Processorsnelheden

[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 ]