Core2 Duo trager in 64-bit? Onzin!

[Verwijderd]

Okee, nu ben ik het zat...
Iedere keer weer krijg je dat gezeik over dat de Core2 traag zou zijn in 64-bit modus...
Van die verdwaalde AMD-fans die ergens een klok hebben horen luiden...

Mensen, we zijn hier toch tweakers? We willen hier toch weten hoe de vork in de steel zit? We gaan toch niet domweg mensen napraten zonder te weten waar we het precies over hebben?

Waar hebben we het hier dan over?
Nou, in het kort heeft Intel sinds de Pentium M een techniek die bekend staat als Macro Op Fusion.
Kortom, het samenvoegen van meerdere 'macro ops' tot een enkele operatie.
Zoals jullie waarschijnlijk wel weten, worden sinds de Pentium Pro de x86-instructies niet direct uitgevoerd, maar eerst uitgeplozen en vertaald naar kleinere operaties, omdat er een RISC-achtige execution core gebruikt wordt. De x86-achtige instructies worden macro-ops genoemd, en de RISC-achtige instructies worden micro-ops genoemd.

Nu heeft Intel in de implementatie van de 64-bit mode van de Core2 de macro-op fusion niet toegepast. Hier is dit hardnekkige gerucht zeer waarschijnlijk door ontstaan (overigens beschikt de processor ook over micro-op fusion, en die werkt WEL in 64-bit mode).
Maar wat betekent het nou eigenlijk in de praktijk?

Heel weinig... De macro-op fusion is zeer beperkt. Het werkt alleen op cmp en test-instructies, direct gevolgd door een conditional branch (en nog wat andere beperkingen qua 16-byte alignment, maar 1 fusion per cycle etc). Dus het wordt maar op een klein aantal instructies toegepast.
En als het al toegepast wordt, is de enige winst dat je wat bandbreedte bespaart in je pipeline, omdat je een micro-op minder te verwerken hebt. De verwerkingssnelheid van de instructies op zich wordt niet hoger.

Er wordt dus van een mug een olifant gemaakt.
Afgezien van dit detail heeft de 64-bit mode geen afwijkingen tov de executie in 32-bit mode. Je hebt alleen wel het voordeel van meer en grotere registers etc, die normaal gesproken het gebrek aan macro-op fusion ruimschoots compenseren, waardoor 64-bit toch wel een stuk sneller is dan 32-bit.
In mijn eigen code was dat ook duidelijk te zien:
Mijn voorlopige bevindingen over multicore-processing

Daarnaast wil ik ook nog even opmerken dat AMD een dergelijke techniek al helemaal niet heeft... Dus het is onzin dat het als nadeel van Intel gezien wordt... Het is eerder een voordeel van Intel in 32-bit mode ten opzichte van AMD.

Maar je hoeft mij niet te geloven (sommigen lijken te denken dat ik alleen maar pro-Intel ben ofzo)... Ook Agner Fog, een zeer bekende naam in de wereld van software optimalisaties en microarchitecturen zegt dit:
http://www.agner.org/optimize/microarchitecture.pdf

quote: Agner Fog

The fact that macro-op fusion doesn't work in 64-bit mode should not make any programmer
refrain from using 64-bit mode. The performance gain due to macro-op fusion is unlikely to
be more than a few percent, and only if uop throughput is a bottleneck. Macro-op fusion has
no effect in the much more likely case that the bottleneck lies elsewhere.

[McKaamos]

Een beetje tweaker weet echt wel dat een C2D netzogoed snel is in 64bit als elke andere volledige 64bit chip.
De enige chips die niet snel zijn in 64 bit, sterker nog, die niet eens 64bit zijn maar puur wat extensies ervan hebben zijn bepaalde Pentium D modellen.

Maargoed, er zijn vast momenten waarop een C2D trager is dan b.v. een AMD Athon64. Elke chip heeft zo z'n voor en nadelen. Dit zit em echt niet puur en alleen in Macro/Micro-Ops.

Ik weet trouwens niet waarom je staat te klagen... Hier op T.net is het algemeen bekend dat C2D's ongekend snel zijn en nog geen waardige tegenstander hebben gevonden op de desktopmarkt.

[ Voor 17% gewijzigd door McKaamos op 14-01-2007 01:13 ]

[Verwijderd]

McKaamos schreef op zondag 14 januari 2007 @ 01:12:
Ik weet trouwens niet waarom je staat te klagen... Hier op T.net is het algemeen bekend dat C2D's ongekend snel zijn en nog geen waardige tegenstander hebben gevonden op de desktopmarkt.

Verder mag heel zijn bewering nog 100% correct zijn, het maakt eigenlijk niet veel uit.

Daar er tegenwordig bijna niets meer (volledig) in assembler geschreven wordt is iedereen afhankelijk van de compiler ontwikkelaars om ervoor te zorgen dat de mogelijkheden van een CPU zo volledig mogelijk benut worden.

En ik vrees dat ik een open deur intrap als ik zeg dat de doorsnee kwaliteit van de geproduceerde executables al lange tijd heel erg vaak heel erg te wensen overlaat.

Hardware wordt hoe langer hoe sneller en efficienter, maar software benut hoe langer hoe minder al die features. Want je mag nog zo je best doen om een uiterst geoptimaliseerd algoritme te schrijven in een hogere taal, als de compiler shit code produceert schiet je er weinig mee op...

[ Voor 8% gewijzigd door Verwijderd op 14-01-2007 01:24 ]

[Verwijderd]

McKaamos schreef op zondag 14 januari 2007 @ 01:12:
De enige chips die niet snel zijn in 64 bit, sterker nog, die niet eens 64bit zijn maar puur wat extensies ervan hebben zijn bepaalde Pentium D modellen.

Ook dit is niet waar.
De eerste 64-bit core voor Pentium 4 was de Prescott... en alle andere 64-bitters zijn ofwel dualcore-varianten van Prescott, of die-shrinks ervan.
In de 64-bit implementatie zit dus geen verschil. Alle Pentium 4/D-modellen (en ook de Xeon-varianten) zijn even goed of slecht in 64-bit.
Ook dit kun je vinden in mijn topic. Ironisch genoeg zijn de Pentiums doorgaans zelfs het meest gebaat bij 64-bit code. Ze gaan er meer op vooruit dan de Core2... Hoe de Athlon64 het doet weet ik nog niet, omdat nog niemand resultaten heeft durven posten, maar ik ga ervanuit dat de Athlon64 net als de Core2 en de Pentium 4 een klein sprongetje maakt, en niet ineens een gigantisch stuk sneller wordt in 64-bit.
Ik denk dat de Athlon64 ergens tussen de Core2 en Pentium 4 valt, dat is bij de meeste 64-bit benchmarks zo, voor zover ik gezien heb in reviews.

Ik weet trouwens niet waarom je staat te klagen... Hier op T.net is het algemeen bekend dat C2D's ongekend snel zijn en nog geen waardige tegenstander hebben gevonden op de desktopmarkt.

Op de frontpage is het anders iedere keer weer raak.

[Verwijderd]

Verwijderd schreef op zondag 14 januari 2007 @ 01:23:
[...]


Verder mag heel zijn bewering nog 100% correct zijn, het maakt eigenlijk niet veel uit.

Daar er tegenwordig bijna niets meer (volledig) in assembler geschreven wordt is iedereen afhankelijk van de compiler ontwikkelaars om ervoor te zorgen dat de mogelijkheden van een CPU zo volledig mogelijk benut worden.

En ik vrees dat ik een open deur intrap als ik zeg dat de doorsnee kwaliteit van de geproduceerde executables al lange tijd heel erg vaak heel erg te wensen overlaat.

Hardware wordt hoe langer hoe sneller en efficienter, maar software benut hoe langer hoe minder al die features. Want je mag nog zo je best doen om een uiterst geoptimaliseerd algoritme te schrijven in een hogere taal, als de compiler shit code produceert schiet je er weinig mee op...

Dit slaat nergens op.
Dingen als macro-fusion zijn juist gemaakt omdat de compiler vaak 'simpele' code schrijft... Dus een cmp of test met direct daarachter een branch.
En zo niet, dan is het triviaal om de compiler aan te passen zodat hij dat wel doet, en dus ten volle gebruik maakt van deze feature. Ze zullen er eerder optimalisaties uit moeten halen dan erin doen, om dit voor elkaar te krijgen.

Verder zijn compilers nog nooit zo goed geweest als nu. Het probleem van inefficiente code speelt zich op een hoger niveau af, door slechte keuze van algoritmen door onkunde danwel tijdsgebrek. Dat heeft niets te maken met het niveau dat in dit topic besproken wordt.

Modbreak:

Gebruik de edit-knop eens...

[ Voor 4% gewijzigd door dion_b op 14-01-2007 14:23 ]

[GoldenBatt]

Hmm, leuke discussie,,,

Ik ben dan wel geen expert in dit soort dingen, hoe een processor precies in elkaar steekt. Maar ga dit topic toch wel even volgen. Maar is het niet een stuk makkelijker enz om een benchmark op te zetten? Ik zou hier best Win XP Pro 64X voor willen instaleren op een apparte partitie, en wat willen bench marken. Cpu tests zeg maar. Als meerdere tweakers dat doen, en we een leuk tabel maken, hebben we toch een conclusie?

Zijn der trouwens geen benchmark's te vinden @ google?

Edit: Ik vondt dit, en daaruit blijkt dat C2D idd ook beter is in 64Bit
http://blogs.msdn.com/ric...ve/2006/07/13/664890.aspx
Maar is het tot zover wel een betrouwbare test enz? Aan de ene kant maakt het me niet uit, mijn AMD X2 vindt ik snel genoeg voor mezelf, aan de andere kant ben ik wel benieuwt

[ Voor 23% gewijzigd door GoldenBatt op 14-01-2007 01:48 ]

[Verwijderd]

Een benchmark-applicatie had ik al...
Ik had het topic ook al gelinkt: Mijn voorlopige bevindingen over multicore-processing
Hiermee kun je zowel multithreading als 32-bit/64-bit vergelijken (de 64-bit versie vind je wat later in de thread).
De applicaties zijn functioneel 100% identiek... ze zijn allen met VS2005 gecompileerd vanaf dezelfde sourcecode, naar 32-bit danwel 64-bit.

Er is alleen helaas nog niemand geweest die 64-bit resultaten met een Athlon64 heeft gepost.

[ Voor 10% gewijzigd door Verwijderd op 14-01-2007 01:51 ]

[GoldenBatt]

Verwijderd schreef op zondag 14 januari 2007 @ 01:49:
Een benchmark-applicatie had ik al...
Ik had het topic ook al gelinkt: Mijn voorlopige bevindingen over multicore-processing
Hiermee kun je zowel multithreading als 32-bit/64-bit vergelijken (de 64-bit versie vind je wat later in de thread).
De applicaties zijn functioneel 100% identiek... ze zijn allen met VS2005 gecompileerd vanaf dezelfde sourcecode, naar 32-bit danwel 64-bit.

Er is alleen helaas nog niemand geweest die 64-bit resultaten met een Athlon64 heeft gepost.

Ja, maar als ik dat zo lees, laat je ook de 3D kaart mee tellen, vindt dat je dan een puur CPU gebaseerde test moet doen. Om het zo min mogelijk van andere dingen af te laten hangen. Hooguit dus ook nog je moederbord en geheugen. Geef die AMD een board waarop agp past, en pak een Geforce 2, denk dat je dan idd wel lager uit komt. om maar een extreem voorbeeld te geven,,, *Of begrijp ik dat ding nu vekeert?*

[Verwijderd]

Die 3d-kaart telt niet echt mee.
Mijn E6600 met 7600GT scoorde beter dan een E6600 met 8800GTX...
Alleen met ECHT trage videokaarten zal het uitmaken (zoals bv een of andere Quadro die iemand gepost had)... maar de meeste mensen zullen toch minimaal wel een GeForce 6200 hebben of een Radeon X300 ofzo, en dan maakt het bijzonder weinig uit. Je kunt een en ander testen door het window te resizen. Als ie sneller wordt met een kleiner window, dan heeft de GPU dus invloed. Maar dan moet je toch wel een behoorlijk trage GPU hebben.
Je noemt wel die GF2, maar ik zou niet gek opkijken als zelfs een GF2Ultra nog snel genoeg is voor deze test.

[karakedi]

Een kameraad van mij beweerde dat amd in 64 bit sneller zou zijn. Om te kijken of het echt zo was hebben we benchmark gedraaid op de laptops.

Mijn specs:
dell inspiron 6400
proc: t5500 1,66 ghz
geheugen: 2x 512 mb ddr2
chipset: intel 945
video: intel 950gma

Zijn specs:
Acer Aspire 5102
proc: tl-50 1.6 ghz
geheugen: 2x 512 mb ddr
chipset: ati xpress
video: x1100

Om de 64 bit mogelijkheden te testen hebben we gebruik gemaakt van windows vista ultimate 64 bit editie.

Hoewel hij wist dat de core 2 duo sneller was in 32 bit, beweerde hij dat in 64 bit zijn amd sneller zou zijn.

Na een middag gebenchmarkt te hebben met cinebench en pcmark, bleekt dat de dell met t5500 rond de 10% sneller was.

Volgens mij klopt dus niet dat amd in 64 bit beter is.

[GoldenBatt]

Hmm, net even snel die testjes gedaan. Niet uit laten lopen ofzo nog, maar die 1ste loopt bij mij @ 140 fps ofzo gemiddelt, tenzij ik mijn 2de beeldscherm adaptor aanklik, mijn tv, dan ligt dit nog maar op de 70 .

Die 2de loopt op de eerste beeldscherm adaptor met netzoveel frames, en die laatste met 40 frams meer, 170/180 dus. Alleen kwamen deze 2 niet boven de 90 % CPU gebruik uit, en ik gebruik al gemiddelt 5 Procent, aan windows, msn, firefox, 2Keer bcdc++ Plus een hub, en utorrent. Waarom vebruikt hij niet de volle 100 Procent?

[Verwijderd]

GoldenBatt schreef op zondag 14 januari 2007 @ 02:16:
Waarom vebruikt hij niet de volle 100 Procent?

Omdat niet alle code over 2 cores verdeeld kon worden. Daardoor heeft de tweede core af en toe wat rust.

[White Feather]

Gaat het niet gewoon om dat de 64-bit implimentatie van AMD gewoon beter is dan die van Intel. Een Athlon heeft meer voordeel van 64 bit dan een Intel Core 2 Duo. Niet dat dat de Athlon sneller is, want de Intel wint het nog steeds.

[rapture]

Intel processors trager in 64bit?

Eerst uitpluizen vanwaar deze stelling komt.

AMD had x86-64 (AMD64) instructieset in elkaar gestoken voor hun Athlon X2 64, aangezien Microsoft niet 87 varianten van 64bit Windows willen maken, moest Intel AMD-compatibele processors bakken. AMD mag processors bakken door een x86-licentie van Intel en Intel had geëist dat ze het recht bezitten om alles van AMD-processors te kopiëren. Dus Intel downloadt ff de datasheet van AMD64 en snel werden de eerste AMD-compatibele (EM64T) processors gebakken. Wie zegt dat die datasheets van AMD wel juist zijn? Daar kunnen evengoed bugs insteken zodat de eerste x86-64-compatibele processors brak presteerden. Dat kan nu veranderd zijn, Core 2 Duo beschikt over zoveel brute kracht dat het voldoende compenseert?

De stelling proberen te ontkrachten door een eigen (partijdige of gewoon slecht gecodeerde?) programma gaat niet zomaar lukken. Dus naar reallife benchmarks (en allerlei programma's) grijpen en benchen maar. Je kan al starten met x64-versies van 7-zip (compressie), Xvid, Counter-Strike-server,... te testen. Uiteindelijk zal de gebruiker de keuze maken gebaseerd op de applicaties dat hij/zij wilt draaien. Nee, ze kopen geen processor om synthetische benchmarks (ook niet om Sisoft Sandra, Prime95,...) te draaien.

[ Voor 4% gewijzigd door rapture op 14-01-2007 04:02 ]

[Verwijderd]

White Feather schreef op zondag 14 januari 2007 @ 02:37:
Gaat het niet gewoon om dat de 64-bit implimentatie van AMD gewoon beter is dan die van Intel. Een Athlon heeft meer voordeel van 64 bit dan een Intel Core 2 Duo. Niet dat dat de Athlon sneller is, want de Intel wint het nog steeds.

Dat is dus niet zo.
Dat was het argument toen de Pentium 4 64-bit extensies kreeg, maar ook toen al was de P4 over het algemeen een stuk sneller in 64-bit mode dan in 32-bit mode (en ook de Athlon64 kent situaties waar hij trager is in 64-bit mode dan in 32-bit mode).
Toen was het dus al niet geldig... Het was weliswaar een beetje een gekunstelde oplossing om 64-bit ALUs te bouwen in een 32-bits ontwerp, maar aan de prestaties was dat niet af te zien (en strikt gezien is een Athlon64 ook niet veel meer dan een 64-bits uitbreiding van de gewone Athlon... de verschillen zitten vooral in delen die onafhankelijk zijn van de execution core, zoals hypertransport en een geintegreerde memorycontroller).
Aangezien de Core2 Duo een compleet 64-bits ontwerp is, gaat het argument al helemaal niet meer op.

Verder valt er weinig te zeggen over Athlons, omdat ze zo enorm veel trager zijn dan Core2 Duos.
Het is nogal logisch dat er minder winst te boeken valt, naarmate de 32-bits basissnelheid hoger ligt (en mede daarom doet de Pentium 4 het juist relatief goed in 64-bit). Andere factoren, zoals geheugen, chipset, harddisk etc gaan steeds zwaarder meewegen. Het wordt dus steeds moeilijker om betere prestaties te behalen als de rest van het systeem niet sneller wordt.
Helaas heeft geen enkele reviewer dat door, en probeert niemand een low-budget Core2 te koppelen aan een Athlon64 die min of meer gelijke 32-bits prestaties levert.

[Verwijderd]

rapture schreef op zondag 14 januari 2007 @ 02:41:
De stelling proberen te ontkrachten door een eigen (partijdige of gewoon slecht gecodeerde?) programma gaat niet zomaar lukken.

Het programma bestond al voor de stelling, en is ironisch genoeg voor 95% geschreven en geoptimaliseerd op een Athlon XP 1800+.
Als het al partijdig is, dan is het wel ten voordele van AMD, omdat dat mijn ijkpunt was tijdens veel van de optimalisaties.
Slecht gecodeerd is het ook zeker niet, ik durf de bewering wel aan dat dit een van de snelste implementaties in zijn soort is, die er bestaan. Er zitten nogal wat jaartjes research en werk in.
Kortom, ik pik deze insinuaties niet, en ik eis verontschuldigingen.
Sowieso geven de 'reallife' benchmarks eenzelfde beeld (dit algoritme is net zo reallife overigens, lees de andere thread nog maar eens door, jij bent niet de eerste onwetende snotneus die dit soort domme opmerkingen maakt).

[ Voor 12% gewijzigd door Verwijderd op 14-01-2007 03:02 ]

[burne]

Verwijderd schreef op zondag 14 januari 2007 @ 01:23:
als de compiler shit code produceert schiet je er weinig mee op...

Compilers doen dat niet. Niet meer. De doorsnee compiler is met een gemiddeld niveau van optimalisatie al beter dan een doorsnee programmeur die een stukje assembly inline schrijft. Recente compiler-versies van Intel, GNU en de Portland Group leveren code af die veel beter geoptimaliseerd is dan een mens voor elkaar krijgt.

[rapture]

Verwijderd schreef op zondag 14 januari 2007 @ 02:59:
Het programma bestond al voor de stelling, en is ironisch genoeg voor 95% geschreven en geoptimaliseerd op een Athlon XP 1800+.
Als het al partijdig is, dan is het wel ten voordele van AMD, omdat dat mijn ijkpunt was tijdens veel van de optimalisaties.
Slecht gecodeerd is het ook zeker niet, ik durf de bewering wel aan dat dit een van de snelste implementaties in zijn soort is, die er bestaan. Er zitten nogal wat jaartjes research en werk in.
Kortom, ik pik deze insinuaties niet, en ik eis verontschuldigingen.
Sowieso geven de 'reallife' benchmarks eenzelfde beeld (dit algoritme is net zo reallife overigens, lees de andere thread nog maar eens door, jij bent niet de eerste onwetende snotneus die dit soort domme opmerkingen maakt).

Het gaat erom, dat iedereen programma's, statistieken, grafiekjes, plaatjes, photoshop-creaties,... kan produceren om zijn punt door te duwen. AMD-aanhangers kunnen even goed een vage AMD-fanboy-tool in elkaar steken om mooie cijfers tevoorschijn te toveren.

Om onpartijdiger, nauwkeuriger, zinniger,... te werken, kan je bestaande benchmarks/programma's gebruiken om het verschil tussen de processors te meten. Uiteindelijk kopen mensen geen processors om synthetische benchmarks of vage tools te draaien, ze kopen eerder processors om bepaalde applicaties te draaien.

bv Far Cry (first person shooter) heeft weinig baat met 64bit, maar het zegt niks over andere games.
nieuws: Eerste blik op 64-bit gameprestaties met AMD64 Far Cry

bv reviews, dat de stelling "Intel processors trager in 64bit?" aantoont.
nieuws: Prestaties processors in 64-bit niet onverdeeld gunstig
nieuws: 64-bit-versie Windows XP arena voor Intel en AMD

De reviews beginnen te dateren, het aanbod van x86-64 software groeit,... zodat de reviews een opnieuw mogen gedaan worden. Over Core 2 Duo zijn er gewone reviews geweest, maar nog geen x86-64 reviews.

[Verwijderd]

rapture schreef op zondag 14 januari 2007 @ 03:59:
[...]
Het gaat erom, dat iedereen programma's, statistieken, grafiekjes, plaatjes, photoshop-creaties,... kan produceren om zijn punt door te duwen. AMD-aanhangers kunnen even goed een vage AMD-fanboy-tool in elkaar steken om mooie cijfers tevoorschijn te toveren.

Dat kan, maar dat heb ik niet gedaan.
Ten eerste heb ik het algoritme op een AMD-processor geschreven en geoptimaliseerd.
Ten tweede heb ik er absoluut geen belang bij om een bepaalde processor beter uit te laten komen dan een ander.
Ik wil het beste uit elke processor halen. Daarom heb ik het algoritme ook compleet omgegooid nadat bleek dat de eerste versie niet goed liep op Athlon X2 en Pentium D. Ironisch genoeg bleek de versie die geoptimaliseerd was voor X2 en Pentium D nog sneller op Core2.
Ten derde werk ik al jaren aan dit programma, lang voordat de Core2 uberhaupt begon, en is het zeker niet iets dat even snel in elkaar gedraaid als een soort fanboy-tool. Daarvoor is het veel te ingewikkeld, en zit er veel te veel tijd in. Het is ook geen synthetische test, maar een real-world toepassing.
Kortom, ik pik die insinuaties van jou niet, en ik eis verontschuldigingen.
Mijn code is zo onpartijdig mogelijk (blijkt toch uit het feit dat op alle drie de processors goede resultaten worden geboekt?), en bijzonder nauwkeurig en zinnig. Wie denk je wel dat je bent, om mijn code zo te beoordelen? Waarschijnlijk heb je geen enkel idee wat de code eigenlijk doet.

bv Far Cry (first person shooter) heeft weinig baat met 64bit, maar het zegt niks over andere games.
nieuws: Eerste blik op 64-bit gameprestaties met AMD64 Far Cry

Je weet toch hopelijk wel dat de 64-bit versie van Far Cry ook veel meer detail heeft en grotere levels etc?
Ze hebben de winst van de 64-bit mode omgezet in een betere gedetailleerde game.

bv reviews, dat de stelling "Intel processors trager in 64bit?" aantoont.
nieuws: Prestaties processors in 64-bit niet onverdeeld gunstig
nieuws: 64-bit-versie Windows XP arena voor Intel en AMD

Het gaat hier over Core2, niet over Pentium 4.
Verder zijn er genoeg benchmarks te vinden waar ook Pentium 4 beter werkt in 64-bit mode. Een enkele benchmark uitzonderen waarin P4 het toevallig wat minder doet, is niet representatief.
In mijn programma zijn alle processors sneller in 64-bit dan in 32-bit (tenminste, daar ga ik vanuit, er is nog steeds niemand die Athlon64-resultaten heeft durven posten, dus de kans bestaat dat de Athlon64 toch trager is), en zit het grootste verschil bij de Pentium 4.

Maar er zijn hier mensen die beweren dat de Core2 zelfs trager is dan de Athlon64 in 64-bit. Zo erg denken ze dat het verschil is. En dat noemt zich tweaker.
Fanboys zijn het. Net als jij overigens, met je bespottelijke insinuaties. Ik ben blijkbaar geen tweaker. Ik ben wetenschapper.
Daarom heb ik ook weinig aan die benchmarks in reviews, omdat het daar niet duidelijk is wat er precies gebeurt, en waarom een bepaalde processor beter of minder presteert.
In mijn geval weet ik dat wel, en valt er vrij over te discussieren, en kan ik het programma ook aanpassen om te kijken of er omheen geprogrammeerd kan worden (zoals bv het probleem van de stack in 64-bit... daar gaan waarschijnlijk een hoop programmeurs de mist in).

[ Voor 10% gewijzigd door Verwijderd op 14-01-2007 14:21 ]

[dion_b]

Kortom, ik pik deze insinuaties niet, en ik eis verontschuldigingen.
Sowieso geven de 'reallife' benchmarks eenzelfde beeld (dit algoritme is net zo reallife overigens, lees de andere thread nog maar eens door, jij bent niet de eerste onwetende snotneus die dit soort domme opmerkingen maakt).

Met opmerkingen als dit verneuk je het voor jezelf (alweer)

ddbruijn, je hebt zinnige dingen te melden en bent een van de weinigen die daadwerkelijk ook proefondervindelijk onderbouwt wat je beweert. Hulde daarvoor.

Maar de manier waarop je je in discussies gedraagt kan echt niet door de beugel. Ook al weet je dat je gelijk hebt, je hoort de ander met respect te bejegenen. Dat respect ontbreekt volledig in je posts. Daar komt bij dat je continu je eigen topic aan het schoppen bent door meermaals achter elkaar te posten ipv de edit-knop te gebruiken. Iemand die zijn eigen benchmarktools kan schrijven kan makkelijk uitvinden hoe correct te posten. Dat je dat niet doet getuigt ook van gebrek aan respect, ditmaal voor de GoT Huisregels.

Het is dan ook voor het manifeste gebrek aan respect en fatsoen in je omgang op GoT dat dit topic dicht moet. En dat is jammer, want met de kennis die je hebt zou een topic over deze materie erg interessant kunnen zijn.
Ik zou je willen vragen je daarop te bezinnen. We willen graag die kennis delen en op een normale manier met je bespreken. Maar dat je veel weet geeft je totaal niet een vrijbrief je op sommige momenten als arrogante klootzak te gedragen