LabVIEWForum.de - Primzahlen finden

LabVIEWForum.de

Normale Version: Primzahlen finden
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4
(14.09.2011 08:04 )jg schrieb: [ -> ]Das ist jetzt aber geschummelt! Du parallelisiert die 1000 Durchläufe zur Berechnung der Primzahlen, nicht den einzelnen Berechnungs-Algorithmus selber.
Ja richtig, die äußerste Schleife ist doch nur dazu da, die Berechnung 1000 mal zu wiederholen, um damit die Zeitdauer, die man sonst nur auf 1 ms genau erhalten hätte, genauer auflösen zu können.
Und in den inneren For-Schleifen geht die Parallelisierung nicht, da die Strukturen Shift-Register enthalten.

Bei der Androhung von Gerd:
Zitat:Wenn ihr mir jetzt alle auf die Pelle rückt, muss ich mein VI wohl mal auf MultiCore trimmen - bisher läuft es nur auf einem CPU-Kern
handelt es sich möglicherweis nur um einen Bluff, um uns Angst zu machen Big Grin. Denn bei jedem Finden einer neuen Primzahl werden ja immer die vorangegangenen Ergebnisse verwendet - darauf beruht ja gerade die Schnelligkeit des Codes. Ein Paralleles Arbeiten kann ich mir da schwer vorstellen.

zu Hartz IV: Entschuldigung, der Scherz war von mir, und ich hatte hatte vergessen, diesen emotikonmäßig als solchen zu kennzeichnen, so daß daraus unversehens Ernst wurde. Aber ob mit oder ohne Kennzeichnung: mit meinem Humor habe ich nicht immer ein glückliches Händchen, und das hier ist wohl auch eher schief gegangen.
Übrigens: 1990 war ich ein Jahr arbeitslos, und in dieser Zeit hatte ich Labview im Selbtstudium gelernt.
Hallo Lucki,

Zitat:Bei der Androhung von Gerd:
Wenn ihr mir jetzt alle auf die Pelle rückt, muss ich mein VI wohl mal auf MultiCore trimmen - bisher läuft es nur auf einem CPU-Kern
handelt es sich möglicherweis nur um einen Bluff, um uns Angst zu machen Big Grin. Denn bei jedem Finden einer neuen Primzahl werden ja immer die vorangegangenen Ergebnisse verwendet - darauf beruht ja gerade die Schnelligkeit des Codes. Ein Paralleles Arbeiten kann ich mir da schwer vorstellen.
Nein, das war kein Bluff. Da sollte durchaus das Aufbohren auf 2 CPU-Kerne möglich sein, wenn man parallel 2 "benachbarte" Zahlen siebt und somit (vorher) 2 Iterationen nun in einer erledigt. Aber man sollte dafür schon die DataValueReferences benutzen...

@Jens:
Wenn du in deinem VI noch die ExpressionNode gegen echtes G austauscht, kannst du nochmal ~5% rausholen (2x²+2x = (2x+2)*x = 2*(x+1)*x)...
Liebe LabVIEW Fans

Vielen Dank für die rege Teilnahme an der Diskussion und die beigetragenen Lösungen.

Ich habe die Lösung des Praktikanten sowie die Vergleichszeiten der Berechnungen auf meinem Rechner, wie im Startbeitrag dieses Threads angegeben, eingestellt.

Knapper Gewinner nach Zeit ist: Primzahl3.vi mit 0.01s Mean.
Sowohl Primzahl2 als auch Primzahl3 schlagen das VI des Praktikanten um fast 2 Größenordnungen.

Ich denke aber, das sich das Primzahlen_Praktikant.vi, dass innerhalb von 3 Stunden, inklusive LAbVIEW lernen, entstanden ist, sehen lassen kann. Sowohl im Hinblick auf Perfomance und insbesondere Eleganz in Bezug auf Datenflußprogrammierung.

Gruß Holger
(14.09.2011 08:04 )jg schrieb: [ -> ]
(14.09.2011 07:25 )rasta schrieb: [ -> ]Hallo Lucki,
Dein vi dauert auf meiner privaten Stromspar-CPU Big Grin ~18ms.Daraufhin habe Ich die "Configure Iteration Parallelism" - Möglichkeit
der For-Schleife benutzt und zumindestens auf meinem Rechner interessante Ergebnisse erhalten.
1.) Auto Core mit Configure Iteration Parallelism -- ~ 3,8ms
2.) Single Core -mit Configure Iteration Parallelism -- ~7,5ms
3.) Single Core-ohne Configure Iteration Parallelism -- ~18ms
Außer dieser For-Schleifenänderung ist es immer noch Dein Code.

Gruß
Ralf
Das ist jetzt aber geschummelt! Du parallelisiert die 1000 Durchläufe zur Berechnung der Primzahlen, nicht den einzelnen Berechnungs-Algorithmus selber.

Gruß, Jens
Jens,
ich schummele doch nicht Box, ich hätte lediglich den Off-Topic Hinweis setzten sollen.
Mir ging es um die (für mich) interessanten Ergebnisse Vergleich Nr 2.) mit Nr.3)
Im Task-Manager ist bei beiden 1 Kern voll ausgelastet, jedoch 2.) Faktor ~2,4 schneller als Nr.3)
Warum?
Vielleicht hat ja jemand eine Antwort..

Gruß Ralf
(14.09.2011 09:16 )jg schrieb: [ -> ]Anbei eine kleine Optimierung von Lucki's VI. Die Anzahl der Durchläufe der FOR-Loop lässt sich deutlich minimieren.
Auf einem i7 920 gewinne ich damit ca. 1 ms (9,2 ms zu 10,2 ms).

Dafür hast du das Ergebnisarray aber auch ein wenig zu klein dimensioniert. Es fehlen knapp 7000 Werte (bei 1000000 durchläufen).

MfG Carsten
Oh, da hast du Recht. Da habe ich mir zu sehr auf die Aussage von GerdW verlassen.
(09.09.2011 21:44 )GerdW schrieb: [ -> ]Wikipedia (in den 60er/70er Jahren war da ja noch nicht dran zu denken) ist da sehr hilfreich: Anzahl der Primzahlen bis x ~= x/ln(x). Ist eine gute Abschätzung, um Speicher zu reservieren, in dem die Ergebnisse abgelegt werden...
Naja, das ist die Gelegenheit, gleich mal den Formelknoten rauszuschmeißen.
[attachment=38240]
Gruß, Jens
Hallo Jens,

Anmerkungen:
- ich hatte nicht umsonst "~=" geschrieben
- Wikipedia schreibt pi(x) ~ x/lnx
- Wikipedia zeigt eine Grafik zu pi(x), der man entnehmen kann, das x/ln(x) etwas zu kleine Werte approximiert (wie du gemerkt hast Smile )
- Faktor 2 wie bei dir ist deutlich zu hoch, ich rechne da mit ca. 1,4 (und bin auf der sicheren Seite)
- jetzt solltest du noch die Debugging-Features ausschalten und über die darauf folgende Beschleunigung staunen (bei LV2011 ca. Faktor 3,5 auf meinem Laptop)
Hi, Gerd,

das "~" hatte ich damals schon gesehen und bemerkt, aber irgendwie habe ich die endgültige Ergebnis-Größe des Arrays nicht mehr überprüft. Ganz klar mein Fehler, nicht deiner Wall , und gemerkt hat es Carsten Guru2

Toller Tipp mit Debugging, bringt auf meinem Heim-PC etwas mehr als Faktor 2 (ca. 5 ms zu 12 ms) unter LV2010.

Guru1 Guru1 Guru1

Gruß, Jens
Dass ich das auch mal erleben darf. Big Grin

Gruß Markus

(19.01.2012 22:00 )jg schrieb: [ -> ]Ganz klar mein Fehler
Die Fomel pi(x) ~ x/lnx wurde ja 1793 bereits vom 15jährigen Gauß vermutet, und das bietet einen schönen Vorwand, um etwas
Offtopic2 [Werbung]
einzuschleußen:
In dem 3D-Film über Gauß "Die Vermessung der Welt", Kinostart 25. Oktober 2012, spielen in der Schulklasse, in der der kleine Gauß, statt die Zahlen von 1-50 zu addieren, die Summenformel für eine arithmetrische Reihe verwendete, meine beiden Enkelkinder mit.
Mit dreckigen Gesichtern und Händen, kurz geschorenen Haaren. (Mein Enkeltochter hat sich allerdings geweigert, ihre blonden Locken abschneiden zu lassen, durfte trotzdem mitmachen) Gedreht wurde die Szene in Görlitz, als Gage bekam jeder 150 Euro. Fahrtkosten 2x Dresden-Görlitz blieben allerdings an mir hängen.Big Grin
Seiten: 1 2 3 4
Referenz-URLs