Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 16 reacties
Bron: SystemLogic

Op SystemLogic is een zeer uitgebreid artikel verschenen over de theorie achter multithreading. Het plaatsen van een tweede processor in een systeem heeft zoals je weet nooit automatisch als gevolg dat de performance van het systeem twee keer zo hoog komt te liggen. De redenen hiervoor zijn allerlei problemen die zowel soft- als hardware tegenkomt in een SMP omgeving. Dingen waar bijvoorbeeld rekening mee gehouden moet worden zijn caches en latencies. En manier om dat op te lossen wordt een steeds betere optie en dat is een enkele chip bakken die zich gedraagt als meerdere processors. Volgens de laatste geruchten zal Intel zoiets in de loop van 2002 introduceren in haar Xeon processors, maar ook andere bedrijven zoals IBM en Compaq zijn er al intensief mee bezig. Men gaat uitgebreid in op de verschillende methoden en natuurlijk ook de nadelen die deze technologie met zich meebrengt.

Hoewel men over het algemeen zonder te hoeven liegen kan zeggen dat de software multithreaded geprogrammeerd moet zijn om voordeel te doen van een SMP of SMT systeem is deze stelling niet altijd per definitie waar. Er zijn namelijk een aantal algoritmes bedacht die een programma tijdens het draaien analyseren en, waar mogelijk, in meerdere draden opsplitsen. Dit kan ervoor zorgen dat de beschikbare bronnen van een single-chip multithreading processor nog beter gebruikt worden. Hoewel n van de grondleggers van deze techniek bij Intel werkt is het niet duidelijk of Jackson Technologie gebruik maakt van dit soort kunstjes.

En van deze methoden is het zogenaamde Slipstreaming, waarbij elk programma door de processor twee keer tegelijk wordt uitgevoerd. De processor kijkt altijd een stukje vooruit in de ene stream, zodat de tweede stream weet waar de code heen gaat voor deze daadwerkelijk wordt uitgevoerd. Dat is handig, want de tweede stream kan op dat moment nutteloze code verwijderen. Dezelfde code wordt vervolgens ook uit de hoofdstream geplukt en daardoor kan een single-threaded programma tot 50% sneller gaan lopen op een multithreading processor, zonder extra programmeerwerk. Hoewel dit allemaal nog heel erg geavanceerd klinkt zal het waarschijnlijk niet al te lang duren voor dit soort ideen verwerkt zullen zitten in mainstream computers:

Foster 200 pix, schuin CMP uses two (or more) smaller cores to increase functional unit efficiency (removing horizontal waste), and has shown itself in new processors such as the Sun MAJC architecture, and the IBM POWER4; and the SledgeHammer from AMD should too. CMT and FMT both use the ability to switch rapidly between threads to hide memory latencies, and decrease vertical waste. CMT can be found in the MAJC architecture, and FMT in the Terra Supercomputing architecture. SMT operates by running any thread, in any functional unit, on any clock, thus removing both horizontal, and vertical waste, and will be found in the Alpha 21464, and possibly in a later incarnation of the P4 architecture. DMT and Slipstreaming processors both aim at increasing single-thread performance.

Though the many varied forms of multithreading take very different approaches, the goal is the same: higher real-world throughput. All of these techniques allow additional functional units to be added to a processor, and show something more akin to return to scales than to diminishing returns. While previous processors tended not to go far beyond 4 functional units per processor, due to diminishing returns, there are now techniques available which allow more units to be added with increased efficiency. We shall see some strange architectures in the future...
Moderatie-faq Wijzig weergave

Reacties (16)

Ik vind dit wel een beetje een wazige technologie. Ik snap wel wat ze doen, maar gat het dan niet helemaal mis als je heel veel processen hebt. Wat gaat het OS (zeg Linux) dan doen? Gaat dat niet ontzettend door elkaar lopen met die multithreading en multitasking? Nu bepaald de kernel dus welke thread er nu weer eens wordt uitgevoerd, maar hoe kunnen ze dat dan weer combineren met die processor??

* 786562 RG
Ach toen de pentium eerst uitkwam was het ook allemaal een beetje vaag men had het over 2 instructies tegelijk uitvoeren etc. Toen dacht ik ook van wat nou als instructie een van de ander afhankelijk is enzo. Daar haden ze dus ook al oplossingen voor gevonden. Waar ze nou volgens mij meer heen willen is dat de processor niet annalyseert wel 2 instructies tegelijk uitgevoerd kunnen worden maar ook welke groep van instructies tegelijk uitgevoerd kan worden.

Het wordt ook allemaal erg geavanceerd en er gaan een hoop transistoren in dit soort logica welke een annalyse aan het doen is die veel beter gedaan kan worden door de compiler die de code genereerd. De P4 heeft al een aantal extra instucties voor bv. branchpredictie waardoor de compiler van te voren al kan zeggen welke code het meest uitgevoerd wordt zodat de pipeline efficient gevuld wordt.

Zelf zie ik meer in de IA64 architectuur omdat de compiler hier veel meer aan kan geven. Ik weet niet in hoevere dit is maar ik hoop dat daarmee dit soort dingen weer wat vereenvoudigd kan worden. Want ik ben bang dat dit soort nieuwe technieken een hoop vage bugjes met zich mee gaat brengen omdat het heel erg complex wordt om alle situaties die zich voor kunnen doen op zo'n multithreading processor te analyseren.

Verder is SMP op een processor nattuurlijk ook een goed ID en laat de programmeurs dan maar meer threads gebruiken voor zware taken.
't is eigenlijk jammer dat de tijd van het 'bitneuken' voorbij is. Tegenwoordig wordt er nog maar weinig gekeken naar het aantal kloktikken oftewel de efficientie van een applicatie in aantal/soort instructies(=snelheid).

tzal wel inherent zijn aan de enorme toename van de prestaties van huidige systemen.
Er is inderdaad een tendens om daar helemaal niet meer naar te kijken. Met een profiler kun je prima zien in welk deel van de code je programma de meeste tijd doorbrengt, maar soms kun je daar gewoon niets aan doen. System calls die veel tijd kosten kosten nu eenmaal veel tijd.....

Dit mag natuurlijk geen excuus zijn om slordig om te springen met resources. Als je kijkt naar sommige moderne software dan worden de minimum-eisen soms wel heel erg hoog...
Inderdaad jammer...feit is wel dat Windows applicaties grotendeels gebaseerd zijn op Windows API calls en je dus niet zoveel meer kan bitneuken... ;( , of je moet al die calls beginnen vervangen door eigen code.
>En manier om dat op te lossen wordt een steeds betere optie en dat is een enkele chip bakken die zich gedraagd als meerdere processors


Heeft de G4 dat niet al lang?
Volgens mij is er nog geen processor die zich gedraagd als meerdere simultane processors. Wel kunnen processors meerdere dingen per kloktik verwerken, maar daarnaast doet 1 instructie er tegenwoordig ook meerdere kloktikken over.
Een on chip SMP bestaat volgens mij nog niet. Eigenlijk snap ik het nut ook niet helemaal. De latencies gaan omlaag in vergelijking met SMP, maar je kunt beter 1 snellere processor hebben. Want niet alle taken zijn geschikt voor SMP.
Als je kijkt naar processor behoefte van tegenwoordig dan heb ik voor de meeste single threaded dingen niet een snellere processor nodig. Ik bedoel hiermeee sneller textverwerken etc. is absoluut niet nodig. Verder voor de dingen waar het wel geld is het verhaal van de kip en het ei erg van toepassing. Er moet toch iemand beginnen. Als SMP een beetje standaard zou worden dan wordt de software die dit nodig heeft zoals o.a. video/beeldbewerking hier wel voor aangepast. Dus ik ben het niet helemaal eens met de stelling je kunt beter een snellere processor hebben want ik hoop dat dit in de toekomst veranderd. Want met steeds kleiner wordende processoren moet de overige ruimte op de chip ook zo efficient mogelijk gebruikt worden.
Het mooie van SMP is de mogelijkheid om ieder parallellisme dat er is ( Thread level of Instruction level ) te benutten.... Alpha is bezig met een SMP-chip die over niet al te lange tijd klaar is ( benchmarks zijn er al - artikel ligt thuis =) ) en dat ding haalt met een max mogelijke IPC van 8 gemiddeld zo'n 6 IPCs !!! Best wel een techniek die we meer gaan zien denk ik toch zo, maar eerst zien, dan geloven }>
Maar hoe komt die tweede processor verderop in de stroom? Deze kan niet gewoon sneller rekenen, want dan kun je beter direct de resultaten van deze tweede processor gebruiken.

De code wacht bijvoorbeeld op een event (user input, signaal op netwerkkaart). Daar zullen beide processoren op moeten wachten. En dan? Hoe kan die tweede processor nu verderop in de codebrij al bezig gaan?
Zonder multithreading dus.
daar ben ik net een stukje over aan het schijven voor een studiepunt thx wouter tinus.
Ehm... het plaatje doettut niet :(
typo: "...die zich gedraagd
Te koop asus cuv4x-d met 2x PIII 800Mhz


(zodra RC5-Project afgelopen is dan) :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True