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 , , 169 reacties
Submitter: player-x

Microsoft heeft nauw samengewerkt met Intel om Windows 7 betere ondersteuning voor hyperthreading te geven dan voorgaande besturingssystemen. Ook raadt Microsoft bedrijven aan de uitrol van Vista te staken.

Bill Veghte, senior vice-president bij Microsoft voor de ontwikkeling van Windows, kondigde afgelopen week bij Microsofts TechEd-conferentie in Los Angeles aan dat Microsoft en Intel nauw samengewerkt hebben om Windows 7 het meeste uit de hyperthreading-technologie te laten halen. Onder andere netbooks zouden voordeel kunnen halen uit de verbeteringen, aangezien de Atom-processor wel een enkele core heeft, maar de werklast over twee threads kan verdelen. Ook de Core i7- en de komende Core i5-cpu's van Intel hebben de hyperthreading-technologie aan boord. Wel moeten applicaties hier ondersteuning voor bieden, maar aangezien het aantal processors met twee of meer rekenkernen groeit, wordt er ook steeds meer software ontwikkeld die de mogelijkheid biedt dat er aan meerdere draadjes tegelijk wordt gewerkt. Details over de verbeteringen in de ondersteuning gaf de Microsoft-medewerker niet.

"Als je net begonnen bent met het testen van Vista zou ik overstappen op de Windows 7 Release Candidate en daarmee verder gaan", raadde Veghte bedrijven aan in zijn keynote-toespraak. Hij noemde de kwaliteit van het nieuwe besturingssysteem als reden om over te stappen. Veghte zei dat zijn bedrijf in augustus volledig klaar wil zijn met Windows 7.

Veghte liet weten dat Microsoft er alles aan doet om te voorkomen dat Windows 7 bij de introductie dezelfde compatibiliteitsproblemen vertoont als bij de lancering van Windows Vista. "Bij de Release Candidate hadden we 10.000 hard- en softwarebedrijven die werken aan ondersteuning voor Windows 7", aldus Veghte, die claimde dat Microsoft heel dicht bij volledige Windows 7-compatibiliteit voor praktisch alle grote hardware- en softwarebedrijven is.

Moderatie-faq Wijzig weergave

Reacties (169)

Wat is precies het nut van hyperthreading als je in feite alsnog maar 1 item per keer kan afhandelen?
Volgens mij, maar ik weet het niet zeker, is het antwoord pipelining:

Pipelining zorgt ervoor dat een bewerking in de computer in stappen wordt gedaan. Bijvoorbeeld: haal getal uit variabele A op, haal getal uit variabele B op, tel de opgehaalde waarden bij elkaar op, schrijf de gevonden waarde weg ik variable C.
Dit zijn vier stappen die ieder door een ander deel van de processor kunnen worden afgehandeld. De inactieve onderdelen van een processor kunnen zich ondertussen bezighouden met de volgende regel programmacode (assembly code), maar ze kunnen ook een heel andere taak gaan afhandelen, een andere thread. Dit is vooral aantrekkelijk als er in een programma veel gebranched (bijvoorbeeld if-statements) wordt. Dan kan het aantrekkelijker zijn om twee totaal verschillende taken uit te voeren in plaats van branches te moeten voorspellen.
Hyperthreading is geen volledige multicore, maar het is wel meer dan een single core. Soms levert dat veel winst, soms ook niet.
Ik kan me herinneren dat in de eerste Hyperthread processoren de optie standaard uit stond, omdat hij bij de meeste toepassingen het geheel alleen maar trager maakte. Nu veel programma's (waaronder Windows 7) op multicore zijn voorbereid kan dat anders worden.

@xahodo
Bedankt voor de toevoeging. Het verschil tussen machinetaal en assembly is mij bekend, ik wilde mijn uitleg duidelijk houden daarom die 1% (jouw schatting) over het hoofd gezien ten behoeve van de eenvoud. Wat jij zegt over shared resources is was ik bedoelde, ik heb geen rekening gehouden met meerdere resources van hetzelfde type (meerdere gedeeltelijke pipelines).

[Reactie gewijzigd door 84hannes op 18 mei 2009 11:00]

Nee, pipelining is heel wat anders dan hyperthreading.

Pipelining zorgt ervoor dat de instructie makkelijker te verwerken is door de processor. Daardoor kunnen de verschillende onderdelen van een core beter benut worden. Tot dit punt heb je volledig gelijk.

Vervolgens begin je over hyperthreading, en sla je de plank volledig mis. Om het te reduceren tot een analogie: Pipelining is "voorkauwen" waar hyperthreading "meerdere monden om mee te kauwen hebben" betekent.

Bij hyperthreading zijn er meerdere pipelines aanwezig die elk zorg te dragen voor één of meerdere isntructies (nagelang de capaciteit van het moment), zolang hij daardoor niet de andere pipeline(s) in de weg zit. Dit is gelijk het probleem van hyperthreading.

Bij hyperthreading gebruiken meerdere pipelines dezelfde onderdelen van de core. Dit verhoogt de belasting, en maakt nog efficiënter gebruik van de core, maar kan ook vertraging met zich mee brengen omdat twee pipelines hetzelfde onderdeel nodig hebben (en maar eentje toegang krijgt).

Branch prediction (wat al aanwezig is sinds de eerste pentium 1) is ook iets wat jij aansnijd wat hyperthreading niet doet (in de pentium, tenminste).

Branch prediction zorgt ervoor dat de processor van te voren voorspelt of een voorwaardelijke sprong wel of niet uitgevoerd wordt en zet vervolgens de instructies die hij nodig "denkt" te gaan hebben alvast klaar.

De Itaniums gaan daar nog een stapje verder in, en doen het zoals jij schetst. Zij komen een sprong tegen en gaan vervolgens beide mogelijkheden uitwerken iedere in een eigen pipeline, totdat óf de twee samenkomen óf hij bij de voorwaardelijke sprong arriveerde die de thread split aanvankelijk activeerde.

Nog even wat anders: machinetaal is de taal zoals die door de computer verwerkt wordt (voor een ongetraind oog volledig onleesbaar), terwijl assembly een taal is die (voor 99%) één op één geconverteerd naar machinetaal kan worden. Die andere 1% gaat over dingen om ons mensen het leven gemakkelijker te maken, maar die een computer compleet niet begrijpt zonder tussenkomst van een assembler (een programma wat assembly omzet naar machinetaal).
Bij hyperthreading gebruiken meerdere pipelines dezelfde onderdelen van de core. Dit verhoogt de belasting, en maakt nog efficiënter gebruik van de core, maar kan ook vertraging met zich mee brengen omdat twee pipelines hetzelfde onderdeel nodig hebben (en maar eentje toegang krijgt)
Dit is dus onjuist... een core heeft maar 1 pipeline, de grap is deze pipeline bestaat uit een aantal stappen. Laten we zeggen 20... Stel je het volgende eens voor, je hebt een programma dat met de processor bezig is en dus de volledige 20 stappen gebruikt van de pipeline, na deze 20 stappen moet hij om de stap (dus stap 2, 4, 6, 8 etc etc.) wachten op de hardeschijf totdat die voldoende in het geheugen heeft gezet. oftewel je houd 10 stappen over waar je normaal gesproken niets mee kan doen, hier komt HT dus om de hoek kijken... die maakt een 2e VIRTUELE (hij is dus niet fysiek aanwezig in de processor alhoewel de software denkt van wel) pipeline aan en probeert dus deze VIRTUELE pipelin samen te voegen met de FYSIEKE pipeline om zo dus de processor efficienter te gebruiken, immers als er niets in stap 1,3,5,7 etc. staat gebeurt er dus ook niets in de processor. Feit is je handeld nog steeds alle berekeningen NA elkaar af en niet NAAST elkaar.
Ja, HT kan een programma trager maken, omdat je per thread dan de helft minder cache geheugen hebt. Intel heeft een zodanig grote cache dat veel benchmarks er compleet in passen. Hiermee hebben ze lange tijd de effecten van hun tragere geheugen bus kunnen maskeren. Maar met HT aan, kan dat voordeel verloren gaan.
Maskeren? Alsof ze het wouden verbergen, er zijn gewoon 2 mogelijkheden om iets te bereiken en ieder kiest zijn eigen weg...

Een auto die snel optrekt vind ik bruter dan een auto die sneller kan rijden maar er is een afstand waarbij de auto's precies op hetzelfde moment zijn en dan zal de snelste auto pas uitlopen ;) Oftewel dat kan na 1 km zijn maar ook naar 5 km. en als je nooit verder dan 4 km moet dan is de snel optrekkende auto altijd in het voordeel :) Dus ja of Intel nou hun langzame geheugenbus probeert te fixen of AMD met een snelle geheugenbus hun weinige cache proberen goed te maken weet ik zo net nog niet ;)

ps komt misschien beetje vaag over maar kan niet zo goed uitleggen :D
Je kunt bij hyperthreading wel degelijke 2 items in één keer afhandelen. En dat is dan ook het nut van hyperthreading.

Het probleem bij hyperthreading is echter, dat dat niet onder alle omstandigheden kan. Verschillende soorten berekeningen vergen verschillende onderdelen van de cpu. Daardoor is het mogelijk dat bij een bepaalde berekening, een ander gedeelte van de cpu idle is. Met hyperthreading probeer je dan alsnog de rest van de cpu ook te gebruiken.

Dit is dus wezenlijk verschillende van het gebruik van meerdere volwaardige cores, waarbij de verschillende threads dezelfde soort berekeningen tegelijk kan doen.

Hyperthreading is geen volledige multicore, maar het is wel meer dan een single core. Soms levert dat veel winst, soms ook niet.
Er zijn enkele praktijkvoorbeelden te noemen waarin hyperthreading niet goed werkt en dan juist een vertraging geeft:

- Benchmarks - Hierdoor heeft hyperthreading een slechte naam gekregen onder overclockers en menig tweaker. Een benchmark voert meestal vrijwel continu dezelfde handeling uit waardoor hyperthreading z'n werk niet goed kan doen.

- Multimedia streams - Hierbij heeft hyperthreading zeker wel nut, het probleem is alleen dat het in sommige gevallen wel een performance hit geeft. Hoewel de gemiddelde decoding snelheid hoger kan zijn met hyperthreading aan kan de minimum decoding snelheid juist lager uitvallen. Bij een multimedia stream is de minimum decoding snelheid het belangrijkste aangezien een te lage decoding snelheid framedrops tot gevolg heeft (wat als storend kan worden ervaren).

- Overclocken - Doordat een groter deel van de core gelijktijdig gebruikt wordt is het opgenomen vermogen normaal hoger en is de chip dus warmer. Dit komt het overclocken niet ten goede. Daarnaast zijn er juist wat lastige circuits nodig die vaak het slechts zijn over te clocken. Waar in het ene geval een benchmark wel uitgevoerd had kunnen worden op een bepaalde snelheid kan de hyperthreading ervoor zorgen dat de boel vastloopt.

Deze drie scenario's hebben voornamelijk voor de slechte naam van hyperthreading gezorgd. Benchmarks tonen geen snelheidsverbetering en vaak juist een slechtere snelheid. Daarnaast werkt het overclocken minder goed en kun je niet eens meer fatsoenlijk een filmpje kijken.

Toch is hyperthreading een zeer nuttige techniek en kan het zeker een snelheidsverbetering brengen mits de software er juist mee om gaat. Maar het is logisch om te zien waarom niet de hele wereld staat te juichen om hyperthreading en Intel het voor hele series aan een stuk heeft weggelaten.
Om even de hele discussie mooi af te sluiten, een linkje met het gemeten verschil bij verschillende benchmarks... Het maakt soms uit, soms ook niet het ligt er een beetje aan wat voor applicaties je gebruikt en wat je wilt doen. Het word voornamelijk alleen sneller als je computer moet multi-tasken. Het enige wat mij persoonlijk opvalt is dat mijn HT (fake-core's) in de task manager vaak idle zijn en alleen de eerste van de 4 core's (de echte cores dus) aan het werk zijn... Af en toe schiet de HT core omhoog...

Linkje: http://www.hardware.info/...ntel_Core_i7_Uitgediept/3
Ik kan me ook herinneren dat het in servers vaak werd uitgezet, omdat het daar veel vaker nadeling was dan voordelig.
Dat is heel erg afhankelijk van de situatie.

Exchange server 2003 had 20 tot 30% prestatie winst over het algemeen.
SQL heeft in veel gevallen ook flinke winsten, maar het kon daar in bepaalde situaties ook trager worden.

Een groot nadeel van HT, is dat het troubleshooting lastiger maakt. Het is moeilijker te bepalen of je server een cpu bottleneck heeft of niet.

Bovendien gaat finetuning van het aantal threads tov cpu's volledig de mist in als je applicatie niet in de gaten heeft dat het om hyperthreading cores gaat ipv echte cores.
Daar moet je dan handmatig ingrijpen.
Als dat de enige 3 nadelen zijn, heeft HTT dus nut voor meer dan 90% van de mensheid...

Wat zeg nou zelf, de minimum decoding snelheid? Dat zijn wrs negatieve pieken die dus helemaal niet boeien.
Er zijn nog meer nadelen, maar dit zijn wel de voornaamste.

Hyperthreading heeft dan ook zeker veel zin voor een groot deel van de mensen, maar heeft in de loop der tijd gewoon een slechte naam gekregen.

Overigens zijn dit niet de enige redenen waarom hyperthreading een slechte naam heeft gekregen. Andere factoren zijn de slechte performance van de P4 waar het origineel op geintroduceerd werd en het feit dat veel mensen het niet snappen en het als 'fake' zien.

En de minimum decoding snelheid kan zeker wel boeiend zijn als dat het verschil maakt tussen een soepel filmpje kijken of continu met framedrops te zitten. Al is dat met de snelheden van de moderne CPU's niet direct heel boeiend en er is ook geheugen genoeg om een redelijke buffer op te bouwen. Maar op een Atom systeem kan dat het verschil maken tussen 720P materiaal wel of niet goed kunnen bekijken.

[Reactie gewijzigd door TRRoads op 17 mei 2009 14:50]

Als mensen dat zouden snappen zou het fenomeen "slechte naam" niet bestaan.

Dus zodra mensen begrijpen dat een mening geen feit is is jouw stelling met bijbehorende vraag irrelevant. Maar zolang mensen dat niet snappen ligt het antwoord op je vraag in de stelling die je poneert.

Waarom stel je 'm eigenlijk?
Wat je zegt is in zekere zin waar, maar je eerste alinea i erg isleidend: het lijtk voor het OS dat er twee dingen tegelijk gebeurd zijn, maar de CPU-kern heeft nog steeds maar 1 instructiepipeline, en kan onder geen beding 2 dingen per keer tegelijkertijd berekenen.
wikipedia lijkt wat anders te zeggen:
Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources. [...] When execution resources would not be used by the current task [...] a hyper-threading equipped processor can use those execution resources to execute another scheduled task.
http://en.wikipedia.org/wiki/Hyper-threading
Dat klopt sowieso niet, vrijwel elke moderne processor is out-of-order (atom is uitzondering). Dat houd in dat ze de instructies zoveel mogelijk paralel uitvoeren. Door afhankelijkheden in de instructiestroom werkt dat niet altijd even lekker - hyperthreading maakt beter gebruik van de executieunits door de delen die niet voor 1 thread bruikbaar zijn in te zetten voor een 2e thread.
Klopt als een bus; ik heb een tijd terug (januari 2004 t/m oktober 2006) gedraaid op een dual Xeon 2.67 met Hyperthreading. Met hyperthreading aan had ik ongeveer een 25% hogere snelheid, tegenover hypterthreading uit, als ik de tijd opnam die in totaal voor een aantal gelijk lopende taken nodig was.
Hyperthreading is niks anders dan 2 of meer ipv 1 tread op die reken eenheden op één core los te laten. Bij Ci7 zijn dat 6 units ALU's die niet gelijkwaardig zijn. Waar met HT enable 2 treads om de ALU's/ units kunnen vechten. Wat oudere CPU hebben bepaalde typen er 3.
Out off order heeft een sweetspot van onder de 3 ALU wat het wat regelmatiger kan aan spreken, meer zou overkill zijn. Op enkele uitzonderlijke apps na. Wil je meer eenheden vaker en dus effectiever gebruiken dan is HT een must.

Er worden in het meest ideale out of order situatie 6 items per 2 treads verwerkt.

Minst ideale 1 items per 2 treads. Als een van de twee treads wacht op de andere. ivm synchronisatie of tread afhankelijkheden. Of single treaded app.

Ik denk dat de Extra ALU kwa transistor kost op de totale diespace zeer rendable zijn om toch gemiddeld een leuke IPC boost te geven. Met een redelijke bezetting van die 6 ALU als dat gemiddeld 4 van de 6 zijn krijg je een aardige boost. over een 3 of 4 ALU HT loze core.

éen andere doom senario is dat sommige app de treads heel mooi out of order te verdelen zijn en dus parralel te verwerken. En als single tread daarmee alle unit's bezetten. Een code mix dat met één tread alle 6 units of de gross kan bezetten.
Dan is er niks over voor HT 2de tread. Er worden dan ALU verdeel over 2 treads die beide alle kan benutten en dan krijg je die HT overhead er over dan krijg tov 'n HT loze of disablde core zelfs performance verlies.
Maar deze situatie wordt nogal meer een uitzondering omdat de ALU's niet gelijkwaardig zijn.

Dit geld dus voor de Ci7.

HT is dus geen wonder middel maar sommige app krijgen een leuke boost. Maar vele amper of zelfs een performance hit.
Dus je hebt uitschieters maar als gemiddeld je vaker een performance winst hebt is het mooi meegenomen.
Die sweetspot hangt wel af van de lengte van pipeline, en de cache grootte (branch predictie). Ik weet niet of die voor de core i7 langer geworden is, maar gezien de vorse uitbreiding van met name SSE zou je dat wel verwachten.

Voorheen had je een enkele core waarop je hyperthreading toepast. Nu heb je meerdere cores waarop je dat doet. Als het OS bijhoud welke pipeline bij welke core hoort, kan het voorkomen of promoten dat meerdere threads van een enkele applicatie bij dezelfde core terecht komen. Bijvoorbeeld Audio en video decoding benutten hele specifieke eenheden van de ALU (sse extentie). Dan is het voordelig om threads van verschillende typen applicaties bij eenzelfde core onder te brengen, en zo min mogelijk threads van eenzelfde applicatie.

Een enkele applicatie zal dus mischien niet altijd zoveel voordeel hebben, maar draai je er meerdere parralel, op een multicore processor, kun je meer winst verwachten.
Als een instructie gegevens uit het RAM nodig heeft om uitgevoerd te worden, zal een processor zonder HT wachten op die data, en dan de instructie uitvoeren. Hierdoor wacht de CPU een tiental cycles per keer dit voorvalt.

Een CPU met HT geeft echter elke kern 2 instructiestacks, waartussen hij voortdurend wisselt. Als er dan een instructie is die RAM-data nodig heeft wordt er, ipv te wachten, even enkel met instructies van de andere stack gewerkt, tot de data uit het RAM in de cache is gekopieerd.

Dit is dus ook de reden waarom je 2 CPUs ziet in er kern met HT: het OS merkt 2 instructiestacks op. Of het OS nu doorheeft dat het 1 CPU-kern is of niet doet er niet toe: een kern met HT is dan ook pas nuttig wanneer het OS hem als 2 kernen behandelt.

HT is verder ook geoptimaliseerd voor "oude" (slechte :p) code: als je bv een programma hebt dat active waiting gebruikt, zal een CPU zonder HT op 100% draaien tijdens het wachten. Een CPU met HT zal slechts op 50% draaien: bij NOP-instructies wordt de capaciteit van de instructiestack gelimiteerd tot de helft.
je kan 1 taak opdelen in 2 (bij 1 kern) stukken. waardoor theoretisch de tijd dat het kost een item af te handelen wordt gedeeld door 2.
Volgens jou zou een processor met hyperthreading dus precies 2x zo snel zijn als een processor zonder hyperthreading? Dat is onzin want in werkelijkheid is het maar ongeveer 5 tot 10%, wat nog steeds een mooie prestatiewinst is, maar niet zo mooi als dat jij het doet overkomen.

Het blijft maar 1 core, en er komt niet zomaar uit het niets rekenkracht bij ofzo. Hyperthreading zorgt er enkel voor dat de beschikbare rekenkracht wat efficiënter gebruikt kan worden.

Door 2 threads parallel te verwerken is de kans kleiner dat de processor even niets te doen heeft doordat bijvoorbeeld op het geheugen of andere delen van de processor gewacht moet worden.
Onder windows is het 5 tot 10%... onder linux heb ik 30% (dit was een p4) gemeten, en wordt het wel degelijk aangemerkt als 2 cpu's (ook al is het niet zo).

Hyperthreading bestaat in principe uit anderhalf core. Ik wil daarmee zeggen dat (sommige) instructies twee keer op dezelfde core zijn gezet, maar dat nog niet geldt voor elke instructie en al helemaal niet voor de registers. Dit betekent dat in sommige situaties er twee instructies parallel uitgevoerd kunnen worden op dezelfde core.

Om te voorkomen dat dit tot problemen lijdt, mogen de instructies niet dezelfde registers aanspreken, toegang zoeken tot exact hetzelfde geheugen-adres, toegang zoeken tot exact hetzelfde hardware poort of iets veranderen wat de ander zou kunnen beïnvloeden.

Dit heeft tot gevolg dat als een programma gebruik wil maken van hyperthreading, het er speciaal op gecompileerd moet worden (de sourcecode hoeft er daarentegen weinig rekening mee te houden) om de instructies dusdanig te plaatsen dat er zo min mogelijk conflicten zijn. Dit is een gecompliceerde taak, omdat niet iedere instructie even lang duurt.

Mijn kennis is echter wel verouderd. Dus de situatie kan flink verbeterd zijn, maar in de hoofdlijnen zal het nog steeds hetzelfde idee zijn. Als men profijt wil hebben van HT, zal men ervoor moeten compileren.

Eerdere versies van windows waren niet gecompiled met HT, nu zullen ze windows 7 hoogst waarschijnlijk juist op HT compileren. Intel processoren zullen er in ieder geval profijt bij hebben.
Bijna alles wat je zegt is onzin,

1. Hyperthreading heeft niets te maken met windows of linux. De mogelijke winst op zowel linux als windows is gelijk.

2. Instructies worden niet twee keer op een core gezet, instructies staan in het geheel niet op een core. Registers zijn er juist wel in overvloed, veel meer dan je in programmacode aan kunt sturen,

3. Hyperthreading werkt met verschillende threads die elk een eigen context hebben, de registers in een context hebben niets met de registers in een andere context te maken, anders dan dat ze dezelfde naam hebben.

4. De source code moet juist wel speciaal voor threads worden geschreven, en als het kan moet de tweede thread zo geschreven worden dat die gecompileerd wordt als instructies die gehyperthread kunnen worden. De compiler is niet echt relevant. Tijdsduur van instructies is ook niet relevant, vooral niet op een OS dat multitasking is, want dan kan op elk moment een ander programma aan de beurt zijn.

5. Je kennis is niet verouderd, maar nooit correct geweest.

6. Windows wordt niet gecompileerd op hyperthreading, dat is niet iets wat je kunt doen. Wat Windows nu wel doet is beter raden welke thread op een fysieke core gezet moet worden en welke thread op een hyperthread core gezet kan worden,
@4 er zijn processors die dit hardwarematig doen en een intel compiler doet t over het algemeen toch een stuk beter dan zijn concurrenten imho
Om te voorkomen dat dit tot problemen lijdt, mogen de instructies niet dezelfde registers aanspreken, toegang zoeken tot exact hetzelfde geheugen-adres, toegang zoeken tot exact hetzelfde hardware poort of iets veranderen wat de ander zou kunnen beïnvloeden.
Het zijn juist de registers die dubbel uitgevoerd zijn. Alle data registers, debug registers, segment registers, control registers en debug registers zijn dubbel uitgevoerd alleen niet alle MSR's(machine specific registers) zijn dubbel uitgevoerd maar die worden toch niet zo regelmatig gebruikt dat het wat uitmaakt. Ook de APIC (interupt controller) is dubbel uitgevoerd. In de i7 schijnen nog wat meer gedeeltes er twee keer in te zitten maar daar heb ik nog geen ervaring mee.
Dat de registers er dubbel in zitten is ook wel logisch. De registers bevatten waarden die de staat van het programma bij houden zoals de PC(program counter) die bepaald waar het programma is in de programma code maar ook de data registers mogen niet zomaar van waarde veranderen alks een andere thread aan de slag gaat aan gezien veel compilers parameters en (tijdelijke)variabelen in de registers opslaan. Als de registers niet dubbel uit gevoerd waren zouden ze dus elke keer als een andere hyperthread een register gebruikt opgeslagen moeten worden en die van de nieuwe hyperthread moeten worden opgehaald als je dit doet heb je het niet meer over hyperthreading maar ben je eigenlijk gewoon taskswitches aan het doen. Bij een hyperthreadingachtige implementatie is dus het twee keer uitvoeren van de registers altijd de eerste stap.
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 1, Hoofdstuk 2.2.5)

@JoJo_nl:
AMD processoren ook hoor.
Ik snap dat je AMD heel geweldig vindt maar ze hebben niet alles wat intel heeft (en anders om). HTT heeft AMD in ieder geval nog niet, dus AMD proceccors zullen hier (voorlopig) nog geen baat bij hebben. Hoe stoer AMD ook is 8-). De vraag is ook of deze technologie bij AMD processors wel zo makkelijk toe te passen is en of die enigzins nuttig is, misschien maakt AMD al wel heel efficient gebruik van hun chips.

En hypervisors en hyperthreading hebben (behalve dan dat hun naam met hyper begint) niks met elkaar te maken.

@_js_
4. De source code moet juist wel speciaal voor threads worden geschreven, en als het kan moet de tweede thread zo geschreven worden dat die gecompileerd wordt als instructies die gehyperthread kunnen worden. De compiler is niet echt relevant. Tijdsduur van instructies is ook niet relevant, vooral niet op een OS dat multitasking is, want dan kan op elk moment een ander programma aan de beurt zijn.
Als je als programma baat wil hebben bij HT zal je zoals je al zegt multithreaded of multiprocess code moeten schrijven. Je zal in al je threads de basis regels van multiprocess en multithread programmeren moeten volgen maar je kan gewoon alle instructies gebruiken en je hoeft geen rekening te houden met wat je tweede thread is. Voor de processor is er geen eerste en tweede thread ook kan jou programma gewoon samen met een ander programma op de zelfde hyperthreading processor tegelijk draaien. Het af stemmen van de threads op elkaar op tijdsduur en dergelijken is compleet irrelevant. En een niet multitasking OS zal uberhaupt niks merken van HT.

Wel zijn er enkele optimalizaties die je compiler en je OS kunnen toepassen om wat meer performance winst te krijgen. Deze hebben vooral te maken met de gedeelde resources die de staat van de hele processor of core beïnvloeden zoals caches en enkele instructies.
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 1, Hoofdstuk 2.2.5)
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 3B, Hoofdstuk 7)
Voor geïntereseerden: Er zijn van deze boeken ook digtitale kopieën beschikbaar op http://www.intel.com/products/processor/manuals/

[Reactie gewijzigd door jmzeeman op 18 mei 2009 10:06]

AMD processoren ook hoor.
Wel grappig dat microsoft zijn eigen besturingssysteem vista nu ook al begint af te vallen.. Windows 7 is best een mooi systeem , alleen er is nog het nodige aan compatibiliteit en werkzaamheid te doen imo. voornamelijk in het geluid en videogedeelte. Hyperthreading ondersteuning was in vista ook al voorhanden en werkt sinds sp1 best wel goed. Ik gok dat ze van het hypervisor idee afgestapt zijn en dit native ondersteunen nu (drivers en OS). voor uitleg zie hier boven.

edit:
toch maar beetje blaat erbij..
hyperthreading deelt de reken-unit van de processor in twee zodat deze gelijktijdig aan 2 verschillende dingen kan werken (let wel dit is dus op halve kracht) . de reken-units krijgen van de hypervisor taken toegedeeld. deze worden gestuurd vanuit de pipeline voor instructies in de processor. in sommige gevallen kan deze hypervisor besluiten dat hij een stukje code wat verderop in de pipeline staat alvast gaat berekenen. dit resulteerd uiteindelijk in een minimale snelheidswinst van enkele procenten tot 30 a 40% max.
hier onder ergens stond een weggemod stukje over een muur bouwen. dit is precies de essentie van hyperthreading en het zou niet weggemod moeten worden imo.

[Reactie gewijzigd door JoJo_nl op 18 mei 2009 09:00]

Marketing les 1 :P kijk wat mensen vinden van je vorige product...

Zeg dat je het met je nieuwe product alles hebt verbeterd en dat het oude product inderdaad een slecht product was. Dit om ervoor te zorgen dat de personen die nu twijfelen nog even wachten op de nieuwe versie waar hoogst waarschijnlijk weer een hogere marge op zit
Dat is bij de P4 (en misschien ook de Atom) het geval, maar bij de Core i7 en i5 is hyperthreading wat beter en anders uitgewerkt en zijn er daadwerkelijk meer erwerkingseenheden beschikbaar, waardoor je een core met hyperthreading nu meer kunt zien als 1,5 core dan 1,07 core. Maar het zou natuurlijk ook best leuk zijn om eens een oude P4 HT erbij te pakken en te kijken of die implementatie van hyperthreading ook baat heeft bij de optimalisaties in Windows 7.
Er is geen i7 versie zonder hyperthreading om mee te vergelijken... Wie zegt dat die prestatiewinst door de hyperthreading komt en niet door andere optimalisaties (de geïntegreerde geheugencontroller om maar eens wat te noemen....)

Tuurlijk is de i7 veel sneller, maar of dat veel met Hyperthreading te maken heeft? (ja 5 tot 10% gok ik). Hyperthreading is gewoon een van de vele optimalisaties die samen een snellere processor maken.

Het is geen sommetje van '2 cores en ook nog met hyperthreading dus 4x zo snel' zoals veel mensen soms denken. Beetje dezelfde onzin als de MHz mythe; ('2x zoveel MHz is 2x zo snel'). Er bestaat geen '1.5 core', het is gewoon een snellere core.
Je kan hyperthreading toch uitschakelen?
De winst met Hyper-Threading is relatief hoog voor Core i7, zo'n 20-40 % naar mijn (uitgebreide) ervaring.
Nee, het is niet alleen maar een snellere core. In zekere zin bestaat er wel degelijk 1,5 core. Immers, onder bepaalde omstandigheden kan hyperthreading inderdaad twee dingen tegelijk doen. Onder andere omstandigheden niet. Gemiddeld is het dus wel degelijk meer dan 1 core, en minder dan 2 cores.

En dat is niet hetzelfde als gewoon een snellere core. Immers, HT werkt alleen maar in een situatie met twee actieve threads.
niet helemaal, je kan 2 verschillende taken tegelijk uitvoeren, zolang ze maar niet hetzelfde deel van de cpu nodig hebben.
En als ze dat wel hebben, dan maakt het toch nog niks uit.
Ik heb een Atom330 op ITX, en hier staat:
Atom-processor wel een enkele core heeft,
Maar ik heb toch echt 2 Cores met HT, dus fysiek 4,
want MS Windows TaskManager liegt niet!
Hoe kan dat dan?
Om even in metaforen te spreken: als je in je eentje 100 uur doet om een muurtje te metselen, kan je met 100 personen in een uur hetzelfde muurtje metselen? :? :P
Zoals AHBdV hierboven al aangeeft. Hyperthreading maakt gebruik van het feit dat een processor voor het uitvoeren van verschillende typen instructies verschillende "executie eenheden" gebruikt. Bijvoorbeeld voor het berekenen van een vermenigvuldiging gebruikt het een andere "executie eenheid" dan voor het uitvoeren van een geheugen copieer aktie. Die twee instructies kun je dus tegelijkertijd uitvoeren. En dat is het doel van hyperthreading. Daavoor heeft een hyperthreading processor wel twee (of meer) pijplijnen per "core" nodig uiteraard.
Wat microsoft in haar code bijvoorbeeld kan doen, is proberen in hun compiler de gegenereerde code zoveel mogelijk te laten wisselen van type instructie dus type executie eenheid die het nodig heeft. Voor stukken code waarvan de volgorde niet kritisch is, kun je wat husselen bijvoorbeeld. Dat geeft de processor meer mogelijkheden om instructies uit meerdere threads tegelijk uit te voeren.
Dat zou kunnen, echter is het wel van belang dat in dit geval niet dezelfde registers worden aangesproken. Voor zover mijn x86 instructieset kennis nog op pijl is werkt de MUL (multiply, vermenigvuldigen) instructie als volgt:

De waarden van register A worden met register B vermenigvuldigd. Vervolgens wordt de uitkomst in register A geplaatst. Als je dan de instructie "MOV AX, CX" uit zou voeren dan heb je een probleem. Deze instructie kopieert de data van register C (CX) naar A (AX).

Je voelt hem al aankomen, je weet niet welke data je in je register hebt: De uitkomst van de MUL instructie, of juist de data uit register CX.
Klopt, de P4 had al extra copieeen van registers om die reden. Want een register is heel klein t.o.v. van de ALU. Die extra registers zag je als programmeur dus niet, maar waaren specifiek per pijplijn. Er was indertijd een leuk stukje op Internet van een AMD ingenieur daarover. AMD is de uitvinder van Hyperthreading.
Met hyperthreading kunnen wel degelijk meerdere threads tegelijkertijd worden afgehandeld mits de processor op een gegeven tijdstip de benodigde execution units in de processor nog vrij zijn.
De zoveelste keer dat Microsoft zonder schaamte zegt dat Windows 7 beter is dan Vista, of anders gezegd dat Vista gewoon niet een volwaardig OS genoemd zou mogen worden. Dit is de zoveelste keer dat ik dit ergens lees, in allerlei vormen, waarmee het voor mij steeds duidelijker wordt dat Vista gebruikers gratis zouden mogen overstappen op Windows 7. En nee, ik zeg dat niet uit eigen belang want ik draai nog steeds XP. Maar als de maker van een OS al door laat schemeren dat Vista niet het OS is wat het had moeten zijn, dan zouden ze in mijn ogen ook niet twee keer de licentiekosten mogen vangen.

Microsoft zou eens hand in eigen boezem moeten steken, en er gewoon voor uit moeten komen dat ook zij Vista als tussenos beschouwen. Vista gebruikers gratis, of in ieder geval met fikse korting, over laten stappen en XP-gebruikers over de streep trekken om naar Windows 7 te gaan. Iedereen blij, en de slechte naam die Microsoft gekregen heeft door Vista is voor een groot gedeelte weer rechtgetrokken. Hierdoor zal het beeld van arrogantie van Microsoft verminderen, en waardeer je de gebruikers die toch Vista zijn gebruiken.
Hij noemde de kwaliteit van het nieuwe besturingssysteem als reden om over te stappen.
Dit zegt genoeg. En dit is niet de eerste keer dat werknemers van Microsoft zulke uitspraken doen. Vista was, vooral zonder het SP, gewoon slecht. Ze hebben een slecht product gekocht en daarvoor moet de klant, bedrijf of particulier, gecompenseerd worden.
Veghte liet weten dat Microsoft er alles aan doet om te voorkomen dat Windows 7 bij de introductie dezelfde compatibiliteitsproblemen vertoont als bij de lancering van Windows Vista.
Die problemen waren er toch niet? Of was Microsoft zo onzeker geworden dat ze dit nu pas durven toe te geven, omdat Windows 7 gewoon een erg goed OS is geworden? Net zoals met de Xbox wordt de klant voor de gek gehouden door Microsoft die zijn kop in het zand steekt, en niet de klant maar het marktaandeel en dus de aandeelhouder tevreden wil houden. Het wordt tijd dat dit weer omgedraaid gaat worden, en dat de klant weer als volwaardig consument gezien gaat worden.
Microsoft heeft nauw samengewerkt met Intel om Windows 7 betere ondersteuning voor hyperthreading te geven dan voorgaande besturingssystemen.
Dit vind ik dubieus. Een OS-maker hoort niet met één bedrijf/fabrikant rond de tafel te gaan zitten. Ze zouden met alle fabrikanten, en dus met alle technologieën, om de tafel moeten om zo onafhankelijk en onpartijdig een OS te ontwikkelen. We zagen het al met Vista dat Microsoft voor één fabrikant haar systeemeisen verlaagde, terwijl dit onder water helemaal niet van toepassing was omdat er helemaal geen aanpassingen aan het OS gedaan werden. Dit is niet in goede aarde gevallen, maar blijkbaar heeft Microsoft nog steeds niet geleerd van haar fouten. Wat maakt het ook uit, als de aandeelhouders maar tevreden en glimlachend naar huis toe gaan :)
Windows XP was in principe een hele grote verandering ten opzichten van al zijn voorgangers.
Vista kon dat nooit overtreffen en heeft alleen op het gebied van beveiliging een meerwaarde ten opzichten van XP.
Windows 7 zal dat ook nooit overtreffen aangezien er niet echt nieuwe futures aan toe zijn gevoegd die het succes van Windows XP kunnen overtreffen.
Alles werkt sneller en ziet er gelikt uit, maar dat is niet alleen aan Windows te danken, de hardware heeft de laatste 8 jaar ook een grote vlucht gemaakt waarop Windows verder bouwt.
Nu hebben ze dan HT geperfectioneerd maar dat was een future die in Windows XP al was gepresenteerd.

de suggestie van Veghte "Als je net begonnen bent met het testen van Vista zou ik overstappen op de Windows 7 Release Candidate en daarmee verder gaan"

Is gericht op netwerk architecten die bezig zijn met Vista in een test omgeving beter Windows 7 kunnen gaan testen, de reden hiervoor is natuurlijk dat Windows 7 veel beter uit die test gaan komen, en dat de RTM versie deze keer niet vertraagd zal worden.

Een doorsnee consument hoeft zijn OS niet te testen, aangezien de dingen die hij ermee wil doen gewoon zullen werken, de meeste mensen zijn dan ook in de verkooppraatjes getrapt die ze te horen krijgen bij paradiget of mediamarkt.
Alles werkt sneller en ziet er gelikt uit, maar dat is niet alleen aan Windows te danken, de hardware heeft de laatste 8 jaar ook een grote vlucht gemaakt waarop Windows verder bouwt.
Niet mee eens, mijn netbook werkt een stuk lekkerder met Win7 dan met XP erop, batterijduur is ook nog eens verbeterd (niet zozeer de max accuduur, maar de voorspelling klopt beter). En opstarttijd van netbook was (veel) korter dan die van Vista op mn vaste pc (65 vs 110 secs)
Een doorsnee consument hoeft zijn OS niet te testen, aangezien de dingen die hij ermee wil doen gewoon zullen werken, de meeste mensen zijn dan ook in de verkooppraatjes getrapt die ze te horen krijgen bij paradiget of mediamarkt.
Daar heb je gelijk in, maar de doorsnee consument zal vast wel van zn tweaker vrienden gehoord hebben dat Win7 erg fijn werkt en dat ze beter daar op wachten :)

[Reactie gewijzigd door BdK9001 op 17 mei 2009 21:23]

Het enige dat Microsoft zegt is dat Windows 7 een beter OS wordt dan Windows Vista. Dat zeggen ze bij elke nieuwe versie.

Het grote imagoprobleem van Vista komt gewoon door een hele hoop elkaar napratende mensen. Natuurlijk zijn er echte problemen met Vista - niet alle ontwerpkeuzes zijn even gelukkig uitgepakt, maar op de geschikte hardware is het een veel beter OS dan XP is, qua gebruikerservaring, stabiliteit, veiligheid en zelfs compatibiliteit. Op geschikte hardware is er ook geen snelheidsverschil.

Windows 7 is alleen nog beter dan Vista. Ik gebruik nu een nog pre-RC, en ik moet zeggen dat dit wel eens het beste OS kan zijn dat Microsoft ooit uit gaat brengen. Het is gewoon zo goed, en dat is ook het enige wat ik uit deze tekst kan halen dat er gezegd wordt.
Hypterthreading is wat mij betreft de Windows Millennium of Vista van Intel.

Met alle multicore CPU's zie ik er het nut niet meer van in. Het was/is een grote Hype, ik trap er niet meer in.

of zoals de Amerikanen het zeggen: "There is no substitute for cubic inches"
Niet mee eens, HTT wordt over het algemeen juist onderschat. In benchmarks komt de snelheidswinst vaak inderdaad niet zo naar voren en het is ook niet zo dat één enkele app er opeens veel sneller van wordt. Maar als je kijkt naar hoe een systeem aanvoelt, de daadwerkelijke praktijkervaring dus, dan heeft HTT wel degelijk een voordeel. Het is een soort semi echte multicore en je merkt gewoon dat een systeem minder snel hangt op één proces/programma, alles werkt vloeiender. Draai bijvoorbeeld maar eens één instance van Prime 95 op een gewone single core machine en dan op een HTT single core machine, op de HTT kun je nog redelijk werken terwijl de gewon single core veelal onwerkbaar wordt. Misschien heb je gelijk dat HTT in het multicore tijdperk onnodig/achterhaald is, maar in het single core tijdperk had het IMO zeker meerwaarde.
Je zou beter eens opzoeken wat Hypertreading inhoud, ipv het af te schilderen als zinloos.
HT zorgt er voor dat je cubic inches in nog meer gevallen 100% benut kunnen worden. Als de mogelijkheid er is worden er 2 instructies tegelijk uitgevoerd waar er anders maar 1 werd uitgevoerd.
Wat ik me dan afvraag, gezien de "nauwe" samenwerking van MS tussen de 10.000 hard/software bedrijven, waarom bieden al die bedrijven dan geen hard/software updates aan via Windows :? Is het dan zo moeilijk omdat via Windows update te laten lopen ?

Daarmee vind ik Vista/Win7 dus helemaal niet zo innovatief omdat men geen verbetering op dit soort vlakken aanbrengt binnen hun OS die juist kan bijdragen tot een beter product. Nee, inplaats daarvan veranderen we het "schilletje" van paint en teksdocument.

Gemiste kansen dus imho en Win7 brengt weinig toegevoegde waarde in daadwerkelijke veranderingen tov. XP/Vista en daarmee laat Ballmer zien dat hij niet vooruitstrevend is en MS op de lange termijn zelf steeds meer buitenspel zet.

En gebruikers kunnen dan wel weer aanhalen dat de kernel zoveel beter is maar ook wat betreft de veiligheid is Windows nog steeds een achter de feiten aanlopend product. Verder is DirectX steeds onbelangrijker aan het worden, met name voor gamen, temeer omdat MS de gamemarkt voor de PC stees zelf meer ondergraafd met hun console.
Microsoft Update doet alleen de updates die via Microsoft komen, waar Microsoft dus een kwaliteitscontrole op kan doen. Het is voor MS niet haalbaar om alle software en drivers te gaan testen, dus dan zouden ze ongetest spul op MU moeten gooien om vervolgens klachten van klanten te krijgen dat de computer niet meer werkt (gebeurt al vaak genoeg). Het is de verantwoording van de fabrikant van het softwarepakket/hardware om ervoor te zorgen dat hun spul geupdate wordt.
Even op je reply, de meeste software werd/word al door MS gecontroleerd en daar betalen 3rd party partijen miljoenen voor om het WHQL certificaat te krijgen. Wel of niet getest, of ik ze nu van de soft/hardware fabrikant zijn site zelf haal doet daar weinig aan onder, MS kan het eens een keer als service gaan aanbieden.

Kijken we even verder dan zien we met name de laatste jaren dat met name OEM bakkers zelf drivers schrijven omdat dit velen malen goedkoper is en in eigen huis word getest. Veelal zie je ook steeds meer eigen software meegeleverd worden om de gebruiksvriendelijkheid te verhogen.

Verder heeft MS zelf de plannen om algehele systemen te gaan aanbieden, zoals Apple dat nu doet om juist van onstabiele systemen af te komen, zoals ze dat zelf nu al een deel doen met hun Xbox concept, eigen hard/software. Als ze dan nu toch zo willen veranderen waarom dan niet gelijk dat meegepakt in Win7 :?

Maar we gaan het zien. Ik zie in de toekomst een grote markt weggelegd voor merken die dat wel gaan toepassen en dat zal tevens de laatste kans zijn voor Linux OS'en om eens de consumentenmarkt te gaan betreden. Één ding blijft daarin wel belangrijk, wat we nu maar al te vaak missen is dat er kontinu drivers verbeterd worden na uitlevering. Met name in de laptop markt doet men, als je mazzel hebt nog eenmaal een update en dan mag je het daarmee doen.

Maar het ging mij met name om de soft/hardware in één keer up te daten op een periodiek moment want het is vrij ouderwets om alle sites voor al je soft/hardware af te blijven struinen voor nieuwe/betere drivers. En gezien dat MS dat nu dus niet ingebakken heeft vind ik dat een teleurstellende gemiste kans want ze zijn alleen maar gefocussed op de looks en kijken teveel naar anderen om zo hun eigen software te "verbeteren". Visieloos dus en ik vraag me af of onder Ballmer dit nog eens gaat veranderen want hij miept wel als een ADHD'er op het podium over zijn eigen producten maar daar kan ik niet echt voor vallen ;)

@ PolarBear :

Wat komt er nou daadwerkelijk aan updates binnen, noem er eens een paar behalve een Nvidia driver of een specifiek laptop driverstje voor hardware. VOor desktop systemen is het nog bar en boos, praten we maar niet over BIOS updates, even in vergelijking met Apple die dat wel zo aanbied. Apple update, één knop, alles binnen, scheelt een hoop tijd ;)
Hoe zit dat dan met de WHQL drivers? Die zijn toch wel door Microsoft getest en bevestigd goed te werken met Windows? Kortom; drivers die door WHQL zijn gehaald kunnen wat mij betreft best via Windows Update binnenkomen als optionele update.
Bij mij komen ook nieuwe drivers binnen via Windows update :?
Klopt, er worden ook regelmatig drivers van derde partijen (hardwareleveranciers) verspreid via Windows Update.

Wel moeten de drivers aan specifieke eisen voldoen om hiervoor in aanmerking te komen. Deze eisen worden beschreven op deze Microsoft-site.
Ik zie weer een nieuwe EU rechtzaak tegen Microsoft omdat ze Intel weer een extra voordeel geven. "Koop een Intel i7 met Windows 7 voor maximale optimalisatie". Ik snap best dat de 2 bedrijven al jaren deals hebben maar hou in ieder geval de schijn op door ook te optimalisatie te doen met AMD cpu's.
toch niet een nieuwe WIntel periode toch... nu maar hopen dat een nieuwe phenom uitkomt met hyperthreading. ja ik ben een beetje fanboy, maar iedereen snapt toch dat na alle illegale en "minder legale" praktijken van Intel en Microsoft het een keer fout gaat. als ze samenwerken zijn ze gewoon te sterk en ik adviseer Microsoft dan ook ook samen te werken met AMD. als ze dat doen benadelen ze tenminste niet 1 partij.
maar iedereen snapt toch dat na alle illegale en "minder legale" praktijken van Intel en Microsoft het een keer fout gaat.
Kom op zeg, dit is wel een beetje overdreven.
Intel is de enige met hyperthreading, AMD heeft gewoon volledige cores en daardoor is dit probleem helemaal niet van toepassing.

Het probleem in een notedop:
Elke multi-core CPU met Hyperthreading heeft N volledige cores en N hyperthreading-cores. In principe weet je OS (tot nu toe dus) niet het verschil tussen die cores. Voor je OS zijn er -met HT aan- dus 2N cores beschikbaar.
Wanneer je 2 processen draait (bijvoorbeeld 2 verschillende applicaties), die elk een core volledig bezig kunnen houden, dan is er dus een performance-verschil tussen wanneer je beide processen feitelijk op dezelfde core en bijbehorende HT-core gaat draaien en wanneer je op 2 verschillende cores gaat draaien.
Op de een of andere manier zal de proces-scheduler van je OS dus moeten weten welke combinatie sneller is en de processen dus slimmer moeten verdelen. Het liefst ook dat die affiniteit voor bepaalde cores ook niet zomaar veranderd tijdens het uitvoeren.
Helemaal mooi zou zijn, wanneer je OS ook nog kan bepalen welke instructies parallel uitgevoerd kunnen worden op een HT-core, zonder de performance van de rest van die core nadelig te beïnvloeden, maar ik gok dat dat pas kan als de gebruikte compiler daar ook aan meewerkt.

Hierboven benoem ik vrij duidelijk een verschil tussen HT-core en een "gewone" core, maar strikt genomen is er niet zo'n groot verschil. In principe zijn beide gelijk, maar beïnvloeden ze elkaar wel op een dergelijke manier.
Intel is de enige met hyperthreading, AMD heeft gewoon volledige cores en daardoor is dit probleem helemaal niet van toepassing.
Intel heeft gewoon volledige cores en hyperthreading.
Onzin. NVidia zat vanaf het begin af aan in de DX9 ontwikkeling. Echter, NVidia wilde z'n eigen proprietaire shader systeem er door drukken, i.p.v. met ATI en MS samen te werken.

Verder hadden ATI en MS gewoon meer visie en inzicht. Zij hadden begrepen dat PS2.0 een enorme revolutie te weeg zou brengen in de manier waarop spellen geprogrammeerd werden. En dat het daarom belangrijk was dat de eerste generatie hardware ook daadwerkelijk goed met de nieuwe technologie kon omgaan.

NVidia had die visie niet, en dacht dat het wel net zo als met de oudere integer shaders zou gaan, waarbij het een check-box feature was, maar (in eerste instantie) nauwelijks door spellen gebruikt zou worden.

Het resultaat was dat ATI een GPU uitbracht die vol op DX9 met PS2.0 geoptimaliseerd was, en NVidia een GPU die weliswaar DX9 compatible was, maar in de praktijk voor DX8 geoptimaliseerd was.

Was gewoon een grote inschattingsfout van NVidia's dat ze daar de boot misten. Eigen schuld, dikke buld.
Heeft AMD hyperthreading?
Hyperthreading is helemaal niet nodig.
Wat belangrijker is, heeft W7 nu eindelijk een fatsoenlijke Multi-Threading.
Want MT is belangrijk, of je nu HT hebt of niet.

Als Windows nog altijd niet goed met MT om kan gaan, Vista al zeker nog altijd niet, dan heeft HT of multiple-core weinig effect op het geheel.
Windows schaalt namelijk nog altijd enorm slecht! Vista kan je makkelijk doen vastlopen met 1 thread, belachelijk voor een modern OS.
Windows NT deed al aan multithreading. Zie dit artikel op MSDN (kijk ook even naar de datum).

Verder heeft vastlopen niet met schalen te maken.
Microsoft zecht alleen dat de Intel I5/i7 procsesoren door middel van HT technologie beter presteerd dan in Vista omdat MS samen gewerkt heeft met intel hiervoor.
Die rechtzaak slaat op het gelobby van iNtel om AMD bij OEM Hardware firma's overal buiten de deur te houden.
De rechtzaak is niet tegen innovatie of hardware support.
Maar ze mogen AMD support niet blokkeren met rare deals.
Dit ook alleen omdat iNtel in een monopool positie komt.
Ook voor Apple is Hyperthreading een issue. Vooral audio programma's (lees Cubase 5 , Logic) hebben hier last van. De Nehalem processor heeft mij in ieder geval doen besluiten om even geen nieuwe computer aan te schaffen en te wachten wat de leveranciers van de DAW programma's gaan vermelden over de performance. Ik zou graag zien dat Intel stopt met elke keer dezelfde fout maken betreffende deze hyperthreading, die keer op keer meer problemen oplevert dan de snelheids winst die hier tegenover staat.

Windows Vista was in ieder geval voor mij de reden om over te stappen op OSX. Ik ben wel benieuwd naar Windows 7, maar ik zal eerst bewezen moeten zien dat dit de oplossing gaat bieden.

Eigenlijk is maar een ding voor mij belangrijk en dat is de goede audio performance van het OS. En ik wil niet het halve OS moeten uitschakelen (Lees Aero, etc) om dit te bereiken.

[Reactie gewijzigd door bruij025 op 18 mei 2009 09:12]

Kun je wat specifieker zijn betreffende de problemen met Cubase 5 en Logic? Bied OSX wel ondersteuning voor hypertrading?


Ik draai zelf een pc met Nehalem met Cubase 4/5 en een Firewire audio interface in Windows Vista 64 SP1. En inderdaad de performance is niet bijster slecht, maar met een simpel project met 16 audio/VST sporen en wat plugins gaat de VST performance direct richting de 33%, met een input latency van 3.6 en output van 5.5 ms.

In Windows 7 ben ik nog aan het testen..
OSX Leopard heeft nog geen goede hypertheading ondersteuning. Snow Leopard zal dit waarschijnlijk wel hebben, maar hierbij veranderd het driver model naar 64 bits, wat vooral voor audio drivers een update zal nodig hebben. Steinberg (Cubase) raadt op dit moment Hyperthreading af. Je zal deze technologie dus waarschijnlijk op zowel Apple als Windows (PC) moeten uitschakelen.
Wel vreemd dat MS nu zelfs gaat zeggen "neem geen Vista!!" je zegt in mijn ogen dan dat je een slecht product op de markt hebt gebracht.
wel natuurlijk een teken dat de release erg dichtbij komt en zeker dit jaar zal zijn!
(ik zit er in ieder geval op te wachten :) )
Wel vreemd dat MS nu zelfs gaat zeggen "neem geen Vista!!" je zegt in mijn ogen dan dat je een slecht product op de markt hebt gebracht.
Nee, om twee redenen niet. Ten eerste is Vista zeker niet slecht, het is een prima OS.

Ten tweede is het logisch dat men aanraad om naar Win7 te gaan. Waarom zou je nu nog naar een 3 jaar oud OS overstappen, hoe goed dat OS dan ook is? Lijkt me marketing-technisch vrij logisch dat je naar Win7 over stapt, zeker als je bedenkt dat het compleet backwards-compatible is.
Als ze nu nog zouden adviseren om op Vista over te gaan klinkt het alsof er weinig verbetering is.
Iedere fabrikant probeert zijn producten continu te verbeteren als het goed is toch?
Dat zegt Microsoft helemaal niet. Alleen dat Hyperthreading beter is en dat de kwaliteit verder beter is. Als iets beter is wil niet zeggen dat het voorgaande slecht is. Dat kan ook erg goed zijn. En dat is het ook. Vista is een erg goed product. Ik vind juist XP een enorm slecht product. Ik kan voor iedere versie van windows wel een lijstje maken met dingen die zuigen (Ook windows 7) en de lijst is het langst bij XP.
Fijt is wel dat Vista wat acceptatie betereft niet gelukt is, en Microsoft het met de introductie van Windows 7 feitenlijk de nek om draait. Daarmee is Vista, net als ME een van de kortst levende versies van Windows. Ben het wel met je eens, Vista is een best goed systeem, maar bood blijkbaar te weinig meerwaarde.
Ik ken enkele bedrijven die nu begonnen waren met overstappen naar Vista en daarmee vanwege Windows 7 gestopt zijn. De meerderheid draait nog XP.
Ik ben het wel met je eens dat XP niet meer mee kan, het is gewoon een zwaar verouderde oldtimer geworden.
Ook grappig dat voor veel mensen het gevoel al zegt dat het volgende OS na WIN7 weer flopt. En daarna weer een top OS.
Begrijp je me? ;)
Ok ok, wij weten misschien beter, maar als de geschiedenis zich herhaalt dan gaan we aardig deze kant op.
Win7 is naar voren geschoven omdat Vista zo'n prestege en imago deuk voor MS heeft gegeven.
Die prille eerste ervaring met het verse Vista. Wegen nu nog steed erg mee bij de massa. Zij vinden Vista slecht.
Dat het een moment opname is beseffen vele blijkbaar niet. Vista is dus als zodanig getaged. Forever. Bij de massa.
Ook al is het met SP1 en verder en ook de Driver support in de markt goed op dreef.
Vista zorgt nu voor veel minder problemen.

Omdat budged nu een stuk krachtiger is en geheugen goedkoop. Worden nieuwe PC en notebooks wel met voldoende geheugen geleverd.

De problemen die in het begin opsteken krijgen huidige overstappers aanzienlijk minder.

Tenzij je Vista op een Netbook wilt pleuren dat is kwa spects net wat te zwak.
uit mijn ervaring blijken veel mensen thuis en op het werk dezelfde software te willen (gebruiksgemak), van enkele weet ik zo dat ze onlangs een nieuwe pc met XP licentie hebben gekocht omdat we op het werk nog met XP draaien
dit werkt ook omgekeerd, bedrijven blijven graag zo lang mogelijk bij een vertrouwd systeem, minder kosten qua (om)scholing
XP is extreem lang op de markt geweest en is daardoor enorm ingeburgerd
Wel vreemd dat MS nu zelfs gaat zeggen "neem geen Vista!!" je zegt in mijn ogen dan dat je een slecht product op de markt hebt gebracht.
Dat is jouw gekleurde conclusie.
Iemand aanraden naar een nieuwere versie te gaan wil niet zeggen dat het oude product slecht is. Het kan ook zeggen dat het nieuwe product _beter_ is en nieuwe of betere features bevat.

Een voorbeeld: zou iemand er nu over denken een ipod te kopen, dan zou je momenteel kunnen zeggen wacht op de nieuwe ipod die er binnenkort aan komt. Wil dat dan zeggen dat de oude ipod slecht is?
hyperthreading mm, dan heb ik er met mijn pentium4 vast ook profijt van. :)
Dat klopt als je minimaal de Northwood-core hebt (Willamette-P4's hebben geen hyperthreading).

Wel is de hyperthreading die in de Core i5/i7 en hoger zit een stuk geavanceerder, dus met een P4 zal je er denk ik wel minder profijt van hebben.
Core 2 Duo's hebben geen hyperthreading en zullen dus ook geen profijt hebben van deze feature in Windows 7. Alleen de Pentium 4 Northwood and later en de Core i5/i7 (met uitzondering van de goedkoopste i5 geloof ik) hebben hyperthreading.
waarschijnlijk wel hoor, eigenlijk zegt MS hier gewoon dat ze meer hebben geoptimaliseerd voor multi-threading
specifiek optimaliseren voor hyper-threading is onzin, want dan zou je moeten rekening houden met het feit welke taken je kan afsplitsen door te weten welke taken zo'n cpu naast elkaar kan uitvoeren
feit is dat "gewoon" multi-threading al zeer moeilijk is, maar dit hebben ze wel degelijk beter gemaakt waardoor hyperthreading er automatisch ook winst van heeft
toevallig valt de launch van de i5 samen met Windows7 en dat gaat intel dus als verkoopsargument gebruiken
als je ziet dat de beste i7 eigenlijk niet zo super veel sneller is dan de beste C2Q, dan weet je dat de i5 reeks gaat teleurstellen, maar het ding moet uiteraard wel verkopen
specifiek optimaliseren voor hyper-threading is onzin, want dan zou je moeten rekening houden met het feit welke taken je kan afsplitsen door te weten welke taken zo'n cpu naast elkaar kan uitvoeren
Toch is het net dat wat ze doen, als ik het goed begrijp. Wie weet doen ze zelfs aan een soort analyse van een executable en bepalen ze aan de hand van de soorten instructie's of ze die thread of dat proces moeten schedulen op een aparte core dan wel op een virtuele core van een al redelijk belaste fysieke core.
als je ziet dat de beste i7 eigenlijk niet zo super veel sneller is dan de beste C2Q
Da's ook wel een redelijk boude uitspraak. Voor rekenintensieve taken (3D rendering en video encoding bvb.) is de Core i7 een stuk sneller dan de Core 2 Quad's ... (link)
je zegt het zelf al: rekenintensieve taken, de i5 is niet voor de high end en gaat dus een stuk trager zijn dan de i7 (wie zou anders nog een i7 kopen)

aangezien de meeste programma's nog niet eens geoptimaliseerd zijn voor multi-threading, vind ik het een boude uitspraak dat jij denkt dat ze specifiek gaan optimaliseren voor hyper-threading
de meeste Windows onderdelen zijn totaal niet rekenintensief en dus de moeite niet om extreem te optimaliseren
het opstarten hebben ze wel aangepakt, maar of ze in dat toch wel zeer belangrijke proces een onderscheid maken tussen hyper- en multi-threaden kan ik nauwelijks geloven: bij een redelijke quad core is de cpu totaal niet de vertragende factor
aangezien de meeste programma's nog niet eens geoptimaliseerd zijn voor multi-threading, vind ik het een boude uitspraak dat jij denkt dat ze specifiek gaan optimaliseren voor hyper-threading

het opstarten hebben ze wel aangepakt, maar of ze in dat toch wel zeer belangrijke proces een onderscheid maken tussen hyper- en multi-threaden kan ik nauwelijks geloven: bij een redelijke quad core is de cpu totaal niet de vertragende factor
Het grote verschil tussen multithreading over verschillende cores en hyperthreading (meerdere draadjes op 1 core) is toch dat als je 2 intensieve draadjes op 1 core krijgt terwijl de andere cores uit hun neus lopen te eten wegens verkeerde verdeling, je totale prestatie van het systeem zwaar onder de maat is. Het OS zal dus weldegelijk moeten kijken naar welke extra draadjes op welke fictieve cores kunnen draaien voor het meest optimale resultaat.
Het doet er dan ook weinig toe of je een i5 hebt of een i7, want zolang de hyperthread draadjes verkeert verwerkt worden, zul je op geen van beide processors een fatsoenlijke prestatie krijgen.

Het leek me dat Fietsventje dit aardig duidelijk heeft uitgelegd.
de meeste Windows onderdelen zijn totaal niet rekenintensief en dus de moeite niet om extreem te optimaliseren
't Gaat dan ook niet over de performantie van Windows zelf. Een OS op zich is maar héél zelfden CPU-intensief. Het gaat wel degelijk over de manier waarop Windows de taken van de processen en hun threads verdeelt over de verschillende cores en hoe het tijd toebedeelt aan die processen.
Maar die P4's (Northwood, Prescott, etc...) missen dan weer VT (Virtualization Technique), dus draai dan maar geen pre-Win7 applicaties om ze in de XP-virtuele mode te laten versnellen. Daar verlies je dat speeltje weer. :/
Er zit geen hyperthreading in de Core of Core2 reeks CPU's, zei het Solo, Duo, of Quad.
Hij zegt ook Core i5/i7, want HT is herintroduceerd in de nieuwe processoren van Intel.
Natuurlijk vrij makkelijk om te zorgen dat Windows7 vrijwel perfect compatible is... Het is wat compatibiliteit betreft immers vrijwel gelijk aan Vista.

De stringente access rights die in Vista werden afgedwongen worden nu gewoon overgenomen. Idem wat betreft UAC e.d. Op dit vlak zal simpelweg gelden dat als het in Vista werkt, het ook in Windows7 werkt. Idem voor de hardware drivers. Dat heeft in Vista ook een grote verandering gehad, en Windows7 blijft op dat punt gewoon gelijk.
De compatibiliteit is wel omhoog gegaan door het toevoegen van de Windows XP Mode.
Wat gewoon een virtual PC is met een voorgeactiveerde Windows XP installatie. Kan je zelf ook doen mocht je nog een oude XP hebben liggen.
"Bill Veghte, senior vice-president bij Microsoft voor de ontwikkeling van Windows, kondigde afgelopen week bij Microsofts TechEd-conferentie in Los Angeles aan dat Microsoft en Intel nauw samengewerkt hebben om Windows 7 het meeste uit de hyperthreading-technologie te laten halen"

Hoezit dat dan met AMD, ik voorzie alweer een voortrekkersrol in het voordeel dus van Intel als ik het zo lees....wel jammer...

gr. John
Intel heeft altijd al een nauwe samenwerking gehad met Microsoft. Intel is trouwens sowieso altijd druk bezig met softwareontwikkeling, zie ook de compilers die ze maken. AMD doet dat niet.
Waarom zou het samenwerken met Intel betekenen dat MS niet met AMD samenwerkt?? :?

Dat is een gevolgtrekking die nergens op slaat. Vooral omdat AMD geen hyperthreading heeft, en er dus ook niet met AMD samengewerkt kan worden op dit ondereel.

Voor de rest werkt MS altijd met alle partners samen. Sterker, de 64bit versie van Windows zijn meer op AMD dan op Intel gebaseerd.

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