Processorsnelheden

[Niakmo]

Niemand heeft nog echte benchmarks gepost, dus hier zijn er een paar die ik even snel kon vinden met google

http://www.barefeats.com/pentium4.html
De G5 2.5Ghz verslaat de 2.4xeon

http://www.digitalvideoed.../features/cw_macvspc2.htm
een wat oudere test waar de G4 1ghz dik word ingemaakt.

http://www.spymac.com/forums/showthread.php?threadid=150543
een nofi benchmark , maar misschien wel handig.

dat is voorlopig wat ik kon vinden zal later wel meer zoeken

[MacWolf]

De benchmark discussie is een eeuwige discussie en naar mijn mening compleet zinloos en wel om de volgende redenen:
* Benchmarks kunnen worden bepaald vanuit verschillende perspectieven. De éne benchmark wordt bepaald aan de hand van de compilatiesnelheid en de andere benchmark wordt bepaald door het aantal fps. Er is niet één benchmark waarmee de algehele prestatie van het systeem (hard- en software) is te bepalen.
* De éne benchmark gaat uit van een zo optimaal mogelijke situatie voor een specifieke processor (optimale code, etc...) de andere benchmark gaat uit van een standaard situatie voor alle processoren, waardoor men kan argumenteren dat de éne processor minder presteert als de andere, puur omdat de situatie niet zo optimaal mogelijk is voor de architectuur.
* Processoren maken gebruik van vector eenheden om code te versnellen. De vectoreenheden verschillen aanzienlijk tussen de PowerPC en x86 processoren. Sommige mensen vinden tests waarbij vectoreenheden ook worden meegenomen dan ook niet objectief en zijn van mening dat tests uitgevoerd mogen worden, zolang dergelijke eenheden niet worden meegenomen bij berekeningen.

[Niakmo]

Maar als je een programma neemt dat zowel op een mac als op een pc draait neemt, en een en de zelde gecompliceerde bewerking laat uitvoeren op de mac en pc dan heb je de een aardige indicatie van hoe de twee systemen verschillen, en weet je meteen of de powerbook van 1500 euro de zelfde dingen in de zelfde tijd of beter () kan uitvoeren dan een pc van 1500 euro.

Natuurlijk moet je bij PC vs Mac benchmarks niet pure processor benchmarks doen maar gewoon kijken hoe programma's lopen, want daar heeft een eventule overstapper wat aan.

[bolleh]

MacWolf schreef op zaterdag 12 februari 2005 @ 03:07:
De benchmark discussie is een eeuwige discussie en naar mijn mening compleet zinloos en wel om de volgende redenen:

niet helemaal waar. ik ben het ermee eens dat het zeer moeilijk benchmarken/vergelijken is maar een goede benchmark komt daar aardig overheen.

quake 3 bijvoorbeeld. noem me gek maar imho nog steeds 1 van de beste benchmarks out there. ik heb 2 jaar terug een soort van onderzoek ernaar gedaan met een 7 compleet verschillende systemen en de resultaten waren verrassend. maakt niet uit wat je veranderde in je pc quake 3 werd er sneller door.

harde schijf? snellere laadtijden. snellere proc? meer fps. meer/sneller geheugen? snellere laadtijd+meer fps. snellere videokaart? meer fps.

en het leuke was dat dit op elke resolutie naar voren kwam, op sommige enkel wat beter.

dan ga ik er wel vanuit dat de mac versie van quake 3 enigsinds goed is geprogrammeerd maar dat zal vast wel

[ErikRo]

zirus schreef op zaterdag 12 februari 2005 @ 08:16:
Maar als je een programma neemt dat zowel op een mac als op een pc draait neemt, en een en de zelde gecompliceerde bewerking laat uitvoeren op de mac en pc dan heb je de een aardige indicatie van hoe de twee systemen verschillen, en weet je meteen of de powerbook van 1500 euro de zelfde dingen in de zelfde tijd of beter () kan uitvoeren dan een pc van 1500 euro.

Dan heb ik een leuke voor je. Speel een wmv filmpje af om de pc met mediaplayer en op de mac met mediaplayer. Driemaal reden met er met grote overmacht wint.
Snap je waar ik heen wil

ps dit geldt ook omgekeerd met een mov file dan wint demac vast met grote overmacht.

[ Voor 7% gewijzigd door ErikRo op 12-02-2005 13:03 ]

[dion_b]

ErikRo schreef op zaterdag 12 februari 2005 @ 13:03:
[...]

Dan heb ik een leuke voor je. Speel een wmv filmpje af om de pc met mediaplayer en op de mac met mediaplayer. Driemaal reden met er met grote overmacht wint.
Snap je waar ik heen wil

ps dit geldt ook omgekeerd met een mov file dan wint demac vast met grote overmacht.

Een willekeurige Mac of PC van de laatste 5 jaar kan met gemak zowat iedere film afspelen, dus dit imbalans is niet echt relevant

Neem een betere:
Doe iets zwaars met Photoshop of Premiere ofzo. Dat zijn zinnige apps die regelmatig op beide platforms gebruikt worden. Of idd een spel als Sims2.

Natuurlijk zijn er platform-specifieke voordelen, maar die verschillen lijken steeds kleiner te worden

[Atari 800xl]

Modbreak:

Mods hebben ook email, loos gaan lopen ranten lost bar weinig op

[ Voor 88% gewijzigd door moto-moi op 12-02-2005 22:16 ]

[ErikRo]

dion_b schreef op zaterdag 12 februari 2005 @ 21:20:
[...]
Een willekeurige Mac of PC van de laatste 5 jaar kan met gemak zowat iedere film afspelen, dus dit imbalans is niet echt relevant

Goed in dat geval probeer eens even een High Definition clips (1080I en 720P) van de microsoft site af te spelen op je mac en vertel me hoe geweldig dit afspeelt. Dan praten we daarna verder.

[Verwijderd]

ErikRo schreef op zaterdag 12 februari 2005 @ 23:16:
[...]

Goed in dat geval probeer eens even een High Definition clips (1080I en 720P) van de microsoft site af te spelen op je mac en vertel me hoe geweldig dit afspeelt. Dan praten we daarna verder.

Ik wi lhet wel afspelen maar het is een .exe bestand wat in vind Daarbij komt het ook nog dat het formaat WM9 is en de Media Player van MS voor OSX gewoon een slecht programma is dat niet eens aan de richtlijnen van Apple OSX voldoet (sluit je het scherm, sluit de applicatie bijv).

Dat ik deze niet krijg afgespeeld ligt niet aan Apple niet aan mijn powerbook niet aan OSX, maar aan Microsoft.

Ik heb nu deze site gevonden zonder een .exe bestand en in Windows Media Player doet deze het zwaar klote!! VLC kan het bestand niet afspelen.

Nu komt het LEUKE!!!! Op die site staat ook een HD Xvid versie van 27mb tov 20mb van de WMV. In Quicktime doet deze het veel beter dan de WMV in Windows Media Player for OSX. Dan komt nu VLC daarin draait de Xvid het PERFECT. Dus je argumenten zijn gewoon klote.

Beide filmbestanden waren 720P ben nu op zoek na een 1080I. WMV kijk ik niet meer heen gewoon omdat het een formaat is dat het minst compatible is en ik al weet dat het niet goed werkt op een non-windowsbak.

[edit1]
Bonus: Draai eens die HD clips van op dezelfde pc in een non-windows OS, loopt ook voor geen meter, rara hoe zou dat komen

[ Voor 5% gewijzigd door Verwijderd op 13-02-2005 00:17 ]

[CyBeR]

ErikRo schreef op zaterdag 12 februari 2005 @ 23:16:
[...]

Goed in dat geval probeer eens even een High Definition clips (1080I en 720P) van de microsoft site af te spelen op je mac en vertel me hoe geweldig dit afspeelt. Dan praten we daarna verder.

Dat ligt niet aan de mac maar aan de absurd brakke mediaplayer die microsoft voor de mac maakt. Dat ding gebruikt niet eens video overlays om 't geheel met minder cpu belasting in beeld te krijgen. Hoewel dat geen groot probleem is als je een filmpje hebt van 320x240, is het wel een probleem als je een HD video stream op die manier wilt laten zien.

[ Voor 14% gewijzigd door CyBeR op 13-02-2005 00:14 ]

[ErikRo]

Inderdaad dat was dus precies het punt wat ik wilde maken.
Je kan niet zomaar een applicatie vergelijken op beide platforms omdat het op een van beide geoptimaliseerd is of juist niet, dat geeft dus geen eerlijk vergelijkingsmateriaal..

[ Voor 15% gewijzigd door ErikRo op 13-02-2005 00:30 ]

[dion_b]

ErikRo schreef op zondag 13 februari 2005 @ 00:27:
Inderdaad dat was dus precies het punt wat ik wilde maken.
Je kan niet zomaar een applicatie vergelijken op beide platforms omdat het op een van beide geoptimaliseerd is of juist niet, dat geeft dus geen eerlijk vergelijkingsmateriaal..

Dat kun je best. Het is voor de gebruiker volstrekt oninteressant of een app geoptimaliseerd is voor architectuur X of Y, het gaat erom hoe goed zijn app presteert op X of Y. En dat die twee niet automatisch overeen hoeven te komen is erg belangrijk.

Kijk bijvoorbeeld zuiver binnen de x86 CPUs naar het jaar 2000-2001. AMD had toen de Athlon Thunderbird als high-end CPU, die geen SSE (vector instructies) native ondersteunde, Intel de P4 Willammette die wel SSE had. Als applicaties SSE niet ondersteunden was de snelste Thunderbird vrijwel altijd sneller dan de Willammeette. Maar omgekeerd was niet altijd waar: soms was de brute FPU kracht van de Athlon genoeg om ook in SSE geoptimaliseerde apps (Photoshop...) sneller te zijn dan de P4.

Omdat optimalisatie bij niet bij voorbaat doorslag geeft is het juist wel belangrijk om vergelijkend te benchen, want anders blijf je marketinglui die "geoptimaliseerd voor P4" of "The way it's meant to be played" blaten napraten

Alleen moet je dan zinnige dingen pakken, niet obscure architectuur of OS afhankelijke meuk, maar gewoon programma's die normale mensen ook zouden gebruiken. Kijk maar eens naar deze review:

http://www.pcmag.com/article2/0,1759,1274637,00.asp

G5 vs G4 vs P4, allemaal duals, vergeleken in Acrobat, Photoshop, Lightwave en Squeeze (en Final Cut, maar uiteraard dan alleen de Apples).

Dat het gaat om appels, oude appels en hooggeclockte peren is irrelevant, het gaat om real-life apps die zinnig vergeleken worden. En dat kan altijd cross-platform

[ErikRo]

Dan zou ik als test Par2 willen voorstellen op een gedloade dvd met x aantal missende blokken.
Dat zou voor mij behoorlijk reallife zijn

[Niakmo]

ErikRo schreef op zaterdag 12 februari 2005 @ 13:03:
[...]

Dan heb ik een leuke voor je. Speel een wmv filmpje af om de pc met mediaplayer en op de mac met mediaplayer. Driemaal reden met er met grote overmacht wint.
Snap je waar ik heen wil

ps dit geldt ook omgekeerd met een mov file dan wint demac vast met grote overmacht.

Als je wmvjes wilt afspelen koop je geen mac en als je mac vormaten wilt afspelen koop je geen pc. Maar kijk eens naar neutrale bedrijven en formaten, als adobe en divx, dan kan je wel een redelijk goede vergelijking maken.

[Verwijderd]

ErikRo schreef op zondag 13 februari 2005 @ 01:24:
Dan zou ik als test Par2 willen voorstellen op een gedloade dvd met x aantal missende blokken.
Dat zou voor mij behoorlijk reallife zijn

Hangt dat niet meer af van je IO-performance?

Benchmarken kan je denk ik het beste met 2 programma's die hetzelfde doen maar beide zo veel mogelijk geoptimaliseerd zijn voor 1 platform. Dus niet hetzelfde programma. Maar dan zit je nog bij waar de architectuur nu eenmaal goed in is. Bij de distributed.net client bijv haal ik met RC5-72 ongeveer 14 miljoen keys/s en dat met een G4-1.33ghz. In windows op mijn athlon 2600+ haal ik 6,7 miljoen keys/s en dezelfde pc in linux haalt 7,9miljoen keys/s. De stukken lager geklokte G4 wint het dus nogal makkelijk met een verschil van 77%. En met OGR is de athlon weer sneller de G4. Het ligt er puur aan wat je met je pc doet. Video encoderen is een P4 weer zeer moeilijk van de troon te slaan en volgens mij delft de G4 daar het onderspit (Als iemand een snellere encoder voor OSX weet dan ffmpegX zeg het me even ).

De topicstarter moet eigenlijk kijken naar de programma's wat er op moeten kunnen draaien. En evt even langs een Apple centre gaan voor een demonstratie. Ook eerst zelf al veel software en leuke tooltjes zoeken voor OSX is wel aan te bevelen. Zo installeerde ik als eerste aMSN om op msn te komen (msn messenger vond ik niets) en als 2de installeerde natuurlijk FireFox en daarna aangezien ik ook een linuxgebruiker ben fink en finkcommander, zodat ik linux sofware op de powerbook kan draaien.
Als je kijkt na de specs van een iBook krijg je veel voor je geld. Voor € 999 euro heb je een G4-1.2ghz Laptop met 30GB schijfje, 256mb geheugen, 54mbps wlan, usb2.0 en een accuduur van 6 uur!!! Die accuduur vindt je bij geen enkele andere laptop terug in die prijsklasse. Het geheugen is magertjes maar daar prop je dan voor 100 euro extra zelf 512mb bij en dan gaat alles heerlijk als je veel applicaties tegelijk gebruikt Als je nu een Apple koopt kan je als OSX Tiger uit komt deze gratis krijgen

Ikzelf koos voor een powerbook omdat als ik een gewone laptop zou kopen het eerste wat eraf ging windows zou zijn en linux erop gepleurd worden. Ik hou van een unix omgeving en OSX geeft me die en dan nog met een gebruiksvriendelijkheid en veiligheid die beter is dan windows. De enige gewone laptop die ik geschik vond koste iets over de € 2000,- en die had als extra een dvdbrander, meer geheugen, 13.3" scherm en gigabit lan. Maar ik had me die niet gekocht omdat de powerbook 300 euro goedkoper geprijst was, ik een dvdbrander in de athlon 2600+ heb die ik bijna nooit gebruik en geen gigabitlan op het moment bezit en de bedoeling was om draadloos door huis te zwerven met de laptop. Het grotere scherm maakte me niet zo uit, mijn oude laptop had een 11.3" scherm en ik wilde een zo klein mogelijke laptop. Dus 300 euro voor alleen 256mb meer aan geheugen vond ik wat veel. Wat ik niet gebruik betaal ik ook niet voor.

offtopic:
Even terug op mijn vorige post: Op geforceerde gereduceerde snelheid (600mhz?) speelt de powerbook(G4-1.33) nog die HD-720P xvid uit mijn vorige post moeiteloos af. Voor 720P kwaliteit in WMV zegt MS zelf dat je minimaal een 2.4Ghz pc nodig hebt met 64mb videokaart zijn die specs niet iets te hoog, ook al is het Windows Media? Ik bedoel... het moet toch ook met minder mogelijk zijn?

[edit:]

zirus schreef op zondag 13 februari 2005 @ 02:47:
[...]


Als je wmvjes wilt afspelen koop je geen mac en als je mac vormaten wilt afspelen koop je geen pc. Maar kijk eens naar neutrale bedrijven en formaten, als adobe en divx, dan kan je wel een redelijk goede vergelijking maken.

Dus volgens jou moet ik als ik WM-bestanden wil kijken een windowspc aanschaffen, slaat nergens op? Waarom werken die formaten van Apple wel goed op windows? iTunes en Quicktime werken bij mijn weten even goed op OSX als op windows. Ook kan je een iPod op OSX en Windows gebruiken. En een PocketPC gebaseerde PDA alleen op windows zonder speciale 3th party software. In mijn ogen wil microsoft al hun protocollen en producten zo veel mogelijk windows only maken om zo andere platformen incompatible met het 'marktleidende' bedrijf Microsoft te laten lijken.

[ Voor 13% gewijzigd door Verwijderd op 13-02-2005 03:54 ]

[Niakmo]

[...]

Dus volgens jou moet ik als ik WM-bestanden wil kijken een windowspc aanschaffen, slaat nergens op? Waarom werken die formaten van Apple wel goed op windows? iTunes en Quicktime werken bij mijn weten even goed op OSX als op windows. Ook kan je een iPod op OSX en Windows gebruiken. En een PocketPC gebaseerde PDA alleen op windows zonder speciale 3th party software. In mijn ogen wil microsoft al hun protocollen en producten zo veel mogelijk windows only maken om zo andere platformen incompatible met het 'marktleidende' bedrijf Microsoft te laten lijken.

Dat microsoft dat doet heeft hier even niks te maken , mijn punt was dat je bij het vergelijken van Mac en PC door benchmarking niet gebruik moet maken van iets wat speciaal voor het platform is geschreven. Ik heb geen flauw idee of wmv's uberhaupt te gebruiken is onder mac. Mijn punt is dat als je pc en mac wilt vergelijken je dat het best met 3th party software kan doen als adobe dat veel pc klanten heeft maar ook veel Mac gebruikers.

[1-0-Ed]

Nietzman schreef op zondag 05 december 2004 @ 17:58:
Zie ook dit filmpje: http://www.esm.psu.edu/Fa.../movies/mhz_myth_320f.mov

Wahaha, goddamn, wat een hype filmpje!

"...so you just saw the 800Mhz G4 beat the 1.8Ghz P4..."

Hoezo gezien? Een slideshow met getallen erin getypt? Mijn kleine teen heeft zojuist in mijn slideshow een P4 3.6Ghz met 500% verslagen... haha

Mooiste vind ik nog wel dat het eerst om een 1.7Ghz gaat en vervolgens de hardware smuck het over 1.8Ghz heeft... tssssk, '...I'm from apple and I'm great...'

[Verwijderd]

Nou dan neem je een Acer 4002WLMI; gaat lang mee...zit nog een redelijk videokaart in (ati9700 64mb) en je kunt er nog een andere hd in flikkeren.
Ik moet zeggen dat de Apple's veel mooier zijn, maar ik denk voor mijzelf niet praktisch genoeg ivm software etc.

[Nietzman]

1-0-Ed schreef op zondag 13 februari 2005 @ 10:10:
Mooiste vind ik nog wel dat het eerst om een 1.7Ghz gaat en vervolgens de hardware smuck het over 1.8Ghz heeft... tssssk, '...I'm from apple and I'm great...'

Heb je ook nog iets zinvols te zeggen of blijft het bij die rant?

Dat filmpje is natuurlijk ook maar een simpele manier om iets ingewikkelds aan een groot publiek uit te leggen.

[downtime]

dion_b schreef op woensdag 08 december 2004 @ 02:55:
Een ouderwetse scalar CPU (neem pakweg een 386) voert per kloktik één instructie uit. Een superscalar CPU (bij Intel vanaf de Pentium, hoe het bij 68xx zit weet ik niet, maar PPC is iig superscalar) voert per kloktik meerdere instructies uit.

Geschiedenislesje: Oudere CPU's dan de 386 hadden voor veel instructies zelfs meerdere kloktikken nodig. Soms, als ik me goed herinner, tot 7 kloktikken voor sommige complexe instructies. De complexiteit van de X86 architectuur houdt in dat niet elke instructie er even lang over doet om gedecodeerd en uitgevoerd te worden en ik meen dat de 386 ook maar af en toe meer dan 1 instructie per kloktik haalde.

Mijn toenmalige computer had een ARM processor die 1 van de eerste CPU's was die consequent 1 instructie per kloktik uitvoerde en dat was alleen omdat het een RISC processor was. Het decoderen van instructies bij zo'n CPU kost nauwelijks tijd waardoor RISC CPU's indertijd een voordeel t.o.v. CISC processoren als de X86's hadden. Bovendien kenden de eerste RISC processoren helemaal niet de complexe instructies waarvoor meerdere kloktikken nodig zouden zijn.
Vandaag de dag speelt dat nauwelijks meer omdat CPU's zoveel tegelijk kunnen doen en het decoderen van instructies gewoon parallel aan het uitvoeren ervan gebeurt. Het voordeel van RISC t.o.v. CISC is daardoor grotendeels weggevallen.

Waarschijnlijk is dat ook de reden dat Apple al een paar jaar geen reclame meer maakt waarin de RISC architectuur van de PowerPC processoren vermeld wordt. Het verschil tussen RISC en CISC speelt nauwelijks meer en zou de meeste Apple klanten bovendien niet interesseren.

[ Voor 10% gewijzigd door downtime op 13-02-2005 13:28 ]

[Peentje]

ja idd aap, als het nergens op gebaseerd was brachten ze het niet uit, en het is echt zo hoe kan het anders dat apple 1.2 gigaherz processors in zijn config stopt terwijl er ap pentiums 4 gigaherz zijn, zal wel betekenen dat die toch wat sneller zijn? (dan die 1.2 gigaherz)

jij kijkt nog steeds als ieder paard (met hele hele grote oogkleppen) recht vooruit en staar je blind op die gigaherzen.

sorry maar dan ben je: "gewoon een beetje dom"

[ Voor 5% gewijzigd door Peentje op 13-02-2005 13:33 ]

[Verwijderd]

zirus schreef op zondag 13 februari 2005 @ 09:14:
[...]


Dat microsoft dat doet heeft hier even niks te maken , mijn punt was dat je bij het vergelijken van Mac en PC door benchmarking niet gebruik moet maken van iets wat speciaal voor het platform is geschreven. Ik heb geen flauw idee of wmv's uberhaupt te gebruiken is onder mac. Mijn punt is dat als je pc en mac wilt vergelijken je dat het best met 3th party software kan doen als adobe dat veel pc klanten heeft maar ook veel Mac gebruikers.

Dat zeg ik toch ook (ongeveer), 3th party software gebruiken, voor mij part 2 verschillende ontwikkelaars met 1 super geoptimaliseerd voor x86 en de ander voor powerpc. Een programma dat geport moet worden naar een ander platform kan altijd nadelig zijn voor de performance.

Toch blijft het nog steeds een probleem dat de ene architectuur beter is dan de andere in een bepaald gebied, dat blijf je gewoon houden. Een algemene score moet je niet na kijken. Je moet de score verdelen in bijv gebruiksgemak, office, games, videobewerking en server toepassingen en daarop kan je bepalen of je de een mac of een pc wil of het niet uitmaakt. Ik koos dus voor een Mac vooral omdat OSX een unix is met zeer veel gebruiksgemak.

[dion_b]

/downtime/ schreef op zondag 13 februari 2005 @ 13:25:
[...]

Geschiedenislesje: Oudere CPU's dan de 386 hadden voor veel instructies zelfs meerdere kloktikken nodig. Soms, als ik me goed herinner, tot 7 kloktikken voor sommige complexe instructies. De complexiteit van de X86 architectuur houdt in dat niet elke instructie er even lang over doet om gedecodeerd en uitgevoerd te worden en ik meen dat de 386 ook maar af en toe meer dan 1 instructie per kloktik haalde.

* dion_b voelt zich flink in z'n mier geneukt
_{Maar da's ook nog eens prettig het van de andere kant mee te maken}

Mijn toenmalige computer had een ARM processor die 1 van de eerste CPU's was die consequent 1 instructie per kloktik uitvoerde en dat was alleen omdat het een RISC processor was. Het decoderen van instructies bij zo'n CPU kost nauwelijks tijd waardoor RISC CPU's indertijd een voordeel t.o.v. CISC processoren als de X86's hadden. Bovendien kenden de eerste RISC processoren helemaal niet de complexe instructies waarvoor meerdere kloktikken nodig zouden zijn.

Tja, dat blijft natuurlijk het CISC <-> RISC onderscheid, zonder die complexe instructies moet de complexiteit door software (compiler) overgenomen worden ipv de CPU core.

Vandaag de dag speelt dat nauwelijks meer omdat CPU's zoveel tegelijk kunnen doen en het decoderen van instructies gewoon parallel aan het uitvoeren ervan gebeurt. Het voordeel van RISC t.o.v. CISC is daardoor grotendeels weggevallen.

Ook omdat de 'CISC' CPUs tegenwoordig een RISC-achtige core hebben met een interne decoder van de CISC instructies. Extreem-CISC monsters als de Vax KAxxx CPUs zijn ook uitgestorven. En omdat sommie RISC (PA...) ook nogal barok aan het worden zijn. Er is gewoon een redelijk middenweg gevonden dat een mengelmoes is van beiden.

Waarschijnlijk is dat ook de reden dat Apple al een paar jaar geen reclame meer maakt waarin de RISC architectuur van de PowerPC processoren vermeld wordt. Het verschil tussen RISC en CISC speelt nauwelijks meer en zou de meeste Apple klanten bovendien niet interesseren.

Daarom begon ik er ook niet over

Het ging mij om verschil scalar <-> superscalar mbt IPC. Het RISC <-> CISC verhaal compliceert dat alleen maar...

De tijd dat het echt uitmaakte was de eerste helft van de jaren '90, denk aan de bombarie waarmee Sun de voordelen van de SPARC tov de 680x0 van de daken schreeuwden. Dat was ook de tijd van de Archimedes, waarnaar je vermoedelijk verwees

Offtopic:
* dion_b zou nog altijd een van de latere Archimedes willen bemachtigen

[ Voor 4% gewijzigd door dion_b op 14-02-2005 02:03 ]

[3mph]

hmm ik volg het allemaal niet meer... gaat boven mijn pet

[Verwijderd]

Ik wil ook graag even inhaken op de CPU-technische discussie...
Ten eerste, over die 386... Die kan NOOIT meer dan 1 instructie per clk halen, omdat ie niet superscalar is. Verder heeft ie al moeite om instructies binnen 1 clk af te werken omdat ie maar een hele beperkte pipeline heeft (ik dacht alleen maar 1 extra stage voor de instructie fetch).
De 486 kan wel instructies binnen 1 clk doen... en de Pentium had dus 2 pipelines (superscalar) en kon dus 2 instructies tegelijk uitvoeren, en dat binnen 1 clk, dus maximaal 2 instructies per clk. De PII/PIII/P4/Athlon zouden in theorie maximaal 3 instructies per clk kunnen halen, ongeveer.
Maar die CPUs werken niet meer volgens de normale superscalar architectuur zoals de Pentium. Bij de Pentium had je 2 pipelines die synchroon liepen... Tegenwoordig heb je zogenaamde 'ports'. Die ports kunnen volstrekt onafhankelijk van elkaar opereren, en maken ook out-of-order executie mogelijk. De PowerPCs werken ook ongeveer op deze manier.

Verder is het IPC-verhaal niet zo heel nuttig, omdat je vergelijkt tussen twee verschillende instructiesets. De PowerPC heeft veel meer registers dan de x86, en de instructies hebben 3 operands ipv 2. In het algemeen kun je dus met minder instructies hetzelfde bereiken. Dus zelfs bij gelijke IPC zou een PPC sneller kunnen zijn (maar je kunt vast ook situaties bedenken waarin het omgekeerde geldt). De complexe instructies van de x86 kun je eigenlijk ook niet meer gebruiken. Zoals al werd opgemerkt, zijn het eigenlijk ook RISC-processors geworden, er zit alleen een soort 'vertalertje' op geschroefd. De eerder genoemde 'ports' zijn in feite RISC-units.
Complexe instructies worden opgebroken in zogenaamde micro-ops... dat zijn zeg maar de instructies van de RISC-units. Hoewel je dus met x86 vaak code in zeer weinig instructies kunt opschrijven, als je de complexe instructies gebruikt, is dit in de praktijk niet sneller, omdat je nog steeds net zoveel micro-ops moet verwerken. Sterker nog, vaak is het langzamer... ten eerste omdat je meestal op meer micro-ops uitkomt dan wanneer je het schrijft met code die 1:1 naar micro-ops vertaalt... en ten tweede omdat het decoderen van complexe instructies vaak langer duurt dan de 1:1 instructies. Dus eigenlijk moet je moderne x86 processors opvatten als RISC-processors, en alleen RISC-achtige code schrijven, en de complexe instructies mijden (als we nog lang met x86 doorgaan, vermoed ik dat uiteindelijk de complexe instructies uit de hardware verdwijnen, en door software-emulatie vervangen worden... Dit is met oa de IBM POWER-architectuur en de Motorola 68060 ook gedaan. Het voordeel is dat de hardware simpeler wordt, en dus sneller).

En natuurlijk zijn de mensen van het Apple-filmpje zo slim geweest om beide pipelines op dezelfde snelheid te laten werken. Dat demonstreert dus wel leuk waarom de kortere pipeline op dezelfde snelheid sneller klaar is... maar in werkelijkheid is de langere pipeline natuurlijk ontwikkeld om de CPU op een hogere snelheid te laten werken, en dan kan het er best wel eens heel anders uit zien. Zoals je kunt zien in het filmpje, zijn (fout voorspelde) branches de reden waarom er verschil optreedt... bij veel branches wint een korte pipeline dus makkelijk... bij weinig of geen branches wint de lange pipeline.
En het leuke aan programmeren is dat je alles op 483928430232 verschillende manieren kunt implementeren. Het is dus heel goed mogelijk om programma's te herschrijven met minder of zelfs geen branches. Dat is ook een beetje de makke van de P4. Op zich doet de P4 qua IPC niet veel onder voor een Athlon. Maar hij is dus niet goed met branches... Met audio/video encoding en dergelijke zie je dat dus... Daar zitten sowieso niet zo veel branches in, en de code is vaak geoptimaliseerd voor P4, en dan is er geen houden aan. Maar een hoop software is nog niet herschreven voor de P4, en met het uitvoeren van 'oude code' is de P4 gewoon zwak (ook met x87 code trouwens).

Ik vind het zelf wel jammer dat de P4 niet helemaal uit de verf is gekomen... Uit puur technisch oogpunt vind ik de architectuur erg indrukwekkend en vooruitstrevend. Maar ik weet niet of we ooit gaan zien dat alle software puur voor P4 geoptimaliseerd wordt... In dat geval blijft Intel compleet afhankelijk van het opschalen van de kloksnelheid, ter compensatie van de zwakheden van de P4, in plaats van dat de software die zwakheden uit de weg gaat.
Ik zou zeggen dat de P4 'in theorie' de beste CPU is... maar in de praktijk dus (nog?) niet.

Om terug te komen op de G4/G5... die hebben die zwakheden dus niet... en dat komt voor een groot deel doordat de instructieset veel moderner is. Dat trekt mij aan de PPC-architectuur. Het is heel elegant, en erg efficient. Iets dat een x86 nooit kan worden.

[ Voor 17% gewijzigd door Verwijderd op 14-02-2005 02:30 ]

[bolleh]

Verwijderd schreef op maandag 14 februari 2005 @ 02:22:
Ik wil ook graag even inhaken op de CPU-technische discussie...
Ten eerste, over die 386... Die kan NOOIT meer dan 1 instructie per clk halen, omdat ie niet superscalar is. Verder heeft ie al moeite om instructies binnen 1 clk af te werken omdat ie maar een hele beperkte pipeline heeft (ik dacht alleen maar 1 extra stage voor de instructie fetch).
De 486 kan wel instructies binnen 1 clk doen... en de Pentium had dus 2 pipelines (superscalar) en kon dus 2 instructies tegelijk uitvoeren, en dat binnen 1 clk, dus maximaal 2 instructies per clk. De PII/PIII/P4/Athlon zouden in theorie maximaal 3 instructies per clk kunnen halen, ongeveer.
Maar die CPUs werken niet meer volgens de normale superscalar architectuur zoals de Pentium. Bij de Pentium had je 2 pipelines die synchroon liepen... Tegenwoordig heb je zogenaamde 'ports'. Die ports kunnen volstrekt onafhankelijk van elkaar opereren, en maken ook out-of-order executie mogelijk. De PowerPCs werken ook ongeveer op deze manier.

Verder is het IPC-verhaal niet zo heel nuttig, omdat je vergelijkt tussen twee verschillende instructiesets. De PowerPC heeft veel meer registers dan de x86, en de instructies hebben 3 operands ipv 2. In het algemeen kun je dus met minder instructies hetzelfde bereiken. Dus zelfs bij gelijke IPC zou een PPC sneller kunnen zijn (maar je kunt vast ook situaties bedenken waarin het omgekeerde geldt). De complexe instructies van de x86 kun je eigenlijk ook niet meer gebruiken. Zoals al werd opgemerkt, zijn het eigenlijk ook RISC-processors geworden, er zit alleen een soort 'vertalertje' op geschroefd. De eerder genoemde 'ports' zijn in feite RISC-units.
Complexe instructies worden opgebroken in zogenaamde micro-ops... dat zijn zeg maar de instructies van de RISC-units. Hoewel je dus met x86 vaak code in zeer weinig instructies kunt opschrijven, als je de complexe instructies gebruikt, is dit in de praktijk niet sneller, omdat je nog steeds net zoveel micro-ops moet verwerken. Sterker nog, vaak is het langzamer... ten eerste omdat je meestal op meer micro-ops uitkomt dan wanneer je het schrijft met code die 1:1 naar micro-ops vertaalt... en ten tweede omdat het decoderen van complexe instructies vaak langer duurt dan de 1:1 instructies. Dus eigenlijk moet je moderne x86 processors opvatten als RISC-processors, en alleen RISC-achtige code schrijven, en de complexe instructies mijden (als we nog lang met x86 doorgaan, vermoed ik dat uiteindelijk de complexe instructies uit de hardware verdwijnen, en door software-emulatie vervangen worden... Dit is met oa de IBM POWER-architectuur en de Motorola 68060 ook gedaan. Het voordeel is dat de hardware simpeler wordt, en dus sneller).

En natuurlijk zijn de mensen van het Apple-filmpje zo slim geweest om beide pipelines op dezelfde snelheid te laten werken. Dat demonstreert dus wel leuk waarom de kortere pipeline op dezelfde snelheid sneller klaar is... maar in werkelijkheid is de langere pipeline natuurlijk ontwikkeld om de CPU op een hogere snelheid te laten werken, en dan kan het er best wel eens heel anders uit zien. Zoals je kunt zien in het filmpje, zijn (fout voorspelde) branches de reden waarom er verschil optreedt... bij veel branches wint een korte pipeline dus makkelijk... bij weinig of geen branches wint de lange pipeline.
En het leuke aan programmeren is dat je alles op 483928430232 verschillende manieren kunt implementeren. Het is dus heel goed mogelijk om programma's te herschrijven met minder of zelfs geen branches. Dat is ook een beetje de makke van de P4. Op zich doet de P4 qua IPC niet veel onder voor een Athlon. Maar hij is dus niet goed met branches... Met audio/video encoding en dergelijke zie je dat dus... Daar zitten sowieso niet zo veel branches in, en de code is vaak geoptimaliseerd voor P4, en dan is er geen houden aan. Maar een hoop software is nog niet herschreven voor de P4, en met het uitvoeren van 'oude code' is de P4 gewoon zwak (ook met x87 code trouwens).

Ik vind het zelf wel jammer dat de P4 niet helemaal uit de verf is gekomen... Uit puur technisch oogpunt vind ik de architectuur erg indrukwekkend en vooruitstrevend. Maar ik weet niet of we ooit gaan zien dat alle software puur voor P4 geoptimaliseerd wordt... In dat geval blijft Intel compleet afhankelijk van het opschalen van de kloksnelheid, ter compensatie van de zwakheden van de P4, in plaats van dat de software die zwakheden uit de weg gaat.
Ik zou zeggen dat de P4 'in theorie' de beste CPU is... maar in de praktijk dus (nog?) niet.

Om terug te komen op de G4/G5... die hebben die zwakheden dus niet... en dat komt voor een groot deel doordat de instructieset veel moderner is. Dat trekt mij aan de PPC-architectuur. Het is heel elegant, en erg efficient. Iets dat een x86 nooit kan worden.

je verhaal van optimaliseren klopt wel een beetje. en dat is een beetje de makke van intel.

ze hebben goede ideeen maar een hoop werk moet opnieuw gedaan worden. dit betekent echter niet dat het daarom minder goed is. imho is de IA-64/Itanium de beste cpu die de laatste paar jaar is ontworpen. probleem is wel weer dat een hoop software overgezet moet worden en dat gaat niet 1-2-3 helaas. amd springt daar slim op in met zn x86-64 etc. maar je kan de x86 architectuur niet blijven doorontwikkelen. dat heeft intel goed voorzien, nu is het imho wachten op het moment dat x86 gedag wordt gezegd.

om sneller te gaan moet je soms helemaal opnieuw beginnen. zeker als je beseft dat de basis van de huidige processors gewoon al 15-20 jaar oud is. je kan nou eenmaal niet continue door blijven gaan

[Verwijderd]

bolleh schreef op maandag 14 februari 2005 @ 02:36:
[...]

je verhaal van optimaliseren klopt wel een beetje. en dat is een beetje de makke van intel.

Pfft... typ ik zo'n heel verhaal, en dan 'klopt het wel een beetje'

Maar ik wou nog even toevoegen dat, ironisch genoeg, de Pentium Pro (en dus later PII/PIII en P-M) juist ontworpen was om 'slechte' code goed te laten lopen.
Het probleem was namelijk dat de Pentium dus wel die 2 instructies per clk kon doen... maar dat kon alleen als die 2 instructies niet van elkaar afhankelijk waren.. omdat de pipelines strict synchroon werkten.
Omdat er bij de meeste code geen rekening mee was gehouden (voor 386/486 bestond dit 'probleem' nog helemaal niet), en omdat het lastig bleek om compilers te maken die echt efficiente code konden genereren voor de Pentium, had Intel er dus voor gekozen om dan de processor zelf maar de code te laten uitvoeren in een (redelijk) optimale volgorde... de zogenaamde out-of-order execution dus.

ze hebben goede ideeen maar een hoop werk moet opnieuw gedaan worden. dit betekent echter niet dat het daarom minder goed is. imho is de IA-64/Itanium de beste cpu die de laatste paar jaar is ontworpen. probleem is wel weer dat een hoop software overgezet moet worden en dat gaat niet 1-2-3 helaas. amd springt daar slim op in met zn x86-64 etc. maar je kan de x86 architectuur niet blijven doorontwikkelen. dat heeft intel goed voorzien, nu is het imho wachten op het moment dat x86 gedag wordt gezegd.

Er is hulp uit een andere hoek: .NET/Java.
Met statisch compileren heb je dus twee problemen: ten eerste draait de binary alleen op de instructieset waarvoor ie gecompiled is... en ten tweede is de binary alleen geoptimaliseerd voor de processor waarvoor ie gecompiled is.

Met .NET/Java compileer je dus pas op de machine waarop de code moet draaien. De instructieset is dan niet meer van belang, als er maar een compiler (virtual machine dus) geinstalleerd is. En als je toch gaat compilen, kun je meteen optimaliseren voor de juiste processor.
Het had mooi geweest als .NET nu al redelijk geaccepteerd was. Dan zou alle .NET software meteen draaien op x86, x86-64 en Itanium (en alle andere systemen waarvoor .NET beschikbaar is). Nu wordt de Itanium daar dus de dupe van. Omdat die met x86-compatibiliteit niet kan meekomen met de x86-64, en omdat er nauwelijks native software is, zal ie nooit populair worden, hoe goed de CPU ook is.
En de gebruiker wordt er ook min of meer de dupe van, omdat we nu van alle software 32 bit en 64 bit versies gaan krijgen, wat allemaal onnodige verwarring met zich meebrengt.

Java heb ik al afgeschreven, dat heeft het niet waar kunnen maken, mede door wanbeleid van Sun, als je het mij vraagt (dat gezeur over de MS JVM bijvoorbeeld was het stomste wat ze konden doen... geen standaard Java-ondersteuning in Windows is natuurlijk dodelijk voor het Java platform geweest).
Ik heb er wel vertrouwen in dat Microsoft .NET wel aan de man weet te brengen (niet goedschiks, dan wel kwaadschiks). En misschien krijgen we dan eindelijk een toekomst waarin we vrij onze CPU kunnen kiezen, zonder daarbij na te hoeven denken over het software-aanbod.

Het lijkt me ook wel ideaal als die CPUs eenmaal vrij te kiezen zijn... Dan kunnen er verschillende CPUs ontwikkeld worden, die geoptimaliseerd zijn voor bepaalde taken (media-encoding, servers, etc), zonder dat daarbij concessies aan het ontwerp gedaan hoeven worden door die vervelende x86 instructieset.

In feite is de videokaart-industrie wat dat betreft ver vooruit... Sinds de eeste programmeerbare shaders, hebben ze een dynamische compile-strategie aangehouden. Je programmeert de shaders in een universele meta-taal, en de driver is verantwoordelijk voor het compilen naar de daadwerkelijke hardware. De fabrikant is hier dus vrij om z'n eigen instructieset te maken die ideaal is voor de hardware. En de gebruiker merkt er niets van of hij nou een ATi of een NVIDIA kaart gebruikt... Het compilen en optimaliseren van de shaders is compleet transparant... de gebruiker merkt er niets van, en de software werkt prima.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 03:01:
[...]
En misschien krijgen we dan eindelijk een toekomst waarin we vrij onze CPU kunnen kiezen, zonder daarbij na te hoeven denken over het software-aanbod.

Het lijkt me ook wel ideaal als die CPUs eenmaal vrij te kiezen zijn... Dan kunnen er verschillende CPUs ontwikkeld worden, die geoptimaliseerd zijn voor bepaalde taken (media-encoding, servers, etc), zonder dat daarbij concessies aan het ontwerp gedaan hoeven worden door die vervelende x86 instructieset.

Tja, als dat moet afhangen van .NET en Microsoft dan bedank ik graag voor dit zogenaamde gemak. Om het nog maar niet te hebben over de performance nadelen van een (eventueel veredeld) interpreter systeem...

En om de relatieve mislukking van Java te wijten aan Sun is ook een beetje flauw, omdat Microsoft zoals zovaak de standaard naar eigen hand probeerde te zetten. En Microsoft standaarden zijn per definitie beperkend voor anderen. Wat voor bezwaar was er nu voor Microsoft om gewoon de Sun Java machine mee te leveren, behalve dat het niet hun eigen product was?

[ Voor 19% gewijzigd door Luke_msx op 14-02-2005 08:42 ]

[bolleh]

Verwijderd schreef op maandag 14 februari 2005 @ 03:01:
In feite is de videokaart-industrie wat dat betreft ver vooruit... Sinds de eeste programmeerbare shaders, hebben ze een dynamische compile-strategie aangehouden. Je programmeert de shaders in een universele meta-taal, en de driver is verantwoordelijk voor het compilen naar de daadwerkelijke hardware. De fabrikant is hier dus vrij om z'n eigen instructieset te maken die ideaal is voor de hardware. En de gebruiker merkt er niets van of hij nou een ATi of een NVIDIA kaart gebruikt... Het compilen en optimaliseren van de shaders is compleet transparant... de gebruiker merkt er niets van, en de software werkt prima.

mwoah, vergeet dan niet de fouten die zij ook hebben gemaakt, ati en nvidia dan. door hun eigen instructies te maken die weer niet compatible zijn met de concurrent maar helaas niet gebruikt worden. maarja videokaarten worden ook vaak in een strict direct X plan ontworpen, ze doen er alles voor om als eerste direct X 10 compatible te zijn, alles te ondersteunen.

probleem is dan wel dat je het gevaar loopt dat je de vooruitgang remt. de ontwerpers hebben immers niet echte vrijheid en dat kan op den duur nadelig zijn voor de snelheid

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 08:39:
[...]


Tja, als dat moet afhangen van .NET en Microsoft dan bedank ik graag voor dit zogenaamde gemak. Om het nog maar niet te hebben over de performance nadelen van een (eventueel veredeld) interpreter systeem...

Hier word ik toch zo moe van he...
Waarom denken mensen nog steeds dat Java/.NET etc interpreters zijn?
Waarom wordt het altijd met emulatie geassocieerd, en emulatie met interpreters, en interpreters met slechte performance?
Alsjeblieft zeg... Interpreters, dat is jaren-70-technologie. We zijn al veel en veel verder.
Ik wil dan altijd graag naar het HP Dynamo project verwijzen. Dat is een PA-RISC systeem dat zichzelf 'emuleert' dmv een dynamische compiler. Ze halen daarmee tot 25% performance-winst ten opzichte van de beste statische compilers voor PA-RISC.
Een dynamische compiler voor .NET of Java is niet veel anders, dus het is heel goed mogelijk om daar ook snellere code te genereren dan statische compileres dat kunnen. Er zijn zelfs al benchmarks te vinden van Java die dat in sommige gevallen ook doen.

En om de relatieve mislukking van Java te wijten aan Sun is ook een beetje flauw, omdat Microsoft zoals zovaak de standaard naar eigen hand probeerde te zetten. En Microsoft standaarden zijn per definitie beperkend voor anderen. Wat voor bezwaar was er nu voor Microsoft om gewoon de Sun Java machine mee te leveren, behalve dat het niet hun eigen product was?

Zeker alleen van horen zeggen? Ik heb zelf jarenlang Java ontwikkeld, en ik ben op een bugje hier en daar (dat later gefixt was) nooit iets tegengekomen dat niet op de MS JVM werkt, en wel op de Sun JVM... Dus voor zover ik weet, is de MS JVM gewoon prima compatible met de Java-standaard. Dat er extra extensies op zitten... ja dat is niet relevant. Zolang je die niet gebruikt, is het gewoon puur Java. Grappig genoeg is de MS JVM nog steeds sneller dan de Sun JVM op mijn code, hoewel MS al lang niet meer ontwikkelt.
De vraag is dus meer: wat voor bezwaar was er nu voor Sun om deze snelle JVM niet mee te laten leveren? En ze hadden natuurlijk kunnen verwachten dat MS dan maar helemaal geen JVM meelevert.
Maar goed, het resultaat is duidelijk. Java heeft een flinke deuk opgelopen.

[Verwijderd]

bolleh schreef op maandag 14 februari 2005 @ 11:50:
[...]

probleem is dan wel dat je het gevaar loopt dat je de vooruitgang remt. de ontwerpers hebben immers niet echte vrijheid en dat kan op den duur nadelig zijn voor de snelheid

Ik zie het juist andersom. Bij CPUs hebben ontwerpers niet echte vrijheid... Ze MOETEN x86 implementeren. En zoals we al jaren weten, is x86 waardeloos verouderd. Het is al decennia lang nadelig voor de snelheid. Als je kijkt naar CPUs als de Itanium, de G4/G5, de Alpha, en dergelijke... dan mag het duidelijk zijn dat de x86 nadelig is voor de snelheid.
Als we over gaan op .NET, dan zijn we tenminste van het x86-gebeuren af, en hebben de ontwerpers vrijheid om een instructieset te ontwikkelen die geschikt is voor de huidige technologie, en niet de technologie van de jaren 70.

[CyBeR]

Verwijderd schreef op maandag 14 februari 2005 @ 12:39:
[...]


De vraag is dus meer: wat voor bezwaar was er nu voor Sun om deze snelle JVM niet mee te laten leveren? En ze hadden natuurlijk kunnen verwachten dat MS dan maar helemaal geen JVM meelevert.
Maar goed, het resultaat is duidelijk. Java heeft een flinke deuk opgelopen.

Die extensies van MS zijn exact het probleem. MS denkt dat ze het product 'wel even beter zullen maken'. Op zich een nobel streven, maar ze sturen vervolgens de verbeteringen niet terug naar Sun. Daardoor krijg je dat je een bepaalde VM (die van MS) nodig hebt om bepaalde apps te draaien. En dat is nu juist 't punt van java, dat dat niet hoeft.

Een soortgelijk probleem zie je ook met IE. Microsoft heeft daar allerlei extra nonstandaard meuk in zitten en meuk die wel in de standaard bestaat maar daar van afwijkt. Zodanig is er nu een groot aantal websites dat gewoon niet of brak werkt in andere browsers dan IE, terwijl HTML op zich (als opmaaktaal) zo onafhankelijk zou moeten zijn als de pest.

[Verwijderd]

CyBeR schreef op maandag 14 februari 2005 @ 12:47:
[...]


Die extensies van MS zijn exact het probleem. MS denkt dat ze het product 'wel even beter zullen maken'. Op zich een nobel streven, maar ze sturen vervolgens de verbeteringen niet terug naar Sun. Daardoor krijg je dat je een bepaalde VM (die van MS) nodig hebt om bepaalde apps te draaien. En dat is nu juist 't punt van java, dat dat niet hoeft.

Een soortgelijk probleem zie je ook met IE. Microsoft heeft daar allerlei extra nonstandaard meuk in zitten en meuk die wel in de standaard bestaat maar daar van afwijkt. Zodanig is er nu een groot aantal websites dat gewoon niet of brak werkt in andere browsers dan IE, terwijl HTML op zich (als opmaaktaal) zo onafhankelijk zou moeten zijn als de pest.

In beide gevallen is het antwoord simpel (helaas voor de anti-MS mensen onder ons): als de ontwikkelaars willen dat hun code overal werkt, is het aan hun om ervoor te zorgen dat ze dus niet die extensies gebruiken.
Kennelijk willen niet alle ontwikkelaars dat. Blijkbaar zijn de voordelen van die extensies groter dan de nadelen... En met het marktaandeel van Windows kan ik dat wel begrijpen.
Ik ontwikkel zelf ook meestal Windows-only applicaties... Waarom porten naar andere OSen als er toch niemand is die ze gebruikt? Ligt maar net aan je doelgroep. Ik maak het dan liever zo goed mogelijk voor Windows.

[CyBeR]

Verwijderd schreef op maandag 14 februari 2005 @ 13:32:
[...]


In beide gevallen is het antwoord simpel (helaas voor de anti-MS mensen onder ons): als de ontwikkelaars willen dat hun code overal werkt, is het aan hun om ervoor te zorgen dat ze dus niet die extensies gebruiken.
Kennelijk willen niet alle ontwikkelaars dat. Blijkbaar zijn de voordelen van die extensies groter dan de nadelen... En met het marktaandeel van Windows kan ik dat wel begrijpen.
Ik ontwikkel zelf ook meestal Windows-only applicaties... Waarom porten naar andere OSen als er toch niemand is die ze gebruikt? Ligt maar net aan je doelgroep. Ik maak het dan liever zo goed mogelijk voor Windows.

Dat geldt ook maar 25% van de tijd. Het grootste deel van de mensen die van dergelijke extensies gebruik maakt is namelijk onder te brengen in de categorie prutser-die-niet-beter-weet. Sorry, maar zo is 't nu eenmaal. Als jij van dergelijke extensies gebruik wilt maken, wetend dat 't dan niet meer buiten Windows werkt (en waarom prog je dan nog in java?) is dat jouw keus natuurlijk, maar er schuilt een gevaar in dat minder ervaren programmeurs de extensies gebruiken omdat ze denken dat die overal werken.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 13:32:
[...]


In beide gevallen is het antwoord simpel (helaas voor de anti-MS mensen onder ons): als de ontwikkelaars willen dat hun code overal werkt, is het aan hun om ervoor te zorgen dat ze dus niet die extensies gebruiken.

En de praktijk leert dat het streven van Microsoft om zoveel mogelijk gebruikers afhankelijk te maken van MS dus prima werkt... Ofwel, door incompatibiliteit te creëren heeft Microsoft Java beschadigd(wat natuurlijk ook precies de bedoeling was...), niet Sun. Wel even realistisch blijven.

Hoeveel websites zijn er niet die alleen maar werken op IE, terwijl er mogelijkheden genoeg zijn om een website er op elke browser gelijk uit te laten zien? Daar zie je namelijk precies hetzelfde verschijnsel waar MS een prima standaard vakkundig om zeep heeft geholpen puur en alleen om er zelf beter van te worden.

Kennelijk willen niet alle ontwikkelaars dat. Blijkbaar zijn de voordelen van die extensies groter dan de nadelen... En met het marktaandeel van Windows kan ik dat wel begrijpen.

Tja, nogmaals, precies wat Microsoft graag wil dus: de concurrentie het bestaan onmogelijk maken door bestaande standaarden om te buigen zodat ze Windows-only worden. Op een hele misselijke manier ook nog wel.

Ik ontwikkel zelf ook meestal Windows-only applicaties... Waarom porten naar andere OSen als er toch niemand is die ze gebruikt? Ligt maar net aan je doelgroep. Ik maak het dan liever zo goed mogelijk voor Windows.

Tja, en welk voordeel heb je dan nog bij het gebruiken van Java? Waarom dan niet gewoon een native Win32 applicatie schrijven? Is nog stukken sneller ook...

[ Voor 23% gewijzigd door Luke_msx op 14-02-2005 13:57 ]

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 12:43:
[...]


Ik zie het juist andersom. Bij CPUs hebben ontwerpers niet echte vrijheid... Ze MOETEN x86 implementeren. En zoals we al jaren weten, is x86 waardeloos verouderd. Het is al decennia lang nadelig voor de snelheid. Als je kijkt naar CPUs als de Itanium, de G4/G5, de Alpha, en dergelijke... dan mag het duidelijk zijn dat de x86 nadelig is voor de snelheid.
Als we over gaan op .NET, dan zijn we tenminste van het x86-gebeuren af, en hebben de ontwerpers vrijheid om een instructieset te ontwikkelen die geschikt is voor de huidige technologie, en niet de technologie van de jaren 70.

Nee inderdaad, niet meer gebonden aan technologie uit de jaren 70. Maar in plaats daarvan gebonden aan technologie die ons is opgedrongen door een monopolist die al jaren zijn uiterste best doet om zijn concurrentie de toegang tot de vrije markt af te sluiten. Een hele vooruitgang...

Wat dat betreft zou het dus nog steeds beter te zijn om over te gaan op de Java versie van Sun(!); daarmee ben je in ieder geval echt platformonafhankelijk.

Overigens geloof ik sowieso niet zo in dit soort oplossingen, vooralsnog vind ik de performance ervan nog niet geweldig. Nogal verspilling van CPU capaciteit om on the fly te compileren...

[ Voor 16% gewijzigd door Luke_msx op 14-02-2005 14:01 ]

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 13:48:
[...]

Tja, en welk voordeel heb je dan nog bij het gebruiken van Java? Waarom dan niet gewoon een native Win32 applicatie schrijven? Is nog stukken sneller ook...

Ik zei niet dat mijn Java applicaties Windows-only waren.
Ik zei dat ik meestal Windows-only applicaties ontwikkel.
Ik gebruik Java juist als het overal moet werken.
En stukken sneller? Dat hangt er maar vanaf. Met bv string processing is Java heel erg snel, daar kan portable C code vaak nog een puntje aan zuigen. Het ligt er allemaal maar net aan wat je moet programmeren... en vaak ook hoe je het programmeert. Als je Java op de juiste manier gebruikt, kan het best heel snel zijn, soms zelfs sneller dan C oid. En meestal is snelheid toch niet relevant meer. De meeste mensen hebben meer dan 1 GHz tegenwoordig... Dat is veel te veel voor de meeste simpele taken. Als je code dan iets trager is, dan geeft dat helemaal niet, dat merkt toch niemand.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 13:53:
[...]


Nee inderdaad, niet meer gebonden aan technologie uit de jaren 70. Maar in plaats daarvan gebonden aan technologie die ons is opgedrongen door een monopolist die al jaren zijn uiterste best doet om zijn concurrentie de toegang tot de vrije markt af te sluiten. Een hele vooruitgang...

Als je verwacht dat ik hier serieus op in ga, dan heb je het fout.
Ik heb liever technische discussies.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 14:08:
[...]


Als je verwacht dat ik hier serieus op in ga, dan heb je het fout.
Ik heb liever technische discussies.

Prima; maar vergeet dan niet dat als de wereld op grote schaal kiest voor .NET we in de toekomst geen technische discussies meer hoeven hebben omdat alle keuzes dan al voor ons gemaakt zijn.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 14:06:
[...]

Dat is veel te veel voor de meeste simpele taken. Als je code dan iets trager is, dan geeft dat helemaal niet, dat merkt toch niemand.

Tja, ziehier de mentaliteit van de moderne programmeur. Waar is de tijd gebleven dat je als programmeur de maximale performance uit je programma wilde halen? Door dit soort ideeën wordt moderne hardware dus nooit ten volle benut en dat is doodzonde...

[CyBeR]

jalumsx schreef op maandag 14 februari 2005 @ 14:15:
[...]


Tja, ziehier de mentaliteit van de moderne programmeur. Waar is de tijd gebleven dat je als programmeur de maximale performance uit je programma wilde halen? Door dit soort ideeën wordt moderne hardware dus nooit ten volle benut en dat is doodzonde...

En bovendien heeft niet iedereen dergelijk snelle procs. En daardoor krijg je nu dat dingen als tekstverwerkers met systeemrequirements komen van 500MHz+ en 256MB ram enzo. (Niet accuraat waarschijnlijk, maar you get the point). En dat alles om wat tekst te kunnen manipuleren.

[chem]

jalumsx schreef op maandag 14 februari 2005 @ 14:15:
[...]


Tja, ziehier de mentaliteit van de moderne programmeur. Waar is de tijd gebleven dat je als programmeur de maximale performance uit je programma wilde halen? Door dit soort ideeën wordt moderne hardware dus nooit ten volle benut en dat is doodzonde...

Een programmeur per uur is veel duurder dan snellere hardware... tenzij je echt tegen grenzen aanloopt is het vaak goedkoper om duurdere hardware te nemen dan een programmeur door te laten werken.

[Luke_msx]

chem schreef op maandag 14 februari 2005 @ 14:21:
[...]

Een programmeur per uur is veel duurder dan snellere hardware... tenzij je echt tegen grenzen aanloopt is het vaak goedkoper om duurdere hardware te nemen dan een programmeur door te laten werken.

Dat gaat op als je het over maatwerk hebt. Maar als je spreekt over grote applicaties als bijvoorbeeld een Office pakket dan mag dat wat mij betreft minder meespelen; je wilt tenslotte zoveel mogelijk mensen bedienen met je software en dus de systeemeisen zo laag mogelijk hebben.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 14:12:
[...]

Prima; maar vergeet dan niet dat als de wereld op grote schaal kiest voor .NET we in de toekomst geen technische discussies meer hoeven hebben omdat alle keuzes dan al voor ons gemaakt zijn.

Wat is precies het verschil met nu? Nu gebruiken we voornamelijk x86, en daar heeft Intel alle keuzes al voor ons gemaakt. En bij Java heeft Sun de keuzes al gemaakt.
Dus... ofwel je bent inconsequent, en hebt gewoon iets tegen Microsoft... of je moet toegeven dat er in feite niets verandert, behalve dat MS het vaandel van Intel overneemt. En Intel is nou niet bepaald minder monopolist dan MS.

En als we naar D3D kijken, kunnen we zien dat MS helemaal niet zo'n onderdrukker is. MS nodigt om de zoveel tijd de grote spelers op de grafische markt uit, en samen ontwikkelen ze de volgende D3D-standaard. Bij .NET zou het net zo kunnen gaan. Dat om de zoveel tijd de bytecode vernieuwd wordt, om mee te kunnen blijven gaan in de technische ontwikkelingen.
In dat geval kunnen we dus voor het eerst sinds jaren juist weer WEL de technische discussie aan gaan, waar voorheen x86 al vaststond, en discussie niet mogelijk was.

[bartvb]

@jalumsx: Klopt. Maar als je b.v. iets als OpenOffice wilt bouwen met alleen C met een berg assembly om het allemaal snel te houden en daarnaast ook nog zo min mogelijk libraries gebruikt en allerlei abstraction layers om de programmeur af te schermen van de hardware of het OS dan ben je sowieso een paar keer langer bezig en dan heb je ook enorme problemen met de portabiliteit.

Tegenwoordig heeft iedereen een machine met een paar honder Mhz en een paar honderd MB geheugen, dus waarom zou je dan moeilijk gaan doen met assembler e.d. om het allemaal wat sneller en efficienter te krijgen? Jij bent een paar jaar bezig voor een relatief eenvoudige app, de concurrent (met wat hogere systeemeisen) heeft na een paar maanden al een soortgelijk product af met nog meer functionaliteit ook. OK, het is misschien wat langzamer en wat groter dan jouw super geoptimaliseerde pakket maar het pakket van de concurrent is nog in deze eeuw te gebruiken

Maar goed, dat is allemaal behoorlijk offtopic IMO

@ddbruijn: Heb jij al D3D gezien op andere platformen dan wintel? Nee? Ik ook niet Of ja, er zijn wat OS developers bezig met het porten van wat D3D spul dacht ik maar die worden nou niet bepaald geholpen door MS...

[ Voor 11% gewijzigd door bartvb op 14-02-2005 14:47 ]

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 14:15:
[...]


Tja, ziehier de mentaliteit van de moderne programmeur. Waar is de tijd gebleven dat je als programmeur de maximale performance uit je programma wilde halen? Door dit soort ideeën wordt moderne hardware dus nooit ten volle benut en dat is doodzonde...

Als je mij zou kennen, zou je weten dat dit niet mijn mentaliteit is... Sterker nog, als je mijn post goed had gelezen, zou je zien dat ik JUIST zei dat je de maximale performance uit je programma moet halen. En lees ook nog maar eens de info rond het HP Dynamo project door, als we het toch hebben over het ten volle benutten van moderne hardware.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 14:40:
[...]


Wat is precies het verschil met nu? Nu gebruiken we voornamelijk x86, en daar heeft Intel alle keuzes al voor ons gemaakt.

Maar ik kan wel vrijelijk kiezen voor een AMD machine of zelfs voor een Mac met een PowerPC etc. Met .NET ben je automatisch met handen en voeten gebonden aan MS.

En bij Java heeft Sun de keuzes al gemaakt.

Sun Java is voor een heleboel platformen beschikbaar. Niet alleen voor MS of x86. Slechte vergelijking dus.

Dus... ofwel je bent inconsequent, en hebt gewoon iets tegen Microsoft... of je moet toegeven dat er in feite niets verandert, behalve dat MS het vaandel van Intel overneemt. En Intel is nou niet bepaald minder monopolist dan MS.

Zoals je al kon lezen ben ik dus die niet met je eens. En ja, ik heb wel iets tegen MS inderdaad; niet tegen het bedrijf op zich maar wel tegen de manier waarop ze keer of keer proberen de concurrentie het bestaan onmogelijk te maken; en niet door zulke goede producten te maken maar door alternatieve producten het bestaan ACTIEF onmogelijk te maken

En als we naar D3D kijken, kunnen we zien dat MS helemaal niet zo'n onderdrukker is. MS nodigt om de zoveel tijd de grote spelers op de grafische markt uit, en samen ontwikkelen ze de volgende D3D-standaard. Bij .NET zou het net zo kunnen gaan. Dat om de zoveel tijd de bytecode vernieuwd wordt, om mee te kunnen blijven gaan in de technische ontwikkelingen.
In dat geval kunnen we dus voor het eerst sinds jaren juist weer WEL de technische discussie aan gaan, waar voorheen x86 al vaststond, en discussie niet mogelijk was.

En hoe is D3D beschikbaar voor andere platformen dan Windows? Juist. En .NET? Juist. Dus helpt .NET ons van de regen in de drup, en eigenlijk is de drup in dit geval nog erger dan de regen...

[ Voor 9% gewijzigd door Luke_msx op 14-02-2005 15:03 ]

[Verwijderd]

Je dwaalt helemaal af. Het gaat helemaal niet om software, en dus al zeker niet om MS vs de wereld, hoe graag je het daar zelf ook over wilt hebben.
Ik wil je nog wel even wijzen op www.macdx.com, op het Mono project, de FreeBSD omgeving voor .NET, en het feit dat .NET gebaseerd is op open standaarden die iedereeen vrij mag implementeren, om je een idee te geven over hoe fout je zit met MS/Windows/x86-only.

Nogmaals, het gaat om de hardware-platformen, en hoe je code op verschillende platformen (optimaal) kunt laten draaien. Dat geleuter over D3D dat alleen op Windows (en Mac dus) draaait is compleet niet relevant, en is niets meer of minder dan een anti-MS troll.

[ Voor 25% gewijzigd door Verwijderd op 14-02-2005 17:22 ]

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 16:45:
Je dwaalt helemaal af. Het gaat helemaal niet om software, en dus al zeker niet om MS vs de wereld, hoe graag je het daar zelf ook over wilt hebben.
Ik wil je nog wel even wijzen op www.macdx.com, op het Mono project, de FreeBSD omgeving voor .NET, en het feit dat .NET gebaseerd is op open standaarden die iedereeen vrij mag implementeren, om je een idee te geven over hoe fout je zit met MS/Windows/x86-only.

Nogmaals, het gaat om de hardware-platformen, en hoe je code op verschillende platformen (optimaal) kunt laten draaien. Dat geleuter over D3D dat alleen op Windows (en Mac dus) draaait is compleet niet relevant, en is niets meer of minder dan een anti-MS troll.

Vertel eens, hoeveel medewerking krijgen de makers van die projecten van Microsoft? Laat maar, ik weet het antwoord wel. Hoe je ook anders wilt doen geloven, het blijft een feit dat Microsoft dit soort projecten, die het moeten hebben van zorgvuldige reverse-engineering, altijd zal pogen te dwarsbomen. En het spijt me, jij mag het een troll noemen maar ik heb dagelijks genoeg met dergelijke praktijken van MS te maken om te weten hoe de vork bij dat bedrijf in de steel zit. Ik zie een door .NET gedomineerde software wereld dus ook absoluut niet zitten; Microsoft heeft wat mij betreft al zijn goodwill al lang geleden verspeeld.

Jij weet net zo goed als ik dat als dergelijke projecten in de ogen van MS té succesvol worden dat MS wel weer één of andere veiligheid heeft ingebouwd die dergelijke projecten het bestaan bemoeilijken. Wat dat betreft heeft de ervaring met Samba wel genoeg geleerd, lijkt me.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 19:03:
[...]


Vertel eens, hoeveel medewerking krijgen de makers van die projecten van Microsoft? Laat maar, ik weet het antwoord wel. Hoe je ook anders wilt doen geloven, het blijft een feit dat Microsoft dit soort projecten, die het moeten hebben van zorgvuldige reverse-engineering, altijd zal pogen te dwarsbomen. En het spijt me, jij mag het een troll noemen maar ik heb dagelijks genoeg met dergelijke praktijken van MS te maken om te weten hoe de vork bij dat bedrijf in de steel zit. Ik zie een door .NET gedomineerde software wereld dus ook absoluut niet zitten; Microsoft heeft wat mij betreft al zijn goodwill al lang geleden verspeeld.

Ten eerste gaat deze hele discussie hier niet over, zoals ik al eerder zei. Het gaat om het idee en de technologie achter .NET (en Java dus). Jammer dat .NET toevallig van MS is, zodat mensen als jij het weer nodig vinden om te gaan lopen zeiken over dingen die niets met de technologie zelf te maken hebben.
Ten tweede, zoals ik al eerder zei, is .NET op open standaarden gebaseerd, die iedereen vrij kan inzien, dus is er van reverse-engineering totaal geen sprake.
Je bent gewoon totaal niet geinformeerd, en je zit maar wat off-topic te blaten, omdat je toevallig ergens 'MS' leest, of iets wat daarmee te maken heeft. En dat is trollen ja.

Jij weet net zo goed als ik dat als dergelijke projecten in de ogen van MS té succesvol worden dat MS wel weer één of andere veiligheid heeft ingebouwd die dergelijke projecten het bestaan bemoeilijken. Wat dat betreft heeft de ervaring met Samba wel genoeg geleerd, lijkt me.

Samba is absoluut niet te vergelijken met .NET. Samba probeert een standaard te implementeren die NIET open is, en die NIET bedoeld is om op ieder platform vrij geimplementeerd te worden. Dat ze dan geen medewerking krijgen van MS is niet meer dan logisch. Het was helemaal nooit de bedoeling om SMB op andere systemen te laten werken.
Dat vind ik ook zo vervelend aan die opensource-kliek. Die mensen verwachten van iedereen belangeloze medewerking. Zo werkt de wereld nou eenmaal niet. En als je dat niet kunt verwerken, ga eens naar een psychiater ofzo, ipv hier off-topic te gaan lopen trollen.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 19:16:
[...]


Ten eerste gaat deze hele discussie hier niet over, zoals ik al eerder zei. Het gaat om het idee en de technologie achter .NET (en Java dus). Jammer dat .NET toevallig van MS is, zodat mensen als jij het weer nodig vinden om te gaan lopen zeiken over dingen die niets met de technologie zelf te maken hebben.

Toch wel; de naam Microsoft is nu eenmaal automatisch verbonden aan een bedrijf dat niets maar dan ook niets opheeft met open standaarden. En de technologie is desondanks vooral gebaat bij open standaarden.

Ten tweede, zoals ik al eerder zei, is .NET op open standaarden gebaseerd, die iedereen vrij kan inzien, dus is er van reverse-engineering totaal geen sprake.
Je bent gewoon totaal niet geinformeerd, en je zit maar wat off-topic te blaten, omdat je toevallig ergens 'MS' leest, of iets wat daarmee te maken heeft. En dat is trollen ja.

Sorry hoor, maar de praktijken van MS de afgelopen jaren hebben deze mening van mij gevormd. En dat heeft het bedrijf Microsoft zelf in de hand gewerkt, ik zal dat bedrijf nooit meer 100% vertrouwen. Wat mij betreft had je pas een punt als Microsoft zélf .NET ook uit zou brengen voor andere platforms, en dat doen ze dus niet. Wil je .NET gebruiken op een ander platform dan zul je eerst zelf moeten zorgen dat je je .NET implementatie geschreven hebt.
[...]

Samba is absoluut niet te vergelijken met .NET. Samba probeert een standaard te implementeren die NIET open is, en die NIET bedoeld is om op ieder platform vrij geimplementeerd te worden. Dat ze dan geen medewerking krijgen van MS is niet meer dan logisch. Het was helemaal nooit de bedoeling om SMB op andere systemen te laten werken.
Dat vind ik ook zo vervelend aan die opensource-kliek. Die mensen verwachten van iedereen belangeloze medewerking. Zo werkt de wereld nou eenmaal niet. En als je dat niet kunt verwerken, ga eens naar een psychiater ofzo, ipv hier off-topic te gaan lopen trollen.

Prima joh. Maarreh, ik verwacht helemaal geen belangeloze medewerking. Wel verwacht ik eerlijke concurrentie, en zodra Microsoft ergens bij betrokken is, is eerlijke concurrentie ver uit het zicht verdwenen. Vandaar dus ook dat ik een architectuur van MS die oorspronkelijk alleen bedacht is om Sun dwars te liggen niet bepaald als de heilige graal van de moderne technologie zie.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 19:39:
[...]


Toch wel; de naam Microsoft is nu eenmaal automatisch verbonden aan een bedrijf dat niets maar dan ook niets opheeft met open standaarden. En de technologie is desondanks vooral gebaat bij open standaarden.

Het ZIJN open standaarden, dus je zeurt.

Wat mij betreft had je pas een punt als Microsoft zélf .NET ook uit zou brengen voor andere platforms, en dat doen ze dus niet. Wil je .NET gebruiken op een ander platform dan zul je eerst zelf moeten zorgen dat je je .NET implementatie geschreven hebt.

Jammer dat je zo slecht leest.
Google eens op "Shared Source Common Language Infrastructure".
Hee, kijk eens aan, werkt op Windows, FreeBSD en Mac OS X!

Prima joh. Maarreh, ik verwacht helemaal geen belangeloze medewerking. Wel verwacht ik eerlijke concurrentie, en zodra Microsoft ergens bij betrokken is, is eerlijke concurrentie ver uit het zicht verdwenen. Vandaar dus ook dat ik een architectuur van MS die oorspronkelijk alleen bedacht is om Sun dwars te liggen niet bepaald als de heilige graal van de moderne technologie zie.

Objectief oordelen is niet je sterkste punt he?
En technisch heb je ook nog niet veel aan de discussie toegevoegd... Wat wil je eigenlijk bereiken met die posts van je... Je frustratie van je af schrijven?

[bolleh]

Verwijderd schreef op maandag 14 februari 2005 @ 12:43:
[...]


Ik zie het juist andersom. Bij CPUs hebben ontwerpers niet echte vrijheid... Ze MOETEN x86 implementeren. En zoals we al jaren weten, is x86 waardeloos verouderd. Het is al decennia lang nadelig voor de snelheid. Als je kijkt naar CPUs als de Itanium, de G4/G5, de Alpha, en dergelijke... dan mag het duidelijk zijn dat de x86 nadelig is voor de snelheid.
Als we over gaan op .NET, dan zijn we tenminste van het x86-gebeuren af, en hebben de ontwerpers vrijheid om een instructieset te ontwikkelen die geschikt is voor de huidige technologie, en niet de technologie van de jaren 70.

dat bedoelde ik dus ook te zeggen...

in mn voorbeeld moet de kaart dus direct x 10 compatible zijn, maar het gevaar van dat "moeten" is dat je dus hele nieuwe mogelijk goede ideeen mischien ondersneeuwt en daardoor veel snelheid mist

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 19:46:
[...]


Het ZIJN open standaarden, dus je zeurt.


[...]


Jammer dat je zo slecht leest.
Google eens op "Shared Source Common Language Infrastructure".
Hee, kijk eens aan, werkt op Windows, FreeBSD en Mac OS X!

Yep, en wie heeft die versie voor non Windows OS'en geschreven? Microsoft zelf? Nee dus. Welke garanties heb je dus op compatibiliteit? Wederom, geen.

Objectief oordelen is niet je sterkste punt he?
En technisch heb je ook nog niet veel aan de discussie toegevoegd... Wat wil je eigenlijk bereiken met die posts van je... Je frustratie van je af schrijven?

Sorry, maar iemand die een Microsoft techniek ophemelt die notabene ooit alleen maar bedacht is om een gevestigde standaard (Java) kapot te maken (de ENIGE reden dat .NET gedocumenteerd is is NATUURLIJK dat MS wist dat ze anders geen enkele voet aan de grond zouden krijgen met hun .NET) en dan een ander verwijt niet objectief te oordelen, tja...

Let maar op mijn woorden: MS zal vroeg of laat iets met .NET doen waardoor alle huidige alternatieven op slag niet of niet goed meer werken, zoals al zo vaak is gebeurd. Maar wel pas als iedereen .NET als defacto standaard heeft geaccepteerd. Als jij het vreemd vindt dat deze sentimenten bestaan in de software-community, dan zou jij eens moeten lezen over de geschiedenis van Microsoft en de manier waarop het bedrijf zijn monopoliepositie heeft bewerkstelligd. Ik vind het werkelijk ontstellend om te zien dat iemand die klaarblijkelijk thuis is in de materie desondanks zo gemakkelijk in de valkuilen van Microsoft trapt.

[ Voor 8% gewijzigd door Luke_msx op 14-02-2005 19:57 ]

[Verwijderd]

bolleh schreef op maandag 14 februari 2005 @ 19:52:
[...]

dat bedoelde ik dus ook te zeggen...

in mn voorbeeld moet de kaart dus direct x 10 compatible zijn, maar het gevaar van dat "moeten" is dat je dus hele nieuwe mogelijk goede ideeen mischien ondersneeuwt en daardoor veel snelheid mist

Ik denk niet dat je het begrijpt. DirectX schrijft geen instructieset voor, alleen een featureset. Hoe je die features implementeert, mag je zelf weten. En de featureset wordt samengesteld door de hardware-fabrikanten, in overleg met Microsoft. Dus alle goede ideeen zitten er meestal wel in. De standaard wordt ook iedere paar jaar grondig geupdate.
Als je die standaard niet had, dan zat je weer in het Glide-tijdperk... Voodoo-kaarten werkten leuk, maar de software werkte niet op andere kaarten, want die hadden geen Glide, maar andere standaarden. Dankzij DirectX hebben we dat probleem niet meer.

Bij .NET heb je hetzelfde... Je hoeft dan niet meer x86-compatible te zijn... Je CPU hoeft alleen maar 'ongeveer' zo te werken als .NET graag wil, verder ben je vrij om de hardware naar eigen inzicht te ontwerpen. En omdat de .NET features gebaseerd zijn op moderne programmeertalen als C++/Pascal/Java, zijn ze ideaal voor de meeste software.
We zien dus dat de redenering omgekeerd is. In de jaren 70, toen de x86 onworpen werd, was het idee om een zo krachtig mogelijke CPU te ontwerpen, en dan de code met de hand te schrijven.
Tegenwoordig is het niet meer te doen om alles met de hand te schrijven, dus is het logischer om naar de programmeertalen te kijken, en van daaruit de hardware te ontwikkelen die die code optimaal kan uitvoeren. Het gaat niet meer puur om de kracht van de CPU, maar om het teamwork tussen compiler en CPU. En daarin is x86 niet sterk.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 20:09:
[...]


Ik denk niet dat je het begrijpt. DirectX schrijft geen instructieset voor, alleen een featureset. Hoe je die features implementeert, mag je zelf weten. En de featureset wordt samengesteld door de hardware-fabrikanten, in overleg met Microsoft. Dus alle goede ideeen zitten er meestal wel in. De standaard wordt ook iedere paar jaar grondig geupdate.
Als je die standaard niet had, dan zat je weer in het Glide-tijdperk... Voodoo-kaarten werkten leuk, maar de software werkte niet op andere kaarten, want die hadden geen Glide, maar andere standaarden. Dankzij DirectX hebben we dat probleem niet meer.

Er bestond al een prima oplossing; die heette OpenGL. Maar nee, MS moest weer een eigen standaard bedenken, in plaats van een bestaande standaard te adopteren. Zo ook voor .NET, Java bestond al en werkte prima. Snap je nou echt mijn bezwaren niet tegen de werkwijze van MS?

[ Voor 3% gewijzigd door Luke_msx op 14-02-2005 20:15 ]

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 19:53:
[...]


Yep, en wie heeft die versie voor non Windows OS'en geschreven? Microsoft zelf? Nee dus. Welke garanties heb je dus op compatibiliteit? Wederom, geen.

Erm, die heeft Microsoft dus WEL geschreven. Heb je uberhaupt gezocht?

Sorry, maar iemand die een Microsoft techniek ophemelt die notabene ooit alleen maar bedacht is om een gevestigde standaard (Java) kapot te maken (de ENIGE reden dat .NET gedocumenteerd is is NATUURLIJK dat MS wist dat ze anders geen enkele voet aan de grond zouden krijgen met hun .NET) en dan een ander verwijt niet objectief te oordelen, tja...

Erm, of .NET ontworpen is om Java kapot te maken of niet, dat heeft weinig te maken met hoe goed .NET is. Als we objectief kijken, zien we dat Java en .NET qua techniek niet zo gek veel van elkaar verschillen, en dat .NET een aantal dingen te bieden heeft die de code efficienter kunnen maken dan in Java.
Om die reden vond ik het wel nuttig om zowel .NET als Java te noemen. Verder heb ik niet .NET opgehemeld, maar slechts het idee van dynamische compilatie als mooie oplossing genoemd voor snelle, hardware-onafhankelijke code, dat dus onder andere in .NET en Java toegepast wordt.
Ben je nu helemaal verblind door die anti-MS sympathieen dat je niet eens normaal de thread kunt volgen?

Let maar op mijn woorden: MS zal vroeg of laat iets met .NET doen waardoor alle huidige alternatieven op slag niet of niet goed meer werken, zoals al zo vaak is gebeurd. Maar wel pas als iedereen .NET als defacto standaard heeft geaccepteerd. Als jij het vreemd vindt dat deze sentimenten bestaan in de software-community, dan zou jij eens moeten lezen over de geschiedenis van Microsoft en de manier waarop het bedrijf zijn monopoliepositie heeft bewerkstelligd. Ik vind het werkelijk ontstellend om te zien dat iemand die klaarblijkelijk thuis is in de materie desondanks zo gemakkelijk in de valkuilen van Microsoft trapt.

Welke valkuilen? Je vergeet dat ik voornamelijk Windows-only code schrijf. Voor mij zijn er dus geen valkuilen, zolang het op Windows werkt, is het voor mij goed genoeg. Het gaat mij er alleen om dat ik graag andere CPUs zou willen gebruiken dan de x86.
Als Windows ooit z'n marktaandeel verliest, dan stap ik gewoon over op datgene wat dan gangbaar is.
Dus ik hoef ook helemaal niet paranoide te gaan doen, of te gaan zeuren over MS. Het interesseert mij weinig dat ze graag hun marktaandeel in stand willen houden. Het is voor mij wel handig, omdat ik gewoon Windows-only kan blijven ontwikkelen. Het zou een stuk lastiger zijn als er twee of drie ongeveer even grote spelers zouden zijn. Dan zou ik moeilijk moeten gaan doen om alles overal te laten werken, of accepteren dat ik bij voorbaat een groot deel van de markt uitsluit.
Dus nee, ik slaap 's nachts nog prima hoor, wat MS ook uitvoert. Ik vind mensen als jij een stuk vervelender dan wat MS al dan niet doet.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 20:09:
[...]

[...]

Tegenwoordig is het niet meer te doen om alles met de hand te schrijven, dus is het logischer om naar de programmeertalen te kijken, en van daaruit de hardware te ontwikkelen die die code optimaal kan uitvoeren. Het gaat niet meer puur om de kracht van de CPU, maar om het teamwork tussen compiler en CPU. En daarin is x86 niet sterk.

Hierover ben ik het roerend met je eens. Alleen denk ik dat de eisen aan de hardware niet door een enkele softwarefabrikant zou mogen worden bepaald; er zou een standaard besproken en besloten moeten worden door een grote groep van softwareontwikkelaars. Om hiermee voorgoed monopolievorming onmogelijk te maken.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 20:14:
[...]


Er bestond al een prima oplossing; die heette OpenGL. Maar nee, MS moest weer een eigen standaard bedenken, in plaats van een bestaande standaard te adopteren. Zo ook voor .NET, Java bestond al en werkte prima. Snap je nou echt mijn bezwaren niet tegen de werkwijze van MS?

Alsjeblieft zeg... DirectX is toch wel even heel iets anders dan OpenGL.
Als je er ook maar een beetje verstand van hebt, zie je dat DirectX op de feiten vooruitloopt, terwijl OpenGL achter de feiten aanloopt. Sterker nog, de laaste tijd lijken de extensies die aan OpenGL toegevoegd worden verdacht veel op wat DirectX al tijden heeft. Kijk maar eens naar dingen als render-to-texture, vertexbuffer objects, of fragment programs.
Ja, ik weet wel dat DirectX van MS is... maar ik ben objectief, en ik zie dat het gewoon beter is dan OpenGL (ja, Windows-only ja).
En .NET is ook toch wel even anders dan Java.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 20:21:
[...]


Alsjeblieft zeg... DirectX is toch wel even heel iets anders dan OpenGL.
Als je er ook maar een beetje verstand van hebt, zie je dat DirectX op de feiten vooruitloopt, terwijl OpenGL achter de feiten aanloopt. Sterker nog, de laaste tijd lijken de extensies die aan OpenGL toegevoegd worden verdacht veel op wat DirectX al tijden heeft. Kijk maar eens naar dingen als render-to-texture, vertexbuffer objects, of fragment programs.
Ja, ik weet wel dat DirectX van MS is... maar ik ben objectief, en ik zie dat het gewoon beter is dan OpenGL (ja, Windows-only ja).
En .NET is ook toch wel even anders dan Java.

DirectX is iets anders dan OpenGL ja. En inderdaad loopt OpenGL de laatste tijd achter DirectX aan. Omdat MS zijn Windows monopolie heeft misbruikt om OpenGL als standaard te verdringen.

Snap je nou mijn bezwaren niet of wil je ze niet snappen?

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 20:20:
[...]


Hierover ben ik het roerend met je eens. Alleen denk ik dat de eisen aan de hardware niet door een enkele softwarefabrikant zou mogen worden bepaald; er zou een standaard besproken en besloten moeten worden door een grote groep van softwareontwikkelaars. Om hiermee voorgoed monopolievorming onmogelijk te maken.

Als je je nu eens in de materie zou verdiepen, zou je kunnen vinden dat MS die standaard niet in z'n eentje bepaald heeft, net als bij DirectX. Bedrijven als Intel, HP, IBM en America Online hebben de standaard uitvoerig bestudeerd, en pas nadat iedereen hem heeft goedgekeurd, is de standaard officieel door de EMCA aangenomen.
Kortom, je ziet spoken, omdat je totaal niet weet waar het over gaat, en maar meteen het ergste aanneemt.

[Verwijderd]

jalumsx schreef op maandag 14 februari 2005 @ 20:27:
[...]


DirectX is iets anders dan OpenGL ja. En inderdaad loopt OpenGL de laatste tijd achter DirectX aan. Omdat MS zijn Windows monopolie heeft misbruikt om OpenGL als standaard te verdringen.

Snap je nou mijn bezwaren niet of wil je ze niet snappen?

Nee, ik snap je bezwaren niet... MS ontwikkelt de DirectX standaard... En dan? Hoe moeten ze hun monopolie misbruiken om OpenGL te verdringen dan? Bij de Windows display drivers zit gewoon OpenGL-support, dus kennelijk heeft MS dat niet tegengehouden...
Toch komen er meer DirectX spellen uit dan OpenGL... Wat is jouw verklaring hier dan voor... Heeft MS alle ontwikkelaars omgekocht, bedreigd of gechanteerd ofzo?
Of zou het gewoon komen dat de meeste ontwikkelaars ook vinden dat OpenGL wat achter de feiten aan loopt, en dat ze toch wel liever DirectX gebruiken dan?
En wat zijn jouw bezwaren in dat geval dan? Dat MS geen betere standaard had mogen ontwikkelen omdat er al een standaard was? En je was nog wel zo voor vrijheid en tegen onderdrukking!

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 20:30:
[...]


Als je je nu eens in de materie zou verdiepen, zou je kunnen vinden dat MS die standaard niet in z'n eentje bepaald heeft, net als bij DirectX. Bedrijven als Intel, HP, IBM en America Online hebben de standaard uitvoerig bestudeerd, en pas nadat iedereen hem heeft goedgekeurd, is de standaard officieel door de EMCA aangenomen.
Kortom, je ziet spoken, omdat je totaal niet weet waar het over gaat, en maar meteen het ergste aanneemt.

En wat zou er gebeurd zijn als deze bedrijven de standaard niet goedgekeurd zouden hebben? Dan zou MS ze simpelweg door misbruik van monopolie erdoor gedrukt hebben, en de genoemde bedrijven kennen de machtspositie van Microsoft. Het zijn stuk voor stuk bedrijven die de woede van MS zich niet op de hals willen halen, behalve AOL misschien dan.

Ik geloof niet dat jij je volledig realiseert hoe Microsoft met zijn monopolie de technologiesector in de tang heeft en hoeveel macht het bedrijf heeft. En daarmee innovatie al jaren in de weg staat.

Ik ben helemaal vóór een systeem waarbij je programma's onafhankelijk van platform en besturingssysteem kunt draaien. Maar de betrokkenheid van Microsoft mag wat mij betreft met argusogen bekeken worden, en ik zie in .NET geen realistische aanwijzingen dat MS zijn leven wil beteren.

[chem]

Mensen, ik vind het best als er intens gediscussieerd wordt over de voor- en nadelen van x86 tov PPC etc. etc. - maar zodra dit uitmondt in kansloos geblêr en jij-zei-hij-zei dan is het (weer) snel afgelopen.

[Luke_msx]

Verwijderd schreef op maandag 14 februari 2005 @ 20:35:
[...]


Nee, ik snap je bezwaren niet... MS ontwikkelt de DirectX standaard... En dan? Hoe moeten ze hun monopolie misbruiken om OpenGL te verdringen dan? Bij de Windows display drivers zit gewoon OpenGL-support, dus kennelijk heeft MS dat niet tegengehouden...
Toch komen er meer DirectX spellen uit dan OpenGL... Wat is jouw verklaring hier dan voor... Heeft MS alle ontwikkelaars omgekocht, bedreigd of gechanteerd ofzo?
Of zou het gewoon komen dat de meeste ontwikkelaars ook vinden dat OpenGL wat achter de feiten aan loopt, en dat ze toch wel liever DirectX gebruiken dan?
En wat zijn jouw bezwaren in dat geval dan? Dat MS geen betere standaard had mogen ontwikkelen omdat er al een standaard was? En je was nog wel zo voor vrijheid en tegen onderdrukking!

Je wilt het dus niet snappen. Goed, dan zijn we dus uitgepraat.

[Verwijderd]

Inderdaad, dit loopt uit de hand... .NET/D3D waren alleen maar bedoeld als voorbeeld van hoe het in de toekomst zou kunnen. Het is jammer dat die technologie toevallig van MS is, omdat het altijd van die vervelende discussies uitlokt. Dat was mijn bedoeling helemaal niet, het ging mij om de hardware-platforms, niet om de software-platforms.

Ik hoop dat we deze discussie over de hardware-platforms verder kunnen vervolgen. Laten we over MS maar zwijgen, want dat wordt toch niks.
Dus als iemand vragen of opmerkingen heeft over x86, PPC etc, graag... Ik weet zelf even niets te verzinnen

[Verwijderd]

Wat een discussie zeg... Discussieren is prima, flamen wat minder... het liefst zou ik toch on-topic nog wat meer ervaring van mensen zien mbt processor snelheden en benchmarks (voor zover ze ook echt uit te voeren zijn). Zoals al eerder gezegd is kan je niet echt appels met peren vergelijken maar feit is wel dat ik -en anderen met mij- als consument uiteindelijk een systeem wil kopen dat aan bepaalde verwachtingen voldoet. Dat UT2004, Photoshop, Premiere oid beter draait op mac dan op een vergelijkbare x86 pc (of omgekeerd) vind ik interessant en het is wat minder boeiend of de architectuur van 't logic board net wat anders in elkaar hangt dan die van een x86 platform. Uiteindelijk komt 't neer op prestaties, gebruiksgemak en -genot.

Het statement dat je niet apples met peren kan vergelijken is dus in imho ten dele waar. Qua architectuur misschien wel, maar qua prestaties, emotie en gebruiksgenot toch echt niet.

Ik wil wel eens weten hoe een huidige powerbook 15" 1.67Ghz 512MB presteert t.o.v. bijvoorbeeld een topmodel van vergelijkbare prijsklasse (ook van rond de 1.6Ghz? met evenveel geheugen en een zelfde of vergelijkbare harddisk) uit het dell of asus assortiment en dan puur en alleen op snelheid, prestatie (en dan dus even helemaal vergeten dat DirectX bestaat, cpu caches, etc) en gebruiksgenot.

Ik ben benieuwd

[ Voor 3% gewijzigd door Verwijderd op 14-02-2005 23:46 ]

[Verwijderd]

@ddbruijn

Ik heb met veel interesse je replies gelezen ivm processoren en dergelijke.
Nu zou ik willen vragen of je niet een paar website locaties kan aangeven (of boeken) om over die onderwerpen zelf meer te leren en te begrijpen. Want hoe duidelijk je uitleg ook was, het was vaak nog te hoog gegrepen voor mij, maar het interesseert me wel.
En ik meen dat je zoiets beter zelf kan uitpluizen dan daar mensen mee lastig te vallen om in het lang en het breed uitleg te typen. Dat kan ik beter op het gemakske zelf uitpluizen.

Dus wat mij dan vooral interesseert is zoals gezegd de architectuur van processoren, de manier waarop alle pc onderdelen met elkaar communiceren, en ook de geschiedenis van de verschillende standaarden, protocols, processor architectuur. (ervaring leert dat je het best iets begrijpt als je weet waar je van komt, en als het ware de evolutie zelf nog eens doorneemt)

Heb zelf al wat gezocht en wat gelezen, maar kheb vooral weinig tijd om veel te zoeken, dus misschien kan je me daar al wat op weg helpen (alleen als je zo direct iets weet, je hoeft hier geen tijd in te steken hoor)

[downtime]

Arstechnica.com heeft in het verleden een reeks goeie artikelen over het onderwerp geschreven. Zelf vind ik het vrij zware kost maar helaas kun je dit complexe onderwerp niet echt simpel maken.

[Verwijderd]

Arstechnica is een aardige site inderdaad.
Verder heeft iedere CPU-fabrikant allerlei handleidingen over hun producten (tegenwoordig ook online in PDF te krijgen). Zie bijvoorbeeld http://developer.intel.com.
Er is altijd wel een instructionset reference te vinden, en vaak ook een programming guide of zelfs optimization guide.

Verder is het handig om je een beetje te verdiepen in Computer Organization. Je zou een boek kunnen kopen... bijvoorbeeld van Tanenbaum, die schrijft altijd wel aardig. Je zou ook het gratis e-book Art of Assembly eens kunnen doorlezen (http://webster.cs.ucr.edu/AoA/index.html).
De inleidende hoofdstukken (van de DOS-versie iig, ben niet bekend met de Windows/linux versies) leggen uit hoe een processor nu precies z'n werk doet. Dat geeft een goede ondergrond voor het begrijpen van dit soort onderwerpen, denk ik.

Verder is de beste manier natuurlijk om het gewoon te doen... Dus een assemblertje downloaden, en gewoon wat code schrijven en kijken hoe verschillende CPUs dit nu precies uitvoeren. Maarja, dat is natuurlijk alleen voor programmeurs weggelegd. Ik denk niet dat je 'even' assembly wilt leren als je alleen maar een beetje nieuwsgierig bent naar hoe CPUs werken, maar verder geen interesse hebt in programmeren.

[ErikRo]

Asl jullie nog een leuke test zoeken.

Povray op http://povray.org/ is een opensource raytracer met een mac en een pc versie.
Dus altijd een Mini Mac heeft en een P4 PC en eens even een vergelijking in rendertijd wil doen. Dan kunnen we een leuke cijfers krijgen voor wat betreft het rekengedeelte van chip.

Ik heb dan wel een pc om te testen maar nog geen Mac, iemand zin in een vergelijking?

http://povray.org/download/benchmark.php
Geeft uitleg als je povray als benchmark wil gebruiken.

Ik zal er eens een renderen op een p4 3ghz met benchmark.pov met de standaard benchmark.ini in de map scenes/advanced

[ Voor 25% gewijzigd door ErikRo op 20-02-2005 00:53 ]

[ErikRo]

Render Statistics
Image Resolution 512 x 384

Pixels: 196608 Samples: 196608 Smpls/Pxl: 1.00
Rays: 1120962 Saved: 21200 Max Level: 12/12

Parse Time: 0 hours 0 minutes 2 seconds (2 seconds)
Photon Time: 0 hours 0 minutes 33 seconds (33 seconds)
Render Time: 0 hours 12 minutes 11 seconds (731 seconds)
Total Time: 0 hours 12 minutes 46 seconds (766 seconds)
CPU time used: kernel 1.55 seconds, user 747.80 seconds, total 749.34 seconds
Render averaged 262.37 PPS over 196608 pixels

POV-Ray finished

[Verwijderd]

ErikRo schreef op zondag 20 februari 2005 @ 00:58:
Render Statistics
Image Resolution 512 x 384

Pixels: 196608 Samples: 196608 Smpls/Pxl: 1.00
Rays: 1120962 Saved: 21200 Max Level: 12/12

Parse Time: 0 hours 0 minutes 2 seconds (2 seconds)
Photon Time: 0 hours 0 minutes 33 seconds (33 seconds)
Render Time: 0 hours 12 minutes 11 seconds (731 seconds)
Total Time: 0 hours 12 minutes 46 seconds (766 seconds)
CPU time used: kernel 1.55 seconds, user 747.80 seconds, total 749.34 seconds
Render averaged 262.37 PPS over 196608 pixels

POV-Ray finished

Mac OS X 10.2 or later are supported but for maximum render speed it is not recommended to use Mac OS X.

Niet zo heel eerlijk, MacOS X bevat wel een MacOS 9 emulatielaag maar dat is dus emulatie en krijg je toch weer performance verschil. Op OSX wou ik die benchmark runnen maar hij vond steeds 'function.inc' niet die toch gewoon in de 'include'-dir van POV-Ray staat. Hulp nodig!

[edit:]
Deze benchmark zegt trouwens niets of een G4/G5 sneller is dan een P4, alleen maar op dit gebied niet over het algemeen.

[ Voor 9% gewijzigd door Verwijderd op 20-02-2005 16:08 ]

[ErikRo]

Oh dat had ik weer niet gezien, zag osx en dacht mooi zo ook voor de mac te krijgen.
helpt het niet als die file op dezelfde plek zet waar benchmark.pov staat?

Zal eens even kijekn of ik nog wat meer info kan vinden.

"Requires at least Mac OS 9.2 or at least Mac OS X 10.2.8. Using Mac OS 9.2.2 is strongly recommended. For Mac OS CarbonLib 1.6 is required."

Die carbonlib1.6 heb er niks mee te maken?

[ErikRo]

[b][message=22826540,noline]KoeNijn schreef op zondag 20 februari 2005 @
Deze benchmark zegt trouwens niets of een G4/G5 sneller is dan een P4, alleen maar op dit gebied niet over het algemeen.

klopt maar dat zei ik ook, gaat puur om het reken gedeelte van de chip.

Dan kunnen we een leuke cijfers krijgen voor wat betreft het rekengedeelte van chip.

ok alleen voor wat betreft raytracing dan
Ik had trouwens verwacht dat hij gebruik zou maken van het beroemde vector rekengedeelte op de mac die gebruikt Folding ook en de MM zou daarmee sneller zijn dan een amd3500

[ Voor 23% gewijzigd door ErikRo op 20-02-2005 16:13 ]

[ErikRo]

Misschien helpt dit er was iemand met hetzelfde probleem.

> I have checked the directory and functions.inc is there. How do I fix this?

You have not set the include path. You either removed it or the
automatically used preferences of 3.5 did not contain the standard include
folder in the Preferences dialog Scenes pane. When you installed POV-Ray for
the first time, it did set that folder automatically.

Thorsten


just tell to povray where inludes files are :

- Menu Edit -> Preferences
- In "POV-Ray Application Preferences" windows, select "Scenes" tab.
- Under "Include Paths" box, clic "Add..." button.
- with the browser, locate your pov-ray include files folder and
clic "Choose"
- Now in "Include Paths" box, you can see the include files path.

that's all... but READ THE DOC.

[Verwijderd]

ErikRo schreef op zondag 20 februari 2005 @ 16:21:
Misschien helpt dit er was iemand met hetzelfde probleem.

> I have checked the directory and functions.inc is there. How do I fix this?

You have not set the include path. You either removed it or the
automatically used preferences of 3.5 did not contain the standard include
folder in the Preferences dialog Scenes pane. When you installed POV-Ray for
the first time, it did set that folder automatically.

Thorsten


just tell to povray where inludes files are :

- Menu Edit -> Preferences
- In "POV-Ray Application Preferences" windows, select "Scenes" tab.
- Under "Include Paths" box, clic "Add..." button.
- with the browser, locate your pov-ray include files folder and
clic "Choose"
- Now in "Include Paths" box, you can see the include files path.

that's all... but READ THE DOC.

In de foutmelding die ik kreeg zei die dat de Libery_Path niet goed stond ingesteld in een .ini bestand dus had ik die povray.ini die regel toegevoegd. En toch nog die melding. Nu met jou manier werkte die meteen.

Gerunt op een Powerbook G4 1.33 met 768mb geheugen.
Resultaat 1ste run:

code:

Render Statistics
Image Resolution 512 x 384
----------------------------------------------------------------------------
Pixels:           196608   Samples:          196608   Smpls/Pxl: 1.00
Rays:            1119426   Saved:             20848   Max Level: 12/12
----------------------------------------------------------------------------

Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  6 seconds (6 seconds)
  Photon Time:   0 hours  1 minutes 23 seconds (83 seconds)
  Render Time:   0 hours 36 minutes 49 seconds (2209 seconds)
  Total Time:    0 hours 38 minutes 18 seconds (2298 seconds)

Laag De Render engine stond nog op 'Official POV-Ray 3.6.1' resultaten met de 'Official POV-Ray 3.6.1 for G4' engine heb ik nu geen zin in om te teste Maar deze uitslag kon je volgens mij makkelijk raden. Misschien dat ik em opnieuw laat renderen als ik morgen na school ben. Wat me wel opviel is dat het begin zeer traag gaat en opeens op ongeveer 1/3 gaat die nog al snel.

[ Voor 3% gewijzigd door Verwijderd op 20-02-2005 20:00 ]

[ErikRo]

Leuk dat je nog even de test wilde uitvoeren
Ik weet niet of je hem eerst op vol vermogen had gezet, ik geloof dat power en ibooks standaard wat langzamer lopen om batterijen te sparen.

Dat sneller lopen vanaf 1/3 is niet zo gek hoor, heeft met de scene te maken, als die ineens minder complex wordt (minder rays) gaat het sneller en omgekeerd.


Dus we hebben nu voorlopig even:

P4-3.06ghz met 1024mb
12:46 min

Powerbook G4 1.33ghz met 768mb
38:18 min


Niemand hier met een dual G5-2.5ghz die even wil meehelpen met testen?

[begintmeta]

Ik denk haast dat ik een andere benchmark heb gepakt, Povray 3.6, benchmark van de site en benchmark.ini van de site. Gewoon .ini gerenderd. Pentium 4 2,4 200Mhz dual-channel DDR


Render Time: 0 hours 41 minutes 22 seconds (2482 seconds)


Als ik nog wat tijd zou hebben doe ik het ook nog op mijn gelukkig weer werkende iBook 800Mhz

[ Voor 90% gewijzigd door begintmeta op 20-02-2005 22:02 . Reden: 't was inderdaad wat onnodig lang geworden, nu is vastgesteld dat het inderdaad een andere benchmark is. ]

[ErikRo]

begintmeta: misschien is het handiger om niet alles te plakken alleen je totale rendertijd, anders wordt het zoveel scrollen
Echter daardoor ontdekte ik wel dat jij iets anders hebt gerenderd dan ons. Jij hebt namelijk anti aliasing aangezet, wij hebben hem uitstaan, dat scheelt al snel een factor 3 renderdtijd schat ik.
Kun je hem anders nog eens renderen met aa uit en die in je oude mail plakken?

ps ik heb niet de ini van de site genomen hoor, ik ging ervanuit dat die wel bij de laatste exe van povray zat, snelle controle met het oog leek dat te bevestigen.
Dus neem aub de .ini uit de executable, anders duurt het renderen nog langer.

edit: ik zie nu ook dat de ini op de site AA aan heeft staan. Als jullie allemaal die ini van de site hebben genomen kan ik hem anders wel overnieuw renderen met de ini van de site en AA aan.

ik hoor het wel van Koenijn.

[ Voor 51% gewijzigd door ErikRo op 20-02-2005 21:41 ]

[Hertog]

Verwijderd schreef op zondag 13 februari 2005 @ 03:22:
[...]
Als je nu een Apple koopt kan je als OSX Tiger uit komt deze gratis krijgen
[...]

Tussen al de interessante verhalen in dit topic, waar ik niets aan toe te voegen heb, viel me deze zin op. Is dat zo, waar lees je dat en vanaf wanneer gold dit?

[ErikRo]

Hertog schreef op zondag 20 februari 2005 @ 21:38:
[...]


Tussen al de interessante verhalen in dit topic, waar ik niets aan toe te voegen heb, viel me deze zin op. Is dat zo, waar lees je dat en vanaf wanneer gold dit?

nee is niet zo, want hij niet uit. Maar als hij uitkomt krijg je hem 95% waarschijnlijk meteen erbij.

[Verwijderd]

Hertog schreef op zondag 20 februari 2005 @ 21:38:
[...]


Tussen al de interessante verhalen in dit topic, waar ik niets aan toe te voegen heb, viel me deze zin op. Is dat zo, waar lees je dat en vanaf wanneer gold dit?

Ik meende even terug ergens gelezen te hebben dat als je een apple na 21 januari kocht je een bon erbij kreeg om gratis te upgraden naar tiger. Helaas vind ik het niet meer op internet en ik wil je geen valse hoop geven dus neem maar voorlopig aan dat het niet klopte wat ik zei

Ik vraag me echt af waar ik dat had geleze

[ontopic edit:]

ErikRo schreef op zondag 20 februari 2005 @ 21:15:
Leuk dat je nog even de test wilde uitvoeren
Ik weet niet of je hem eerst op vol vermogen had gezet, ik geloof dat power en ibooks standaard wat langzamer lopen om batterijen te sparen.

Dat sneller lopen vanaf 1/3 is niet zo gek hoor, heeft met de scene te maken, als die ineens minder complex wordt (minder rays) gaat het sneller en omgekeerd.


Dus we hebben nu voorlopig even:

P4-3.06ghz met 1024mb
12:46 min

Powerbook G4 1.33ghz met 768mb
38:18 min


Niemand hier met een dual G5-2.5ghz die even wil meehelpen met testen?

De powerbook had ik geforceerd op de hoge snelheid gezet.

Meteen even wat distributed.net benchmarks houden?
Clientversie: v2.9009.494

code:

[Feb 20 23:06:47 UTC] Automatic processor type detection found
                      a PowerPC 7447A (G4) processor.
[Feb 20 23:06:47 UTC] RC5-72: using core #4 (KKS 7450).
[Feb 20 23:07:05 UTC] RC5-72: Benchmark for core #4 (KKS 7450)                 
                      0.00:00:16.64 [13,110,465 keys/sec]
[Feb 20 23:07:05 UTC] OGR-P2: using core #1 (KOGE 2.0 Hybrid).
[Feb 20 23:07:24 UTC] OGR-P2: Benchmark for core #1 (KOGE 2.0 Hybrid)          
                      0.00:00:16.51 [29,075,037 nodes/sec]

[ Voor 58% gewijzigd door Verwijderd op 21-02-2005 00:25 ]

[O.D.Smolik]

Voortaan beter lezen, want het gaat om iLife 05 en niet Tiger.
We gaan echt offtopic! Hopelijk ziet Zwerver dit niet.
*verstopt zich alvast

[Verwijderd]

ErikRo schreef op zondag 20 februari 2005 @ 21:15:
Powerbook G4 1.33ghz met 768mb
38:18 min


Niemand hier met een dual G5-2.5ghz die even wil meehelpen met testen?

Verschil met iBook G4 1.2 met 512 mb ram is zeer behoorlijk

Total Scene Processing Times
Parse Time: 0 hours 0 minutes 5 seconds (5 seconds)
Photon Time: 0 hours 1 minutes 20 seconds (80 seconds)
Render Time: 1 hours 20 minutes 27 seconds (4827 seconds)
Total Time: 1 hours 21 minutes 52 seconds (4912 seconds)

[Verwijderd]

Verwijderd schreef op maandag 21 februari 2005 @ 00:21:
[...]


Verschil met iBook G4 1.2 met 512 mb ram is zeer behoorlijk

Total Scene Processing Times
Parse Time: 0 hours 0 minutes 5 seconds (5 seconds)
Photon Time: 0 hours 1 minutes 20 seconds (80 seconds)
Render Time: 1 hours 20 minutes 27 seconds (4827 seconds)
Total Time: 1 hours 21 minutes 52 seconds (4912 seconds)

Euhm je moet een paar instellingen veranderen. Ik haalde ook 1 keer 59 minuten maar toen heb ik die afgekapt, omdat ik die 38 minuten al de eerste keer haalde, ik weet helaas niet meer welke instellingen ik had gebruikt toen. Ook moet ik nogmaals opmerken dat dit programma op OSX niet optimaal functioneerd, er wordt voor de performance OS9.2.2 aanbevolen. Mijn score is trouwens op volle kwaliteit enz. Ik start morgen de benchmark met de G4 engine als ik na school ga, nu moet mn powerbook vrij blijven, ik kan niet zonder dat ding

[ErikRo]

Ik ben even in de war, als ik in de ini file kijk die bij povray zit, staat AA aan.
Als ik echter benchmark.pov oproep open, staat de resolutie listbox gewoon op 512x384 en niet op 512x384 AA 0.3 (zoals de ini file zegt) , dus ik weet nu ook niet meer wat en hoe hij rendert

Zo wordt er niet makkelijke rop eea te vergelijken. Ik zal het nog eens renderen met en zonder AA in de listbox.

[Verwijderd]

De volgende benchmarks zijn om te kijken waar de G4 engine zn voordeel in slaat.

Preview uitgeschakeld, background rendering uitgeschakeld en G4 engine gebruikt.
Even gerenderd op kwaliteit [2,3]:

code:

Render Statistics
Image Resolution 512 x 384
----------------------------------------------------------------------------
Pixels:           196608   Samples:          196608   Smpls/Pxl: 1.00
Rays:             418683   Saved:                 0   Max Level: 3/12
----------------------------------------------------------------------------
  Total Time:    0 hours  0 minutes 58 seconds (58 seconds)

Kwaliteit [5]:

code:

  Total Time:    0 hours  3 minutes 19 seconds (199 seconds)

Nu dezelfde benchmarks met de gewone (non-G4) render engine
Kwaliteit [2,3]:

code:

  Total Time:    0 hours  0 minutes 59 seconds (59 seconds)

Kwaliteit [5]:

code:

  Total Time:    0 hours  3 minutes 19 seconds (199 seconds)

Het lijkt er op dat de G4 engine niet eens beter is dan de niet geoptimaliseerde engine

Benchmarks met AA met instellingen:
sampling method: Adaptive
Threshold: 0.3
Recursion Depth: 2
Jitter: 0.0

Non-G4 engine en kwaliteit [2,3]:

code:

  Total Time:    0 hours  4 minutes 46 seconds (286 seconds)

G4 engine en kwaliteit [2,3]:

code:

  Total Time:    0 hours  4 minutes 10 seconds (250 seconds)

Hier werkt de G4 engine net wat versnellend.

En dit is de G4 engine op hoogste kwaliteit zonder AA:

code:

  Total Time:    0 hours 43 minutes 35 seconds (2615 seconds)

Met G4 engine is het dus nog wat slomer dan de gewone engine


Maar even een andere benchmark:

Distributed.net Clientversie: v2.9009.494

Powerbook 12" 1.33ghz met 768mb geheugen:

code:

[Feb 20 23:06:47 UTC] Automatic processor type detection found
                      a PowerPC 7447A (G4) processor.
[Feb 20 23:06:47 UTC] RC5-72: using core #4 (KKS 7450).
[Feb 20 23:07:05 UTC] RC5-72: Benchmark for core #4 (KKS 7450)                 
                      0.00:00:16.64 [13,110,465 keys/sec]
[Feb 20 23:07:05 UTC] OGR-P2: using core #1 (KOGE 2.0 Hybrid).
[Feb 20 23:07:24 UTC] OGR-P2: Benchmark for core #1 (KOGE 2.0 Hybrid)          
                      0.00:00:16.51 [29,075,037 nodes/sec]

Amd Athlon XP 2600+ met 256mb geheugen en een Asus A7V600-X mobo. Draaiende in Debian Sarge (Linux):

code:

[Feb 21 14:04:19 UTC] Automatic processor type detection found
                      an AMD K7-8 (Athlon XP/MP or Duron) processor.
[Feb 21 14:04:19 UTC] RC5-72: using core #6 (GO 2-pipe).
[Feb 21 14:04:38 UTC] RC5-72: Benchmark for core #6 (GO 2-pipe)                
                      0.00:00:16.62 [7,919,698 keys/sec]
[Feb 21 14:04:38 UTC] OGR-P2: using core #0 (GARSP 6.0-A).
[Feb 21 14:04:56 UTC] OGR-P2: Benchmark for core #0 (GARSP 6.0-A)              
                      0.00:00:16.25 [16,493,500 nodes/sec]

G4 1.33 score:
• RC5-72: 13,110,465 keys/sec
• OGR-P2: 29,075,037 nodes/sec
Athlon XP 2600+ (linux)score:
• RC5-72: 7,919,698 keys/sec
• OGR-P2: 16,493,500 nodes/sec
Athlon XP 2600+ (win2000) score:
• RC5-72: 8,067,023 keys/sec
• OGR-P2: 18,513,821 nodes/sec


G4 1.33 maakt korte metten met Athlon XP 2600+. Nu verzoek ik om P4 resultaten

[ Voor 37% gewijzigd door Verwijderd op 21-02-2005 15:15 ]

[ErikRo]

Leuk die hoor die distrubuted client kilt echt elke pc
Dat was al bekend, maar goed ik zal sportief zijn en hem eens installeren en de test resultaten hier vermelden

Dus we hebben nu staan
P4 - 3ghz - 13minuten
G4 - 1.3ghz - 43 minuten

Dus de G4 rekent grof gezegd per mhz op 90% tegenover een P4 mhz als het om raytracing gaat. Waarbij vermeld moet worden dat de G4 engine in OS9 emulatie draait dus verre van optimaal.

[Verwijderd]

ErikRo schreef op maandag 21 februari 2005 @ 15:31:
Leuk die hoor die distrubuted client kilt echt elke pc
Dat was al bekend, maar goed ik zal sportief zijn en hem eens installeren en de test resultaten hier vermelden

Dus we hebben nu staan
P4 - 3ghz - 13minuten
G4 - 1.3ghz - 43 minuten

Dus de G4 rekent grof gezegd per mhz op 90% tegenover een P4 mhz als het om raytracing gaat. Waarbij vermeld moet worden dat de G4 engine in OS9 emulatie draait dus verre van optimaal.

POV-Ray draait niet in OS9 emulatie momenteel maar gewoon op OSX maar in OSX draait die niet optimaal in OS9 emulatie krijg ik em niet en dat zou zowieso dan retetraag gaan.

Dat de P4 wint bij dit gedoe is ook nogal wiedes, het gaat ja over puur rauwe mhz berekeningen, of heb ik het mis? Een Athlon houd volgens mij ook geen P4 hierbij bij, dalijk ff benchen

De G4 1.33 doet er trouwens 38 minuten over, die 43 minuten wat met een 'G4 geoptimaliseerde' engine.

Is er geen benchmark voor Blender3D of iets dergelijks?

[edit:]
Ik heb POV-Ray op windows geïnstalleerd en ik moet zeggen dat die er totaal anders uitziet en lijkt veel meer functies te bevatten. De athlon is momenteel de standaard benchmark aan het draaien, volgens een infodialog zou die test ongeveer 45minuten op een P4 2Ghz draaien.

[edit2:]
De Athlon is nu klaar met de eerste run en die haalde het in 32min05. Ik vraag me af hoe jij aan die 12 minuten komt? Zijn we verschillende dingen het benchmarken? benchmark.pov op hoogste kwaliteit toch?

[ Voor 36% gewijzigd door Verwijderd op 21-02-2005 16:38 ]

[nIghtorius]

Verwijderd schreef op maandag 21 februari 2005 @ 15:45:
[...]

POV-Ray draait niet in OS9 emulatie momenteel maar gewoon op OSX maar in OSX draait die niet optimaal in OS9 emulatie krijg ik em niet en dat zou zowieso dan retetraag gaan.

Dat de P4 wint bij dit gedoe is ook nogal wiedes, het gaat ja over puur rauwe mhz berekeningen, of heb ik het mis? Een Athlon houd volgens mij ook geen P4 hierbij bij, dalijk ff benchen

De G4 1.33 doet er trouwens 38 minuten over, die 43 minuten wat met een 'G4 geoptimaliseerde' engine.

Is er geen benchmark voor Blender3D of iets dergelijks?

[edit:]
Ik heb POV-Ray op windows geïnstalleerd en ik moet zeggen dat die er totaal anders uitziet en lijkt veel meer functies te bevatten. De athlon is momenteel de standaard benchmark aan het draaien, volgens een infodialog zou die test ongeveer 45minuten op een P4 2Ghz draaien.

[edit2:]
De Athlon is nu klaar met de eerste run en die haalde het in 32min05. Ik vraag me af hoe jij aan die 12 minuten komt? Zijn we verschillende dingen het benchmarken? benchmark.pov op hoogste kwaliteit toch?

Hij heeft AA uit staan..

ter vergelijk (dit is een heftige)

AMD Athlon64 @ 2.53Ghz
Render Total Time: 0 hours, 9 minutes, 11 seconds (551 seconds)
Render averaged 275.58 PPS over 147456 pixels

en over die mkeys/s RC5-72:

Windows 32bit: 10Mkeys/s
Linux 32bit: 11Mkeys/s
Linux 64bit: 19Mkeys/s

allen afgerond naar beneden.. nu vraag ik me af.. zijn die G4's 32-bit of 64-bit?? want het scheelt namelijk behoorlijk veel.

ps) een Pentium IV gaat vreselijk stofhappen in RC5-72 crunching. Absoluut niet het sterkste punt van die processor.

grafisch bewijs Povray

[ Voor 18% gewijzigd door nIghtorius op 21-02-2005 17:07 ]

[The Evil Brain]

G4's zijn 32 bit, G5's 64 bit

[Verwijderd]

nIghtorius schreef op maandag 21 februari 2005 @ 16:47:
[...]


Hij heeft AA uit staan..

ter vergelijk (dit is een heftige)

AMD Athlon64 @ 2.53Ghz
Render Total Time: 0 hours, 9 minutes, 11 seconds (551 seconds)
Render averaged 275.58 PPS over 147456 pixels

en over die mkeys/s RC5-72:

Windows 32bit: 10Mkeys/s
Linux 32bit: 11Mkeys/s
Linux 64bit: 19Mkeys/s

allen afgerond naar beneden.. nu vraag ik me af.. zijn die G4's 32-bit of 64-bit?? want het scheelt namelijk behoorlijk veel.

grafisch bewijs Povray

Ik had met de athlon de verkeerde benchmark uigevoerd De XP2600+ haalt het in 14min20.

De G4 is gewoon nog een 32bits cpu en die van mij loopt op 1.33ghz. De G5 is wel een 64bits cpu maar er is geen 64bits client beschikbaar voor OSX. Je hebt mooie resultaten maar het jammer is het dat je hebt overgeklokt waardoor je niet meer kan vergelijken omdat je rating niet meer klopt.

[ Voor 20% gewijzigd door Verwijderd op 21-02-2005 17:09 ]

[Verwijderd]

offtopic:
ik was even op zoek naar wat meer benchmark mogelijkheden en kwam dit verhaal tegen, een beetje lang maar wel een goeie actie: http://www.zug.com/pranks/powerbook/powerbook.pdf

[Madcat]

14 min en 25 sec op een amd 64 3200+ @ 2Ghz met 1GB ram op een windows xp sp2 systeem
zonder AA, blijkbaar is de P4 dus sneller dan de amd?

[ Voor 16% gewijzigd door Madcat op 21-02-2005 17:42 ]

[ErikRo]

Dat de P4 wint bij dit gedoe is ook nogal wiedes, het gaat ja over puur rauwe mhz berekeningen, of heb ik het mis? Een Athlon houd volgens mij ook geen P4 hierbij bij, dalijk ff benchen

Ach ik hoor altijd dat er een mhz mythe is en dat je bv het aantal mhz moet verdubbelen op de apple om te zien waarmee hij gelijk loopt op een pc.
Dat gaat dus niet met alles op.

Zal eens kijken of ik nog een andere render app kan vinden voor zowel pc als mac.

[Madcat]

dat ligt er puur aan wat voor soort berekeningen het zijn, alles heeft zijn voor en nadelen.
in een risc processor zal het aantal megaherzen minder uitmaken dan in een CISC denk ik. omdat je dan inderdaad een aantal jumps enzo kan maken waarbij de pipe geflushed moet worden.

echter als je gaat renderen zal het programma van te voren al weten wat er gedaan moet worden en zal het aantal mhz zeker wel uitmaken.
echter had ik wel gehoopt dat de amd met een index van 3200 de p4 op 3000 (amd index 3000) dus wel zou verslaan.

nu vraag ik me af of die test op een linux platform is gedaan of op windows?
mijn test heb ik op win32 gedaan, win64 heb ik er ook nog wel opstaan maar geen zin om te booten

[ErikRo]

De mijne liep op winxp xp prof met 1024 memory op de achtergrond terwijl ik op de voorgrond aan het surfen was.

[Verwijderd]

Nog even wat getest.

OS9 emulatie op OSX aan de praat gekregen (wist nog niet hoe dat moest) en daarin is POV-Ray een stukje sneller. De benchmark is gedaan met de gewone engine.

code:

Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  5 seconds (5 seconds)
  Photon Time:   0 hours  1 minutes 13 seconds (73 seconds)
  Render Time:   0 hours 32 minutes 13 seconds (1933 seconds)
  Total Time:    0 hours 33 minutes 31 seconds (2011 seconds)

Schermafbeelding - let op slechte upload, @home

Nog ene met de G4 engine:

code:

Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  4 seconds (4 seconds)
  Photon Time:   0 hours  1 minutes 16 seconds (76 seconds)
  Render Time:   0 hours 33 minutes  5 seconds (1985 seconds)
  Total Time:    0 hours 34 minutes 25 seconds (2065 seconds)

Maar nu eens wat anders benchmarken

ErikRo schreef op maandag 21 februari 2005 @ 17:55:
[...]

Ach ik hoor altijd dat er een mhz mythe is en dat je bv het aantal mhz moet verdubbelen op de apple om te zien waarmee hij gelijk loopt op een pc.
Dat gaat dus niet met alles op.

Zal eens kijken of ik nog een andere render app kan vinden voor zowel pc als mac.

Die mhz mythe is er ook. Die die je als je de P4 vergelijkt tegen de P4-M, alle Athlons, Itanium, G3, G4 en G5 cpu's en nog wat andere cpu's. De mac mini maakt al aardappelsla van je P4 op sommige gebieden om maar als voorbeeld te noemen Je moet er op letten dat zoals al vaker is gezegd hier in het topic dat niet alles zo snel draait op een powerpc als op een P4 en omgekeerd heb je hetzelfde.

[ Voor 30% gewijzigd door Verwijderd op 21-02-2005 19:31 ]

[Verwijderd]

Recente test van Barefeats

3. The test units had different memory configurations ranging from 2GB to 4GB. However, since we were running one task at a time, even 1GB would have produced the same results as 4GB. But for the record, this was the configuration:

Dual G5/2.5GHz Power Mac = 4GB of 400MHz DDR
Dual G5/2.0GHz Power Mac = 4GB of 400MHz DDR
Dual Xeon 3.4GHz = 4GB of 400MHz DDR
Pentium 4 3GHz = 2GB of 400MHz DDR
64 bit Athlon 2.2GHz = 3GB of 333MHz DDR

[ Voor 15% gewijzigd door Verwijderd op 21-02-2005 21:11 ]