Einzelnen Beitrag anzeigen

alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#62

Re: Sehr schneller Primzahl-Finder

  Alt 23. Aug 2005, 21:33
@negaH: Zunächst erstmal finde ich deinen Vorwurf des Kopierens ziemlich peinlich, und deine Ausführungen auch. Da Du bekannte Verfahren einsetzt, könnte man Dir auch den Vorwurf machen. Denn eins ist klar: Du _hast_ abgekupfert. Deine Auslassungen über angeblich 'unqualifizierte' Poster, die sich über deinen peinlichen (einseitigen) Streit über schnelle Algos lustig machen, entsprechen nicht wirklich Deinen Fähigkeiten, oder? Ich meine, sie hat Recht: Sieht wirklich so aus wie Längenvergleich... Deine Behauptung, es gäbe keinen Sourcecode für das 8/30 comb Sieb, kann ich zwar nicht nachvollziehen, aber auch egal. Vielleicht schaust Du mal unter 'Sieve of Atkin'. Im Wiki. Da gibts dann auch den Code. Sieht schon sehr verdächtig nach deinem Code aus. Fragt sich, wer zuerst da war

Im übrigen habe ich an diversen Stellen versucht, den Code von Phantom1 schneller zu machen: Komischerweise klappt das nicht mit den Foatingpoint-Berechnungen. Ich habe mir Einen abgebrochen, aber die Performance bricht immer um ca. 30% ein, wenn man hier was drehen will. Dessenungeachtet wird der Algorithmus von Delphi (bis auf die Berechnungen) fast optimal (was die Anzahl der ASM-Befehle anbelangt) kompiliert, sodass der Delphi-Code mit reinem Assembler vergleichbar ist. Ich hatte das mit anderen Mitstreitern hier in der DP an anderer Stelle mal durchexerziert: Mein normaler Delphi-Code war genauso schnell, wie hochoptimierter Assembler: Aufs Verfahren kommt es eben immernoch primär an.

Dann habe ich die redundanten Berechnungen rausgenommen (k*Primelen, k*Primebits, i*30 etc.). Ergebnis: 30% Performance-EINBRUCH. Vielleicht bin ich ja ein Kaschperl und einfach zu blöd dazu, und Du bekommst es besser hin... Ich habe mir bei dieser Diskussion hier jedenfalls angewöhnt, erst alles zu testen, bevor ich das Maul aufreisse.

Was man imho an Phantom1's Code noch verbessen könnte, sind die Zugriffe auf die Bit-Arrays. Hier wäre ein inkrementierender Pointer besser als die indirekte Offsetaddressierung über ein Array. Ich scheitere an der inneren While-Schleife und dem inc (m,i).
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat