Gathering of Tweakers

prometheus345479

dummy@example.com (prometheus345479) — Sat, 17 May 2008 08:03:41 GMT

zaterdag 17 mei 2008 10:03
Hoi,

Ik heb eigenlijk wat hele algemene vragen over de manier hoe CPUs met intructies omgaan, maar ik heb niet echt een antwoord kunnen vinden op wikipedia of howstuffworks etc.

Ik ben op dit moment bezig met een numeriek model om turbulentie te simuleren. Op dit moment doet dit model er 120 uur over om de berekeningen te doen die nodig zijn. (op één core van een Core 2 Quad) Dit kan ik spreiden over alle cores, maar dan nog steeds duurt het erg lang om alles te simuleren.

Ik wil graag weten hoe ik dit kan versnellen. Ik heb eigenlijk alleen wat informatie van mijn oude programmeer lessen in C++, die af en toe vaag over efficientie van processoren gingen. Zoals: vermijd for loops, en if statements zijn traag.

Van wat ik heb gelezen (maar niet zeker of ik het helemaal begrijp) is het vermijden van for loops handig, omdat branch prediction ~dan beter werkt. En ik weet niet of met huidige processors een if statement veel trager verloopt dan een andere rekenkundige bewerking.

Nog even terug naar waarom ik dit wil weten:

In mijn model worden in de orde van vele miljarden double floating points bewerkingen gedaan (double precision is nodig), en honderden miljoenen if statements uitgevoerd. Stel dat ik het aantal if statements halveer, levert dit dan een significante snelheidswinst op? (als if statements gelijk zijn aan rekenkundige operaties levert het zo'n 1% snelheidswinst op, als if statements veel langer duren een rekenkundige operatie, dan levert het dus veel meer snelheidswinst op)

En als je dubbele if statements gebruikt zoals

if a == 1 || b ==2

Wordt dan in alle gevallen zowel de check a==1 en b==2 uitgevoerd? Of gaat de code al door als 1 van de twee waar is? Dus stel dat a==1 meestal waar is, is het dan nuttig om a==1 eerder te laten checken dan b == 2? En hoe werkt dat in de syntax (wat natuurlijk per taal verschillend is waarschijnlijk)

Het model is geschreven in IDL, dat zeer snel is met matrix vermenigvuldigen, maar langzaam met uitlezen van waarden uit vectors (waarom zou ik graag willen weten).

Ik vind dit allemaal erg interessant om te weten, dus als jullie websites kunnen geven waar dit duidelijk uitgelegd wordt(of zelf de moeite nemen om een heel verhaal te typem) dan erg bedankt!

Blues

dummy@example.com (Blues) — Sat, 17 May 2008 08:10:42 GMT

zaterdag 17 mei 2008 10:10
In z'n algemeenheid moet je altijd eerst kijken naar de programmaflow zelf voordat je op if of for-nivo gaat optimaliseren. Heb je al een profiler gedraaid om te zien waar de meeste executietijd in gaat zitten?

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 10:03:
En als je dubbele if statements gebruikt zoals

if a == 1 || b ==2

Wordt dan in alle gevallen zowel de check a==1 en b==2 uitgevoerd?

De 2e check wordt alleen uitgevoerd als de 1e niet slaagt, vziw.

prometheus345479

dummy@example.com (prometheus345479) — Sat, 17 May 2008 08:14:15 GMT

zaterdag 17 mei 2008 10:14
De programmaflow op zich is goed, daar heb ik goed over nagedacht, en geprobeerd alles zo optimaal mogelijk te laten verlopen.

De grootste vertraging treedt op vanwege twee discrete fourier transformaties op twee 256*256 matrices. Dit zijn de traagste stappen.

Boss

dummy@example.com (Boss) — Sat, 17 May 2008 09:05:19 GMT

zaterdag 17 mei 2008 11:05
Heb je al eens gekeken of je met een code profiler kan uitzoeken waar nu echt de bottlenecks in je code zitten? Daar kunnen misschien ook heel verassende dingen uitkomen.

Stamgastje

dummy@example.com (Stamgastje) — Sat, 17 May 2008 09:12:31 GMT

zaterdag 17 mei 2008 11:12

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 10:14:
De grootste vertraging treedt op vanwege twee discrete fourier transformaties op twee 256*256 matrices. Dit zijn de traagste stappen.

Heb je dit zelf geprogrammeerd? En zo ja, doe je het in O(N log N) stappen (als Fast Fourier Transform dus) of in O(N^2) stappen? In het tweede geval is er dan nog heel veel winst te behalen.

Verder zou ik je aan willen raden om eens naar de FFTW library te kijken: deze bevat allerlei geoptimaliseerde routines om de DFT/DCT/DST te berekenen.

prometheus345479

dummy@example.com (prometheus345479) — Sat, 17 May 2008 09:34:30 GMT

zaterdag 17 mei 2008 11:34
Bedankt voor de snelle reacties!

Helaas gebruik ik al fast fourier transform. En ik ben ook vrij zeker dat de vertragingen in de functies zitten met de fourier transformaties.

Ik zal maandag eens kijken naar een code profiler voor IDL.

Maar weet iemand nu, gewoon uit interesse, of if statements heel veel langzamer zijn dan andere operaties. En of er meer van dat soort performance argumenten zijn om iets wel of niet te doen...

Stamgastje

dummy@example.com (Stamgastje) — Sat, 17 May 2008 09:58:29 GMT

zaterdag 17 mei 2008 11:58

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 11:34:
Helaas gebruik ik al fast fourier transform. En ik ben ook vrij zeker dat de vertragingen in de functies zitten met de fourier transformaties.

Als je vooral geïnteresseerd bent in de resultaten van je berekening, zou ik je nogmaals willen aanraden de FFTW library te gebruiken. Deze bevat door-en-door geoptimaliseerde code. Ben je echter vooral geïnteresseerd in het optimaal leren programmeren, dan moet je natuurlijk met je eigen code verder gaan.

quote:
Maar weet iemand nu, gewoon uit interesse, of if statements heel veel langzamer zijn dan andere operaties. En of er meer van dat soort performance argumenten zijn om iets wel of niet te doen...

Dat hangt heel erg af van de processor. En specifieker: van de lengte van de instruction pipeline en van de branch predictor. Op een Pentium 4 bijvoorbeeld zal een IF statement gemiddeld gezien veel meer pijn doen dan op een AMD Athlon XP, aangezien de eerste een veel langere pipeline heeft (grofweg twee keer zo lang).

Maar verder hangt de performance nog van veel meer zaken af. Loops hoeven helemaal niet slecht te zijn, de code voor de loop bevindt zich na de eerste iteratie in de cache en hoeft dus niet steeds opnieuw uit het RAM gehaald te worden (dat relatief zeer traag is). Dit is dus een geval van locality of reference. Wat in jouw voorbeeld heel erg kan helpen, is om het Cooley-Tukey FFT algoritme te gebruiken. Dit deelt de FFT op in losse 1D transforms (van 1x256 waardes). Dit heeft twee voordelen:

alle waardes voor zo'n kleine FFT kunnen zich in de locale cache van de processor (of specifieker: de core) bevinden
de verschillende cores (in jouw geval 4) kunnen tegelijkertijd verschillende stukken van de 2D FFT berekenen zonder dat ze hiervoor elkaars resultaten nodig hebben

Kortom, een eenduidig antwoord op jouw vraag is niet mogelijk. Op micro-niveau geldt dat de efficiëntie van een bepaalde instructie erg af hangt van de processor. En op macro-niveau geldt bijv. dat andere zaken (de mate van communicatie tussen verschillende cores, locality of reference etc) een grote rol spelen.

Onno Hovers

dummy@example.com (Onno Hovers) — Sat, 17 May 2008 10:15:30 GMT

zaterdag 17 mei 2008 12:15

quote:
Blues schreef op zaterdag 17 mei 2008 @ 10:10:
[...]
De 2e check wordt alleen uitgevoerd als de 1e niet slaagt, vziw.

Dat is alleen relevant als er functies worden aangeroepen of er side-effects zijn. In dit geval maakt het niets uit. Dus de compiler kan de jump penalty vermijden door ze allebei uit te voeren. Als je echt wil weten wat de compiler doet, dan moet je kijken naar de machinecode die de compiler produceert.

Hoe snel het dan op een processor draait, daarvoor moet je profilen. De huidige processoren hebben zoveel optimalisaties en caches dat het heel moeilijk is om goed te redeneren over hoeveel tijd een instructie kost.

TheWickedD

dummy@example.com (TheWickedD) — Sat, 17 May 2008 10:24:08 GMT

zaterdag 17 mei 2008 12:24

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 10:03:
En als je dubbele if statements gebruikt zoals

if a == 1 || b ==2

Wordt dan in alle gevallen zowel de check a==1 en b==2 uitgevoerd?

Dit hangt van de programmeertaal en compiler af denk ik. Ik werk veel met MATLAB en daar kun je beide doen.

voor MATLAB:
a == 1 | b ==2 Evalueert beide en kijkt dan of minstens eentje waar is
a == 1 || b ==2 Evalueert eerst a==1 en als die niet waar is pas b==2

Met IDL heb ik geen ervaring, dus kan ik je dit niet vertellen. Moet wel ergens in een goeie reference ofzo terug te vinden zijn?

MSalters

dummy@example.com (MSalters) — Sat, 17 May 2008 22:53:09 GMT

zondag 18 mei 2008 00:53

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 11:34:
Bedankt voor de snelle reacties!

Helaas gebruik ik al fast fourier transform. En ik ben ook vrij zeker dat de vertragingen in de functies zitten met de fourier transformaties.

Ik zal maandag eens kijken naar een code profiler voor IDL.

Maar weet iemand nu, gewoon uit interesse, of if statements heel veel langzamer zijn dan andere operaties. En of er meer van dat soort performance argumenten zijn om iets wel of niet te doen...

Een redelijke stelling is dat if-statements geen bijzonder grote penalty geven in naief geschreven programma's. Ongeveer de enige plek waar ze belangrijk zouden kunnen zijn is binnen in je FFT. Maar die heb je zelf niet geschreven, dus daar hoef je je niet druk om te maken.

Aan de andere kant wil je het liefst de FFTs in de SSE unit draaien; die is veel beter in dat soort dingen. Kan je IDL compiler dat?

pkuppens

dummy@example.com (pkuppens) — Sun, 18 May 2008 06:59:18 GMT

zondag 18 mei 2008 08:59

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 11:34:
Bedankt voor de snelle reacties!

Helaas gebruik ik al fast fourier transform. En ik ben ook vrij zeker dat de vertragingen in de functies zitten met de fourier transformaties.

Ik zal maandag eens kijken naar een code profiler voor IDL.

Maar weet iemand nu, gewoon uit interesse, of if statements heel veel langzamer zijn dan andere operaties. En of er meer van dat soort performance argumenten zijn om iets wel of niet te doen...

FFT2D zelf bedacht? Leuk om de details van te begrijpen, maar er hebben veel andere mensen ook al naar gekeken, die vast al genoeg verstand hebben van het parallelliseren en andere compiler optimalisaties. En of het nu handiger is om alvast wat cosinus en butterfly tabellen in het geheugen te hebben, of steeds uit te rekenen.

Verder is met 99.97% zekerheid je compiler slimmer in het (weg-)optimaliseren van IF statements, tenzij er wat in je probleemdomein mogelijk is, mathematische eigenschappen van de matrix (zuiver reeel, e.d.).

Die profiler is een goede suggestie waar ik niet aan gedacht heb. Doen die alleen rekentijd of ook geheugengebruik/diskgebruik (swappen)?

Mijn echte suggestie is om terug te gaan naar 128x128. Dat is denk ik 8x sneller.
Van double naar float heeft denk ik geen zin meer op een 64 bit processor, maar daar zou je ook nog naar kunnen kijken. Als het scheelt, dan scheelt het meteen 100%!
Als je je probleem genormaliseerd hebt, valt het wel mee met het precisie verlies.

Nyquist kan je vertellen of dat bij jouw probleem allemaal kan..
[Edit: ik herlees je originele mail en daarin zeg je dat het nodig is, die dubbele precisie. Dan is je 256x256 vast ook nodig :/] Ik geloof dat niet helemaal, wat is jouw Nyquist sommetje?

[Ir. Technische Wiskunde TU/e - 1993]

RemcoDelft

dummy@example.com (RemcoDelft) — Sun, 18 May 2008 07:22:27 GMT

zondag 18 mei 2008 09:22

quote:
prometheus345479 schreef op zaterdag 17 mei 2008 @ 10:03:
Stel dat ik het aantal if statements halveer, levert dit dan een significante snelheidswinst op?

Kan je dit niet simpelweg even testen? Maak een test-progje, laat hem 10M if-statements doorlopen, en vergelijk de runtime met het doen van 10M andere bewerkingen...

Voutloos

dummy@example.com (Voutloos) — Sun, 18 May 2008 10:31:18 GMT

zondag 18 mei 2008 12:31
En opzoeken/testen of er bij if condities short circuiting gebruikt wordt is ook maar 5 seconden werk...

prometheus345479

dummy@example.com (prometheus345479) — Sun, 18 May 2008 11:03:24 GMT

zondag 18 mei 2008 13:03

quote:
MSalters schreef op zondag 18 mei 2008 @ 00:53:
[...]
Een redelijke stelling is dat if-statements geen bijzonder grote penalty geven in naief geschreven programma's. Ongeveer de enige plek waar ze belangrijk zouden kunnen zijn is binnen in je FFT. Maar die heb je zelf niet geschreven, dus daar hoef je je niet druk om te maken.

Goed, dan laat ik het hele if statements gebeuren varen. Ik dacht dat het veel tijd zou schelen door de error handling (die met if statements wordt afgehandeld) uit mijn meest aangeroepen standaard functies te halen. Maar kennelijk is een if statement niet zo traag als ik dacht, oude informatie ofzo...

quote:
pkuppens schreef op zondag 18 mei 2008 @ 08:59:
[...]
Mijn echte suggestie is om terug te gaan naar 128x128. Dat is denk ik 8x sneller.
Van double naar float heeft denk ik geen zin meer op een 64 bit processor, maar daar zou je ook nog naar kunnen kijken. Als het scheelt, dan scheelt het meteen 100%!
Als je je probleem genormaliseerd hebt, valt het wel mee met het precisie verlies.

Nyquist kan je vertellen of dat bij jouw probleem allemaal kan..
[Edit: ik herlees je originele mail en daarin zeg je dat het nodig is, die dubbele precisie. Dan is je 256x256 vast ook nodig :/] Ik geloof dat niet helemaal, wat is jouw Nyquist sommetje?

[Ir. Technische Wiskunde TU/e - 1993]

Bedankt voor je uitgebreide reactie, mocht je geinteresseerd zijn, ik ben optica en turbulentie aan het simuleren. En met Fourier transformaties gaat dat heel makkelijk. Ik gebruik de standaard IDL FFT, dus die zal wel geheel geoptimaliseerd zijn.

Het probleem is dat bij Fourier optics, je lens een blokfunctie is (waar een turbulent golffront doorheen gestuurd kan worden). De benodigde nyquist sampling is dus eigenlijk oneindig, om de blokfunctie te kunnen sampelen. Het bleek dat de fouten die optraden vanwege het samplen te groot waren bij een kleine matrix. De fout neemt toe naarmate je dichter bij de rand van de matrix zit. (hoge spatial frequencies). Dit probleem is gewoon inherrent aan de discrete fourier transformatie.

Dus nu simuleren we een grote matrix (256x256) en zoomen daarna in op het centrale gedeelte (32x32), dat voldoende nauwkeurig is. Ook de double precisie is nodig, om de grote range aan waarden allemaal mee te kunnen nemen.

MSalters

dummy@example.com (MSalters) — Sun, 18 May 2008 22:11:03 GMT

maandag 19 mei 2008 00:11
Tja, ik ben toch geneigd om te suggereren dat je snelheidswinst het makkelijkste te halen is door een slimmer algoritme. Om een oplossingsrichting te suggereren: gebruik eerst lage precisie (128x128) om vervolgens in deelgebieden met hogere resolutie eeen foutcorrectie toe te passen. Dat werkt als/omdat je nu grote gebieden met hoge precisie uitrekent terwijl ze niet wezenlijk bijdrage aan de foutterm.

prometheus345479

dummy@example.com (prometheus345479) — Mon, 19 May 2008 07:21:25 GMT

maandag 19 mei 2008 09:21

quote:
MSalters schreef op maandag 19 mei 2008 @ 00:11:
Tja, ik ben toch geneigd om te suggereren dat je snelheidswinst het makkelijkste te halen is door een slimmer algoritme. Om een oplossingsrichting te suggereren: gebruik eerst lage precisie (128x128) om vervolgens in deelgebieden met hogere resolutie eeen foutcorrectie toe te passen. Dat werkt als/omdat je nu grote gebieden met hoge precisie uitrekent terwijl ze niet wezenlijk bijdrage aan de foutterm.

Het probleem is dat er niet valt te voorspellen wat de fout is. Ik genereer een willekeurig golffront, en doe daar een fouriertransformatie op.

Inmiddels heb ik zelf al iets bedacht wat ongeveer 25% snelheidswinst op moet leveren. (beetje te ingewikkeld om op een programmeer forum op in te gaan). Maar dan nog duurt het erg lang.

pkuppens

dummy@example.com (pkuppens) — Tue, 20 May 2008 17:33:14 GMT

dinsdag 20 mei 2008 19:33

quote:
prometheus345479 schreef op maandag 19 mei 2008 @ 09:21:
[...]

Het probleem is dat er niet valt te voorspellen wat de fout is. Ik genereer een willekeurig golffront, en doe daar een fouriertransformatie op.

Inmiddels heb ik zelf al iets bedacht wat ongeveer 25% snelheidswinst op moet leveren. (beetje te ingewikkeld om op een programmeer forum op in te gaan). Maar dan nog duurt het erg lang.

Wat doe je allemaal nog meer dan dat? Want mijn matlab op een trage SUN had maar orde grootte milliseconden nodig om een 256x256 FFT uit te rekenen.

En wat gaf de code profiler aan?

prometheus345479

dummy@example.com (prometheus345479) — Wed, 21 May 2008 08:42:55 GMT

woensdag 21 mei 2008 10:42
Ik zal even posten wat de code profiler aangaf. (uitleg onderaan)
code:

Module          Type  Count     Only(s)   Avg.(s)     Time(s)   Avg.(s)
ABS             (S)    1002    2.264961  0.002260    2.264961  0.002260
ACOS            (S)       2    0.007523  0.003761    0.007523  0.003761
ARG_PRESENT     (S)       2    0.000006  0.000003    0.000006  0.000003
BYTE            (S)    6004    0.021434  0.000004    0.021434  0.000004
COOGRID         (U)    6002    7.138946  0.001189   11.613055  0.001935
COS             (S)    5000   11.494399  0.002299   11.494399  0.002299
CREATE_STRUCT   (S)    6003    2.087533  0.000348    2.087533  0.000348
DBLARR          (S)    9014    1.022593  0.000113    1.022593  0.000113
DCOMPLEX        (S)    8000    6.051644  0.000756    6.051644  0.000756
DINDGEN         (S)   12004    0.065636  0.000005    0.065636  0.000005
DOUBLE          (S)   10000    1.872647  0.000187    1.872647  0.000187
ECLAT           (U)    4000    0.128123  0.000032    4.221070  0.001055
EXP             (S)    3000   15.977381  0.005326   15.977381  0.005326
FFT             (S)    4000   55.418734  0.013855   55.418734  0.013855
FIX             (S)       3    0.000248  0.000083    0.000248  0.000083
FLOAT           (S)       2    0.000006  0.000003    0.000006  0.000003
GENERATE_IMAGE  (U)    1000    5.626188  0.005626  154.693842  0.154694
GENSHIFT        (U)    1000    4.322913  0.004323   64.514111  0.064514
IMAGINARY       (S)    3000    1.522926  0.000508    1.522926  0.000508
KEYWORD_SET     (S)  169044    0.395062  0.000002    0.395062  0.000002
LONG            (S)    1000    0.002499  0.000002    0.002499  0.000002
MATHFT          (U)    4000   16.434584  0.004109  196.604006  0.049151
MIN             (S)    4000    1.054041  0.000264    1.054041  0.000264
MOMENT          (U)       2    0.000098  0.000049    0.000185  0.000093
N_ELEMENTS      (S)    6006    0.014832  0.000002    0.014832  0.000002
N_PARAMS        (S)   22002    0.050284  0.000002    0.050284  0.000002
ON_ERROR        (S)    4004    0.015306  0.000004    0.015306  0.000004
PRINT           (S)      12    0.000314  0.000026    0.000314  0.000026
PROFILER        (S)       4    0.000175  0.000044    0.000175  0.000044
RANDOMN         (S)    1000    5.908828  0.005909    5.908828  0.005909
RANDOMU         (S)    1000    1.368500  0.001368    1.368500  0.001368
ROTATE          (S)    8000    4.265221  0.000533    4.265221  0.000533
SHIFT           (S)    4000    4.033640  0.001008    4.033640  0.001008
SIN             (S)    5000  101.880558  0.020376  101.880558  0.020376
SIZE            (S)  227060    0.600929  0.000003    0.600929  0.000003
SQRT            (S)    3006    1.353392  0.000450    1.353392  0.000450
STDDEV          (U)       2    0.000030  0.000015    0.000223  0.000111
SYSTIME         (S)       1    0.000005  0.000005    0.000005  0.000005
TOTAL           (S)    4006    0.036819  0.000009    0.036819  0.000009
WAVE            (U)    1000   20.994102  0.020994  118.914418  0.118914
WFSSIM          (U)       1    1.194888  1.194888  274.870050274.870050
WHERE           (S)    5002    0.242422  0.000048    0.242422  0.000048

De colom module geeft de naam van de module aan.
Type geeft het type van de module aan. U is zelf gemaakt, S is een system variabele
count is het aantal keer dat een functie wordt aangeroepen.
only is de tijd die besteed wordt in de functie zelf (dus zonder de tijd meegerekend van calls naar externe functies)
time is de tijd besteed in de functies in totaal

Dit is het resultaat van 1000 iteraties. In totaal moeten er 9*9*5=405 maal 1000 ieteraties uitgevoerd worden. En dit moet in totaal voor 5 verschillende waarden worden uitgevoerd, maar dat kan gespreid worden over 5 cores.

Het beste kun je kijken naar de only time, waar te zien is dat de meeste vertraging zit in de sinus functie, en in de fast fourier transform functie. Sin wordt per iteratie 5 maal aangeroepen, fft 4 maal.

De grote verassing is dus dat de vertraging in de sinus functie optreed, en niet zozeer in de fft. Toch wel nuttig zoiets.

Ik ga nu uitzoeken of ik calls naar sin kan vervangen door iets anders, snellers.

Bedankt voor de hulp, en als iemand nog suggesties heeft dan graag!

JeRa

dummy@example.com (JeRa) — Wed, 21 May 2008 08:51:37 GMT

woensdag 21 mei 2008 10:51
De standaard methode om aanroepen naar sin() te versnellen is vantevoren een cache te maken met input -> output waarden. Afhankelijk van hoeveel waarden je cachet en het bereik van deze waarden gaat dit ten koste van de nauwkeurigheid van je model, of van het geheugengebruik.

Stamgastje

dummy@example.com (Stamgastje) — Wed, 21 May 2008 09:53:09 GMT

woensdag 21 mei 2008 11:53

quote:
prometheus345479 schreef op zondag 18 mei 2008 @ 13:03:
Ik gebruik de standaard IDL FFT, dus die zal wel geheel geoptimaliseerd zijn.

Dat is een erg gevaarlijke aanname, die al onderuit gehaald wordt door de resultaten van de profiler. Waarom probeer je niet de FFTW library in je code je hangen? Zoals ik al eerder aangaf is die wel echt goed geoptimaliseerd. Of kan je die niet vanuit IDL aanroepen?

En verder heeft MSalters natuurlijk gelijk dat de grootste winst gehaald kan worden door je matrix te verkleinen indien mogelijk. Standaard geldt: hoe hoger het niveau van optimalisatie/versimpeling, hoe groter de winst. Dus op algoritmisch niveau kun je bijvoorbeeld een factor 1-10 winnen (hier: door een kleinere matrix te gebruiken), waar je met optimalisaties in de implementatie vaak maar een veel kleinere factor (<2) kunt winnen (hier: betere FFT implementatie door bijv. een lookup tabel te gebruiken i.p.v. steeds de Sin/Cos waardes te berekenen).

zeroxcool

dummy@example.com (zeroxcool) — Wed, 21 May 2008 14:27:38 GMT

woensdag 21 mei 2008 16:27

quote:
prometheus345479 schreef op woensdag 21 mei 2008 @ 10:42:
Ik zal even posten wat de code profiler aangaf. (uitleg onderaan)
[code]
Module Type Count Only(s) Avg.(s) Time(s) Avg.(s)
ABS (S) 1002 2.264961 0.002260 2.264961 0.002260
...
[/list]

(...)

offtopic:
Waar komt deze lijst uit, welke profiler, en ander welk platform/IDE?

Knutselsmurf

dummy@example.com (Knutselsmurf) — Wed, 21 May 2008 14:49:32 GMT

woensdag 21 mei 2008 16:49
Wat mij opvalt, is dat de COS() zoveel sneller is dan de SIN(). Ik zou verwachten dat deze operaties ongeveer gelijk zijn

JeRa

dummy@example.com (JeRa) — Thu, 22 May 2008 06:52:28 GMT

donderdag 22 mei 2008 08:52

quote:
Knutselsmurf schreef op woensdag 21 mei 2008 @ 16:49:
Wat mij opvalt, is dat de COS() zoveel sneller is dan de SIN(). Ik zou verwachten dat deze operaties ongeveer gelijk zijn

De gemiddelde tijd ligt inderdaad lager. Zou dit betekenen dat een aanroep naar SIN() simpelweg geredirect wordt naar COS() met een faseverschuiving? Want een extra functioncall zou dat tijdsverschil wel kunnen verklaren.

prometheus345479

dummy@example.com (prometheus345479) — Thu, 22 May 2008 08:15:11 GMT

donderdag 22 mei 2008 10:15

quote:
Stamgastje schreef op woensdag 21 mei 2008 @ 11:53:
[...]

Dat is een erg gevaarlijke aanname, die al onderuit gehaald wordt door de resultaten van de profiler. Waarom probeer je niet de FFTW library in je code je hangen? Zoals ik al eerder aangaf is die wel echt goed geoptimaliseerd. Of kan je die niet vanuit IDL aanroepen?

Ik heb even gekeken naar FFTW, maar het is nogal ingewikkeld om te implementeren. Het is mogelijk om IDL en C samen te laten werken, maar dit werkt weer niet met de IDL versie die ik thuis heb. (dat is de demo versie, waarbij calls naar externe code niet zijn toegestaan).

Het liefst wil ik alles volledig cross platform houden, zodat ik mijn pc thuis ook kan gebruiken voor rekenwerk. (die is sneller dan de computers op de universiteit) Thuis heb ik vista 64-bit met een core 2 Quad. en op de faculteit heb ik 64 bit linux met AMD X2's.

@JeRa
Wat je zegt klopt niet helemaal. COS en SIN in mijn code evenvaak aangeroepen. Dus als een call naar COS SIN zou aanroepen, dan zou de count van SIN 2 maal de count van COS moeten zijn. Dat is dus niet zo. Ik blijf het vreemd vinden...

@Zeroxcool
De output is de output van de ingebouwde profiler van IDL. (zoek op: IDL profiler )

pkuppens

dummy@example.com (pkuppens) — Thu, 22 May 2008 09:05:44 GMT

donderdag 22 mei 2008 11:05
Klein experiment in matlab, hier is de cos 10x langzamer dan de sin.
Er staat me wel bij dat een cos functie geimplementeerd is met iets met convergentieslagen, maar helemaal zeker weet ik dat niet meer.
matlab:

>> a = rand(100,100)*.001;
>> tic ; c = cos(a); toc
elapsed_time =
    0.0154
>> tic ; c = sin(a); toc
elapsed_time =
    0.0015
>>

Overigens reproduceert dit experiment totaal niet bij mij, dus het zegt niks

Zie bijvoorbeeld dit:
matlab:

>> a=randn(1000,1000)*.001;
>> tic ; c = cos(a); toc
elapsed_time =
   0.27571800000000
>> tic ; c = cos(a); toc
elapsed_time =
   0.20404700000000
>> tic ; c = cos(a); toc
elapsed_time =
   0.25817500000000
>> 
>> tic ; s = sin(a); toc
elapsed_time =
   0.15150000000000
>> tic ; s = sin(a); toc
elapsed_time =
   0.12732000000000
>> tic ; s = sin(a); toc
elapsed_time =
   0.15823100000000
>>

Ik stop er maar mee, je zou er wijzer van moeten worden