SMP Stelling

[XElD]

In benchmarks lees je meestal dat een SMP systeem in real life, niet ervoor geschreven applicaties in een systeem zoals een Linux/Win2k/Unix zo'n 10% sneller laat draaien door de Os load te verdelen over de proc's... Een gemiddelde wel ervoor geschreven applicatie z'on 25 tot 50 % en een erg goed ervoor gescreven app die ook voor het doel geschikt is (Distributed.net, brute password crackers, etc...) meer dan 75 tot 100% ... Dit 1e, +/- 10%, is echter het meest het geval...

Uitgaande van die benchmarks zou je denken dat het het helemaal niet waard zou zijn om een SMP te kopen, maar is het gewoon niet zo dat een SMP systeem veel relaxter loopt en de reactietijd in het OS enorm verbeterd doordat het niet hoeft te wachten totdat de processor met iets anders klaar is, zoals achtergrondapps die je toch wel draait , dit zou wel een goede verbetering zijn in het gebruikersgemak van het systeem denk ik en het veel aantrekkelijker maken om een SMP systeem aan te schaffen dan de over het algemeen slechte benchmarkcijfers, die het trouwens meestal alleen maar hebben over de performance van een applicatie, doen vermoeden...<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Zijn jullie het hier mee eens of oneens...[/quote]Verder vraag ik me nog een ding af.... , zou het niet zo zijn dat het erg gunstig is om het hele OS aan een proc toe te wijs, incl. alle achtergrond apps... (ok... zodat ie niet 100% belast is) en dan een niet voor SMP geschreven game (zoals UT) volledig op de ander proc. te draaien, volgens mijn zou dat in een spel als UT toch wel een snelheidswinst van meer dan 25% kunnen opleveren...

[JumpStart]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Verder vraag ik me nog een ding af.... , zou het niet zo zijn dat het erg gunstig is om het hele OS aan een proc toe te wijs, incl. alle achtergrond apps... (ok... zodat ie niet 100% belast is) en dan een niet voor SMP geschreven game (zoals UT) volledig op de ander proc. te draaien, volgens mijn zou dat in een spel als UT toch wel een snelheidswinst van meer dan 25% kunnen opleveren...[/quote]Hier noem je dus gewoon wat Win NT4/Win 2k doet. OS op de ene CPU, en een van de threads op CPU 2.

Q3A is speciaal aangepast voor SMP. Die kan zichzelf splitsen in 2 threads, waarbij dus beide CPU's benut worden. Hierbij haal je nooit 2 x de single CPU score, want de 2 threads zijn afhankelijk van elkaar, en het zal dus gebeuren dat de ene thread moet wachten op de thread die op de andere CPU draait.

Het probleem zit 'em in het OS. Dat moet in staat zijn om threads netjes te verdelen over de beschikbare processors. Je kan NOOIT één proces/thread op meerdere CPUs draaien.

Verder:<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>maar is het gewoon niet zo dat een SMP systeem veel relaxter loopt en de reactietijd in het OS enorm verbeterd doordat het niet hoeft te wachten totdat de processor met iets anders klaar is...[/quote]Erhh, sorry, dat is het wél (ik werk zelf op 2 HP9000 bakken (een J200 en een J2240) met allebei 2 stuks 64 bit Risc CPUs, OS = HP UX 10.20, dus ik weet wat SMP kan betekenen.)

Wat jij zegt is alleen waar wanneer de prioriteiten van threads niet goed geregeld is. Als een grote bewerking dezelfde prioriteit meekrijgt als 'system' dan krijgt het OS geen voorrang. Maar een goed besturingssysteem dat netjes SMP benut laat dat nooit gebeuren. Input/view functies krijgen altijd voorrang (als het goed is tenminste) op grote langdurige rekentaken.

Op het moment dat jij bij je pointer die klote zandloper ziet staan (bij een single CPU systeem tenminste) werk je op een SMP systeem gewoon verder. Een DTP'er (voor wie niet weet dat is: Desktop publisher, een graficus dus) die net een plaatje van 50 MB door een photoshop filter haalt kan vrolijk in een ander plaatje even lopen klussen, omdat die zware rekentaak door de andere CPU gedaan wordt. Bij een single CPU systeem krijgt de 2e bewerking 45%, en de eerste ook 45% em 10% over voor OS en dergelijke. Dan duren beide handelingen bij benadering weer 2 keer zo lang als op een SMP systeem.

Idem met simulaties (Pro/Cast, C-Mold, Moldflow, Deform 2D/3D en dergelijke ): Je kan een simulatie uit laten voeren door de 2e CPU op de volle 100% en dan nog ander werk doen. Dit werkt beter dan de situatie op een single CPU systeem, daarbij krijgt de simulatie de 90% system idle time toegewezen, en is de overige 10% (ongeveer dan) voor de rest van je handelingen.

Of je laat 2 simulaties tegelijk draaien, waarbij de eerste 90% krijgt, en 10% rescources voor overige processen en de 2e simulatie krijgt 100% van de 2e CPU.

[XElD]

Hmmm, dat NT het OS helemaal op 1 proc. zette wist ik niet... ik had ergens een keer gelezen dat NT de kernel verdeelde over de proc's...
(van linux wist ik wel zeker dat het de OS op 1 proc draaide...)

Ik vroeg me alleen af of een zo'n app (1 grote thread neem ik aan) dan automatisch op de 2e 'lege' proc gezet werdt...

[JumpStart]

... ten tijde van de Pentium II Xeon was het alleen nodig om de 2e CPU actief te koelen, de eerste had alleen passieve koeling nodig, omdat de zware rekentaken altijd op CPU 2 gezet werden. CPU 1 had het OS voor z'n rekening en kon dus af met passieve koeling only (verbeter me als ik het fout heb, het zou ook net andersom geweest kunnen zijn.)

... zouden ze nou niet meer zo snel doen denk ik ... PIII 1 GHz Xeon en alleen passieve koeling ?? ZzzzZZzZAPPP ... " waar komt die lucht vandaan ?? en waarom zie ik een zwart scherm ?? "

[XElD]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>ZzzzZZzZAPPP ... " waar komt die lucht vandaan ?? en waarom zie ik een zwart scherm ?? [/quote]Aha! ... weer een voordeel van SMP: 1 CPU kapot, gewoon verder gaan met alleen de andere dan... (aangenomen dat mobo dit ondersteund)