'Intel en Lucid werken aan Larrabee-schaling'
Intel werkt volgens geruchten samen met LucidLogix Technologies aan een nieuw project. De chipgigant zou de technologie van Lucid willen gebruiken om de prestaties van zijn Larrabee-processors te verbeteren.
Het Israëlische bedrijf LucidLogix Technologies zou met Intel samenwerken om zijn Hydra-technologie geschikt te maken voor Intels Larrabee-processor. De Hydra-hardware kan gebruikt worden om meerdere processors te laten samenwerken, waarbij de prestaties vrijwel lineair schalen . Intel zou deze technologie willen inzetten voor de hybride Larrabee-processor, die tientallen cores bevat en die de sterke kanten van x86-cpu's en gpu's moet combineren.
Het is nog onduidelijk hoe Intel de Hydra wil toepassen. Het lijkt niet erg waarschijnlijk dat de Larrabee, waarvan het ontwerp al zo goed als af is, wordt aangepast om de Lucid-technologie intern te gebruiken. Het is aannemelijker dat de chipgigant Hydra wil gebruiken om meerdere Larrabee-processors te laten samenwerken. Het is echter ook nog steeds mogelijk dat Intel de chip alleen maar wil gebruiken om AMD en Nvidia een hak te zetten. Er wordt al langer gespeculeerd dat de opvolger van het X58-moederbord dankzij een Hydra 100 Series-chip geen sli of Crossfire meer nodig heeft, omdat de Lucid-chip ook in staat is om twee of meer videokaarten te laten samenwerken.
Reacties (31)
wow.. is reverse hyperthreading dan eindelijk mogelijk 
Dat gaat zeker wat worden dan
Dat gaat zeker wat worden dan
iets zoals video parallelliseren is nog geen reverse hyperthreading. Natuurlijk ziet Het spel/directx 1 logische eenheid, maar het blijft gewoon een vorm van redundancy.
Hyperthreading of het omgekeerde ervan heeft er niks mee te maken. Reverse hyperthreading is een soort perpetuum mobile
Hyperthreading treed pas in werking als bepaalde onderdelen niet worden gebruikt door 1 thread waardoor een ander thread van die onderdelen gebruikt maakt. Reverse hyperthreading zou volgens jou 2x zo snel gaan, maar er is maar 1 processor!
summair:
Hyperthreading is geen magische truc die je processor 2x zo snel maakt. Het maakt de processor alleen efficienter met onderdelen die anders idle zouden zijn.
Dus het heeft er niks mee te maken.
Hyperthreading of het omgekeerde ervan heeft er niks mee te maken. Reverse hyperthreading is een soort perpetuum mobile
Hyperthreading treed pas in werking als bepaalde onderdelen niet worden gebruikt door 1 thread waardoor een ander thread van die onderdelen gebruikt maakt. Reverse hyperthreading zou volgens jou 2x zo snel gaan, maar er is maar 1 processor!
summair:
Hyperthreading is geen magische truc die je processor 2x zo snel maakt. Het maakt de processor alleen efficienter met onderdelen die anders idle zouden zijn.
Dus het heeft er niks mee te maken.
[Reactie gewijzigd door DLGandalf op donderdag 15 januari 2009 16:03]
Reverse hyperthreading is het gebruiken van 2 processors voor 1 hardware thread (vandaar reverse, aangezien hyperthreading juist 2 hardware threads op 1 processor liet lopen). Je moet hierbij vooral denken aan branches in de code. Omdat instruction pipelines meerdere clockcycles duren, weet je aan het begin van een conditionele branch nog niet of je nou wel of niet moet springen, omdat de resultaten waarvan je van afhankelijk bent nog niet bekend zijn. Nu "gokt" een processor (adhv in het verleden behaalde resultaten bij die specifieke branch) door gewoon alvast maar wat te gaan doen. Als dat achteraf goed blijkt dan is er snelheidswinst. Als het fout blijkt dan heeft ie werk voor niets zitten doen en moet ie overnieuw beginnen vanaf de branch (geen snelheidsverlies hier, deze tijd was je ook al kwijt geweest als je gewoon had gewacht op de resultaten).Reverse hyperthreading zou volgens jou 2x zo snel gaan, maar er is maar 1 processor!
Met "reverse hyperthreading" kun je in theorie een tweede core inzetten om de andere beslissing uit te voeren. Brancht de ene core niet, dan brancht de andere wel, en andersom. Als uiteindelijk de resultaten bekend zijn dan kan een van de twee cores stoppen met werken en weer wachten totdat de andere core weer tot een conditionele branch komt. Dit zorgt voor een aardige snelheidswinst omdat branch-mispredictions in feite tot het verleden behoren. Het is echter natuurlijk niet zo dat een enkele thread nu ineens 2x zo snel uitgevoerd gaat worden. De daadwerkelijke snelheidswinst zal voornamelijk aan de code zelf liggen.
Niet dat ik hiermee wil aangeven dat Lucid een dergelijke techniek biedt, hoor.
[Reactie gewijzigd door .oisyn op donderdag 15 januari 2009 16:33]
Reverse HyperThreading is gelijk hoe complete onzin. Het duurt tientallen klokcycli om resultaten tussen cores uit te wisselen, en het is dus onmogelijk om er iets mee te winnen op het niveau van instructies of branches.
Als je een single treaded app gebruikt op een okt core dan benut je dus theoretish maar maximaal 12,5% van de CPU. Dus op het eerste gezicht is reverse Hypertreading zeer intterresant.
Bij de huidge CPU worden registers niet gedeeld ze zijn niet met reverse hypertreading gemaakt. Je krijg nogal wat overhead dit kan een hoge drempel zijn, Maar denk eerder dat het grootste probleem is om kleine code blokken te herkennen die splitsbaar zijn. Of CISC inkomende code in multitreaded MicroOps decoden RISC.
De hele achter trein pipe line ALU en registers moeten daar op gericht zijn.
Cores zouden gekoppeld kunnen worden het binnen werk waarbij een core de load kan splitten naar een partner core. Voor nu zou Reverse hypertreading meer opgevangen kunnen worden door compiler. Die splitbare brokjes code automatisch in 2 tot 4 treads te delen.
Op hardware niveau zou dit ook kunnen maar dan zou je dus, een meer shared cores, die dichter aan mekaar verwoven zijn. Dus meer als een siamese tweeling of kwartet. Maar van buiten zie je twee of vier. Maar als de ene iets krijgt wat deel baar is zou die ook de andere core(s) kunnen mee gebruiken.
Dit houd in dat je nogal wat architekturische trucken moet toepassen.
En net als HT kan je een leuke winst halen maar regelmatig ook een performance hit. Want de overhead heb je en als het niet splitbaar is krijg je verlies ipv gelijk.
Dan de zin van dit. Tja als men nog steeds single treaden app maakt dan zijn de systeem eisen ook maar zo hoog als 'n enkele core kan leveren. Alleen in uitzonderlijke gevallen een oude app die wegens omstandighedem zeer relevant is voor de gebruiker, die toch verlegen zit voor meer performance, dan is dit mooi megenomen. Maar deze situatie zal uitzonderlijk zijn. Maar ja voor zo'n uitzonderlijke gevallen ga je geen duur R&D architektuur brouwen waar een fractie van de markt wat aan heeft.
Ik denk dat er wel wat uit reverse hyperthreading te halen valt. Maar niet elke software probleem zal makelijk splitbaar zijn. Zoals een brok code met voornamelijk branching. Maar dat zal ook ook op hardware niveau moeilijk splitbaar zijn. Ik denk dat alleen op klein code blokjes die wel deelbaar zijn en op zo'n laag niveau ook makkelijk herkenbaar zijn en dan over meerdere resources verdeel kunnen worden.
Valt wat relevante winst te behalen.
Ik denk dat de investering in zo'n techniek en de waarde er van en de vraag erna on rendable is om er veel effort in te stoppen.
Men kan Tread splitsen ook op compiler niveau doen, maar ook de ontwikelaars kunnen mutitreaden massaal om armen. En met de Multicore toekomst ontkom men er niet aan.
In mijn visie, die wie in de toekomst single treaded programmeerd heeft lage CPU eisen en daar waar één core met gemak aan voldoet. Als professioneel programmer is degelijke Mutitread kennis in de toekomst of nu al toch wel vereist.
Gezien AMD het lang geleden toch overwogen heeft. Maar ook om verschillende redenen. O.a. R&D gebrek het heeft laten vallen. iNtel meer vanwege andere reden er niet aan begonnen is.
Bij de huidge CPU worden registers niet gedeeld ze zijn niet met reverse hypertreading gemaakt. Je krijg nogal wat overhead dit kan een hoge drempel zijn, Maar denk eerder dat het grootste probleem is om kleine code blokken te herkennen die splitsbaar zijn. Of CISC inkomende code in multitreaded MicroOps decoden RISC.
De hele achter trein pipe line ALU en registers moeten daar op gericht zijn.
Cores zouden gekoppeld kunnen worden het binnen werk waarbij een core de load kan splitten naar een partner core. Voor nu zou Reverse hypertreading meer opgevangen kunnen worden door compiler. Die splitbare brokjes code automatisch in 2 tot 4 treads te delen.
Op hardware niveau zou dit ook kunnen maar dan zou je dus, een meer shared cores, die dichter aan mekaar verwoven zijn. Dus meer als een siamese tweeling of kwartet. Maar van buiten zie je twee of vier. Maar als de ene iets krijgt wat deel baar is zou die ook de andere core(s) kunnen mee gebruiken.
Dit houd in dat je nogal wat architekturische trucken moet toepassen.
En net als HT kan je een leuke winst halen maar regelmatig ook een performance hit. Want de overhead heb je en als het niet splitbaar is krijg je verlies ipv gelijk.
Dan de zin van dit. Tja als men nog steeds single treaden app maakt dan zijn de systeem eisen ook maar zo hoog als 'n enkele core kan leveren. Alleen in uitzonderlijke gevallen een oude app die wegens omstandighedem zeer relevant is voor de gebruiker, die toch verlegen zit voor meer performance, dan is dit mooi megenomen. Maar deze situatie zal uitzonderlijk zijn. Maar ja voor zo'n uitzonderlijke gevallen ga je geen duur R&D architektuur brouwen waar een fractie van de markt wat aan heeft.
Ik denk dat er wel wat uit reverse hyperthreading te halen valt. Maar niet elke software probleem zal makelijk splitbaar zijn. Zoals een brok code met voornamelijk branching. Maar dat zal ook ook op hardware niveau moeilijk splitbaar zijn. Ik denk dat alleen op klein code blokjes die wel deelbaar zijn en op zo'n laag niveau ook makkelijk herkenbaar zijn en dan over meerdere resources verdeel kunnen worden.
Valt wat relevante winst te behalen.
Ik denk dat de investering in zo'n techniek en de waarde er van en de vraag erna on rendable is om er veel effort in te stoppen.
Men kan Tread splitsen ook op compiler niveau doen, maar ook de ontwikelaars kunnen mutitreaden massaal om armen. En met de Multicore toekomst ontkom men er niet aan.
In mijn visie, die wie in de toekomst single treaded programmeerd heeft lage CPU eisen en daar waar één core met gemak aan voldoet. Als professioneel programmer is degelijke Mutitread kennis in de toekomst of nu al toch wel vereist.
Gezien AMD het lang geleden toch overwogen heeft. Maar ook om verschillende redenen. O.a. R&D gebrek het heeft laten vallen. iNtel meer vanwege andere reden er niet aan begonnen is.
toch als je een if statement hebt zou je beide uitkomsten kunnen berekenen
( je doet er nu o de gok 1) in principe is dat al revere hyperthreading ( heel basic maar toch)
( je doet er nu o de gok 1) in principe is dat al revere hyperthreading ( heel basic maar toch)
Interessante ontwikkeling, wellicht voor de nieuwe GMA?
Volgens mij is die Larrabee echt zwaar achterhaald wanneer die eindelijk uitkomt
Waar baseer je dat op? Hebben we tegen die tijd al iets met tientallen cores? Intel heeft ook niet echt een historie van achter de feiten aanlopen.
Intel was bezig met chips van 32, 64, en zelfs honderden cores meen ik.
Zie ook:
* nieuws: Intel laat Teraflops Research Chip met 80 cores zien
* nieuws: Intel bouwt prototype processor met tachtig cores
* nieuws: Intel wil 32 cores per processor in 2010
Zie ook:
* nieuws: Intel laat Teraflops Research Chip met 80 cores zien
* nieuws: Intel bouwt prototype processor met tachtig cores
* nieuws: Intel wil 32 cores per processor in 2010
[Reactie gewijzigd door bbr op donderdag 15 januari 2009 14:38]
Cores, vectoreenheden of ALUs? De termen worden vaak dooreen gebruikt maar in een vergelijkende context mogen ze niet door elkaar gehaald worden.
Zo benadrukt AMD nogal graag dat de Radeon 4870 maar liefst 800 'cores' heeft, terwijl het in feite 10 cores zijn met elk 16 vectoreenheden van 5 elementen. Een Core 2 Quad heeft ter vergelijking 4 cores met elk 2 vectoreenheden van 4 elementen (aan hoge kloksnelheid). Larrabee krijgt 16 tot 32 cores met 2 vectoreenheden van 16 elementen.
Zo benadrukt AMD nogal graag dat de Radeon 4870 maar liefst 800 'cores' heeft, terwijl het in feite 10 cores zijn met elk 16 vectoreenheden van 5 elementen. Een Core 2 Quad heeft ter vergelijking 4 cores met elk 2 vectoreenheden van 4 elementen (aan hoge kloksnelheid). Larrabee krijgt 16 tot 32 cores met 2 vectoreenheden van 16 elementen.
[Reactie gewijzigd door c0d1f1ed op donderdag 15 januari 2009 15:43]
Intels cores bevatten een aantal vectoreenheden, dit is in ieder geval wat ik geb opgepikt van de larabee architectuur.
Tja het is moelijk te zeggen of Larrabee en geweldige keuze zal worden om als gaming kaart te kopen in de toekomst. Het zal allemaal afgaan hangen van het succes van de drivers en prijs denk ik.
Het energie verbruik en de prestaties in de benchmarks enkele maanden geleden in games als fear iets wat tegen vielen vond ik. Alhoewel het een product is met veel potentieel en ik er vanuit ga dat er nog veel verbeterd is sincedien. Maar als intel dit een succes wil laten worden zullen ze programmeurs en game fabrikanten voor zich moeten winnen. en dat kost veel $$$ maar ja intel heeft genoeg $$$ om er iets van te kunnen maken
Maar de vraag is wat zal microsoft doen als intel probeert hun directx overbodig te maken. Ik verwacht niet dat Micro$ost zich zijn macht in de API markt laat afpakken.en Nvidia en AMD zullen even min hun terrein willen verliezen.
Het energie verbruik en de prestaties in de benchmarks enkele maanden geleden in games als fear iets wat tegen vielen vond ik. Alhoewel het een product is met veel potentieel en ik er vanuit ga dat er nog veel verbeterd is sincedien. Maar als intel dit een succes wil laten worden zullen ze programmeurs en game fabrikanten voor zich moeten winnen. en dat kost veel $$$ maar ja intel heeft genoeg $$$ om er iets van te kunnen maken
Maar de vraag is wat zal microsoft doen als intel probeert hun directx overbodig te maken. Ik verwacht niet dat Micro$ost zich zijn macht in de API markt laat afpakken.en Nvidia en AMD zullen even min hun terrein willen verliezen.Volgens mij is de Teraflops Research Chip iets heel anders dan de larrabee, de eerste is slechts een onderzoeksproject, terwijl de larrabee ook echt in de winkel moet gaan komen.
waarom dan?
als hij alle DX11 instructies kan afhandelen en bijna lineair schaalt is het maar een kwestie van voldoende cores in een chip te steken om prestaties te komen die gelijkaardig/beter zijn dan de concurrent, dat doet nVidia/Ati toch ook?
als hij alle DX11 instructies kan afhandelen en bijna lineair schaalt is het maar een kwestie van voldoende cores in een chip te steken om prestaties te komen die gelijkaardig/beter zijn dan de concurrent, dat doet nVidia/Ati toch ook?
De instructies zijn zeer generiek en kunnen dus zelfs toekomstige specificaties ondersteunen.als hij alle DX11 instructies kan afhandelen
De verwachting is wel dat qua prestaties de eerste generatie niet hoger dan een vergelijkbaar mid-end kaartje van NVIDIA of AMD zal komen. Latere generaties kunnen inderdaad mogelijks snel opschalen. Maar intussen zit de concurrentie natuurlijk niet stil dus blijft het afwachten of Intel daadwerkelijk iets revolutionairs kan presenteren.
beetje een vraag van wiens verwachtingen. Zoals gezegd is de Larabee bedoeld om eenvoudig veel cores samen te laten werken. Nu kunnen de prestaties van 1 core misschien achterblijven bij de "verwachtingen" maar als de core klein is en de architectuur goed schaalt kan Intel er heel veel samenproppen. Zolang er geen Larabees in de verkoop liggen is het dus koffiedik kijken hoeveel cores dat ding uiteindelijk krijgt, met welk energieverbruik en welke prijs. En laten de factoren, prijs, verbruik en prestaties nu net het succes bepalen. Het blijft dus afwachten waarmee Intel komt.
De Larrabee ondersteund geen hardware DX11, maar is een chip met een flink aantal (huidige geruchten leggen het aantal op 32 bij launch) x86 cores met ieder hun eigen 512bit vector unit. Deze cores zijn aan elkaar verbonden via een 1024bit ringbus, tevens zal er een rasterizer aanwezig zijn (anders kan je geen beeldopbouw produceren). Tevens betwijfel ik dat Lucid echt voor de Larrabee gebruikt wordt, deze zou namelijk al behoorlijk linear moete schalen.
DirectX en OpenGL zullen via software afgehandeld worden. In theorie is er dus geen nieuwe hardware nodig om een nieuwe Dx versie te ondersteunen, echter is het natuurlijk wel de vraag of een oudere chip dan nog snel genoeg is om zeg Dx 12 spellen te kunnen draaien wanneer deze versie uitkomt.
Larrabee zou trouwens eind dit jaar moeten verschijnen.
@E_E_F - Er is geen FSB, er is een 1024 bit brede (eigenlijk 512bit bidirectioneel) ringbus die op hoge frequentie zal draaien. Bandbreedte genoeg dus tussen de cores. Verder zal de kaart gewoon in een PCIe x16 slot zitten en natuurlijk z'n eigen geheugen hebben. Er bestaat ook een mogelijkheid dat er ook een versie van Larrabee komt die gewoon een een quickpath socket komt te zitten.
Huidige GPU's van ATi en nVidia hebben ook meerdere execution units die gezamenlijk gebruik moeten maken van de geheugenbus, PCIe bus, etc...
@.oisyn - Je hebt helemaal gelijk, ik dacht dat het de Rasterizer was, maar alleen bepaalde functies voor texturing worden in hardware uitgevoerd (geen volledige texture units). Buiten dat gebeurt echt alles in sofware.
DirectX en OpenGL zullen via software afgehandeld worden. In theorie is er dus geen nieuwe hardware nodig om een nieuwe Dx versie te ondersteunen, echter is het natuurlijk wel de vraag of een oudere chip dan nog snel genoeg is om zeg Dx 12 spellen te kunnen draaien wanneer deze versie uitkomt.
Larrabee zou trouwens eind dit jaar moeten verschijnen.
@E_E_F - Er is geen FSB, er is een 1024 bit brede (eigenlijk 512bit bidirectioneel) ringbus die op hoge frequentie zal draaien. Bandbreedte genoeg dus tussen de cores. Verder zal de kaart gewoon in een PCIe x16 slot zitten en natuurlijk z'n eigen geheugen hebben. Er bestaat ook een mogelijkheid dat er ook een versie van Larrabee komt die gewoon een een quickpath socket komt te zitten.
Huidige GPU's van ATi en nVidia hebben ook meerdere execution units die gezamenlijk gebruik moeten maken van de geheugenbus, PCIe bus, etc...
@.oisyn - Je hebt helemaal gelijk, ik dacht dat het de Rasterizer was, maar alleen bepaalde functies voor texturing worden in hardware uitgevoerd (geen volledige texture units). Buiten dat gebeurt echt alles in sofware.
[Reactie gewijzigd door knirfie244 op donderdag 15 januari 2009 16:45]
Leuk al die nieuwe ontwikkelingen in x64-land maar ik zie toch echt een smalle bottleneck ontstaan als het gaat om de fsb. Daar zullen zware eisen aan gesteld gaan worden als je nog wat rekenkracht over wilt houden. Een GPU met eigen geheugen kan in grafische toepassingen denk ik echt veel voordeel hebben. Dat is natuurlijk wel anders voor bepaalde niet-grafische applicaties.
[Reactie gewijzigd door E_E_F op donderdag 15 januari 2009 15:42]
Nee, er zijn texture units aanwezig. De rasterizer draait in feite gewoon in software op de chip.tevens zal er een rasterizer aanwezig zijn (anders kan je geen beeldopbouw produceren
Larrabee zal vooral ten eerste een derde speler worden als retail GPU.
Dus DirectX en OpenGL. Voor dev;s en consumenten niks anders.
Wat dan van belang is hoe iNtel ermee performed tov nV en ATI.
Nu die enkele developers die innovatief en hardware to the max willen gebruiken. Die kunnen optioneel een Larrabee native API PAth in hun software bouwen.
Ratrace engine Voxel. Of technieken die nu wel met computation power mogelijk zijn op de vrije flexible larrabee platform waar je bij ATI en nV belemmerd wordt door Fixed aanpak. Want veel is op die GPU nog Fixed.
nV en ATI GPU evolueren ook door de decenia's heen ook naar vollediger programmeerbaar. Maar dan niet X86 based. Maar meer HSML DX OpenGL spects. of nV en ATI machine code voor hun shaders. Shader ASM.
Het is net of iNtel ATI en nV ovolutie weg compleet overslaat en meteen met eind resultaat komt.
Software matig zal al snel langzamer zijn dan Fixed. Maar iNtel kan zijn Procede voorsprong gebruiken om dit op te vangen. Nu zou dat 2de gen 45nm vs 55nm.
Ik ben dus ten eerste benieuwed naar performance.
En een Larrabee hybrid CPU voor Physics en AI gebruik lijk mij ook interresant.
Dus DirectX en OpenGL. Voor dev;s en consumenten niks anders.
Wat dan van belang is hoe iNtel ermee performed tov nV en ATI.
Nu die enkele developers die innovatief en hardware to the max willen gebruiken. Die kunnen optioneel een Larrabee native API PAth in hun software bouwen.
Ratrace engine Voxel. Of technieken die nu wel met computation power mogelijk zijn op de vrije flexible larrabee platform waar je bij ATI en nV belemmerd wordt door Fixed aanpak. Want veel is op die GPU nog Fixed.
nV en ATI GPU evolueren ook door de decenia's heen ook naar vollediger programmeerbaar. Maar dan niet X86 based. Maar meer HSML DX OpenGL spects. of nV en ATI machine code voor hun shaders. Shader ASM.
Het is net of iNtel ATI en nV ovolutie weg compleet overslaat en meteen met eind resultaat komt.
Software matig zal al snel langzamer zijn dan Fixed. Maar iNtel kan zijn Procede voorsprong gebruiken om dit op te vangen. Nu zou dat 2de gen 45nm vs 55nm.
Ik ben dus ten eerste benieuwed naar performance.
En een Larrabee hybrid CPU voor Physics en AI gebruik lijk mij ook interresant.
Als er geen Xfire of SLI meer nodig is, scheelt dat een aardig beetje licentiekosten, dus worden de X58 en volgende borden een stukje goedkoper. Dat zou mooi zijn.
Maar als ik dit lees, denk ik meteen aan de Zii wat vorige week werd geintroduceerd, waarbij ook meerdere componenten samen kunnen werken.
Zit er een overeenkomst tussen deze en Hydra?
Maar als ik dit lees, denk ik meteen aan de Zii wat vorige week werd geintroduceerd, waarbij ook meerdere componenten samen kunnen werken.
Zit er een overeenkomst tussen deze en Hydra?
Dacht dat dit Limix techniek voordeel is dat het zelf de loadbalancing regelt en dus optimaal schaald. Doet me denken aan OPENCL waar men elke PU kan gebruiken maar zelf de higher level managen van de PU zelfs over netwerken moet regelen.
nV Cuda en ATI CMT steam oplossing is Fixed symetrische oplossing wat in houd.
Het schaald niet zo mooi. Kan geen asymetrische combish maken.
Maar daarin tegen haald het de higher level load balansing en tread management van al die coretjes uit developers handen weg.
Waar developer dus op hun applicatie kunnen focusen ipv op laag niveau de hardware layer op gang te brengen. Cuda en steam en HSML is dus een leuke instap.
Denk dat Lumix die low level balancing trap dan overneemt. En daar in gespecialiseerd zijn.
iig dat idee heb ik.
nV Cuda en ATI CMT steam oplossing is Fixed symetrische oplossing wat in houd.
Het schaald niet zo mooi. Kan geen asymetrische combish maken.
Maar daarin tegen haald het de higher level load balansing en tread management van al die coretjes uit developers handen weg.
Waar developer dus op hun applicatie kunnen focusen ipv op laag niveau de hardware layer op gang te brengen. Cuda en steam en HSML is dus een leuke instap.
Denk dat Lumix die low level balancing trap dan overneemt. En daar in gespecialiseerd zijn.
iig dat idee heb ik.
Ik denk dat Intel zelf wat problemen is tegen gekomen bij het schalen naar vele cores, +200 zo als een AMD/Nvidia chipje is niet makelijk en voor grafisch werk zo als dat nu gedaan wordt wel nodig. Ik denk dat Intel dus gewoon een stukje technologie koopt van een ander bedrijf. Als het goed werkt koopt Intel het bedrijfje en als het niets hoeft Intel geen geld te besteden aan onderzoek naar een vergelijkbare oplossing.
Daar naast vraag ik me af of het alleen voor Larabee is of dat Intel mischien ook andere processoren in gedachten heeft voor deze techniek. Uit eindelijk weet intel ook dat een processor niet heel veel meer sneller gemaakt kan worden zonder de schaal te verkleinen. En de schaal verkleinen is nu juist waar we tegen het einde van de huidige mogenlijkheden aan zitten, nog een beetje kleiner lukt heus wel maar heel veel veder gaan we niet komen. En pipe line optimalizaties of betere instruction handlers begint ook steeds moeilijker te worden, de x86 architectuur zit ook hier toch redelijk dicht bij het geen mogenlijk is door al die jaren research en ontwikkeling.
Intel zou dus best wel eens van plan kunnen zijn om zo als ze ook al een beetje aan gegeven hebben in het verleden naar een many core chip te willen gaan. Maar het probleem daarbij blijft comunicatie. Hoe kun je 20, 40 of 80 cores net zo efficient laten samen werken als 2 cores of vier cores. Op een gegeven moment is er wel heel veel bandbreete nodig voor overleg en beslisingen wie wat gaat doen en waarneer, waardoor je boven een bepaalde hoeveelheid gewoon niet meer echt winst behaald maar alleen maar meer vertraging toe gaat voegen door overhead.
Als deze technologie echt zo goed schaalt als geclaimed wordt dan kon dat nog wel eens een flinke sprong vooruit betekenen voor Intel, ze kunnen dan veel beter gebruik maken van meerdere cores in een chip zonder dat de communicatie overhead een groot deel va de winst van meerdere cores weg neemt.
Ik denk dat als Intel over een paar jaar hun onderzoeks gegevens van de 80 core chip bekend maken dat we zullen zien dat Intel daar tegen een plafont aan is gekomen waar boven multi core opstellingen weinig tot geen winst konden boeken (denk aan SLI/CrossFire). Intel zal denk al heel snel aan kondigen dit bedrijfje te kopen als hun techniek echt zo goed werkt, al is het maar om te voorkomen dat de concurenten de techniek in handen kunnen krijgen.
Daar naast vraag ik me af of het alleen voor Larabee is of dat Intel mischien ook andere processoren in gedachten heeft voor deze techniek. Uit eindelijk weet intel ook dat een processor niet heel veel meer sneller gemaakt kan worden zonder de schaal te verkleinen. En de schaal verkleinen is nu juist waar we tegen het einde van de huidige mogenlijkheden aan zitten, nog een beetje kleiner lukt heus wel maar heel veel veder gaan we niet komen. En pipe line optimalizaties of betere instruction handlers begint ook steeds moeilijker te worden, de x86 architectuur zit ook hier toch redelijk dicht bij het geen mogenlijk is door al die jaren research en ontwikkeling.
Intel zou dus best wel eens van plan kunnen zijn om zo als ze ook al een beetje aan gegeven hebben in het verleden naar een many core chip te willen gaan. Maar het probleem daarbij blijft comunicatie. Hoe kun je 20, 40 of 80 cores net zo efficient laten samen werken als 2 cores of vier cores. Op een gegeven moment is er wel heel veel bandbreete nodig voor overleg en beslisingen wie wat gaat doen en waarneer, waardoor je boven een bepaalde hoeveelheid gewoon niet meer echt winst behaald maar alleen maar meer vertraging toe gaat voegen door overhead.
Als deze technologie echt zo goed schaalt als geclaimed wordt dan kon dat nog wel eens een flinke sprong vooruit betekenen voor Intel, ze kunnen dan veel beter gebruik maken van meerdere cores in een chip zonder dat de communicatie overhead een groot deel va de winst van meerdere cores weg neemt.
Ik denk dat als Intel over een paar jaar hun onderzoeks gegevens van de 80 core chip bekend maken dat we zullen zien dat Intel daar tegen een plafont aan is gekomen waar boven multi core opstellingen weinig tot geen winst konden boeken (denk aan SLI/CrossFire). Intel zal denk al heel snel aan kondigen dit bedrijfje te kopen als hun techniek echt zo goed werkt, al is het maar om te voorkomen dat de concurenten de techniek in handen kunnen krijgen.
Veel denken en aannames van jouw kant, en vervolgens op basis daarvan voorspellingen voor de toekomst doen, dat heeft niet veel nut, denk ik.
Waar haal je het vandaan bijvoorbeeld dat Intel tegen een plafonD (Met d ja...) is gelopen? Je eigen aanname of heb je daar enige onderbouwing voor?
Verder, je gooit je suggestie erin dat Intel met problemen zit ergens op het gebied van hun grafische chips. Hoe kom je daarbij? X86 zit dicht? Op welk gebied dan?
Waar haal je het vandaan bijvoorbeeld dat Intel tegen een plafonD (Met d ja...) is gelopen? Je eigen aanname of heb je daar enige onderbouwing voor?
Verder, je gooit je suggestie erin dat Intel met problemen zit ergens op het gebied van hun grafische chips. Hoe kom je daarbij? X86 zit dicht? Op welk gebied dan?
Ik vind het ook raar.
Ten eerste maakt iNtel altijd al GPU's maar dan in IGP form.
Zelf vroeger een i740 van Asus gehad. Retail GKaart.
Ook IGP van nu hebben DX9 en dus een aantal shaders.
'n retail GPU verschil met IGP is dat ze van al die logische units zeg maar modulare delen zoals shaders TMU Rops etc gewoon veel meer van hebben.
iNtel kan dus makkelijk een GPU bakken de basis hebben ze al lang.
Waar ze op achter lopen is de Driver team die voor snelle en frequente solide high performance drivers zorgen. Maar dat kan ook komen.
Maar in plaat daarvan zijn ze extreem en risiko vol met hun innovatieve software oplossing bezig. Larrabee. Dat doet een achter loper niet.
Denk dat ze bij iNtel wel de nodige verstand van multicore en multitreading hebben.
Aangezien ze soms Developers bij staan met multitreaden en ook niet de minste zoals IDsoft met Quak4 geloof ik game,
Ze hebben zelfs een Multitreaded game demo staan smoke demo. Dat me toch ook wel sterk aan valve Multitreaded aanpak doet denken. Maar dan dan toch geavanceerder. Gezien ik Valve idee makkelijker te volgen vond dan die van iNtel.
Zoals Tread synchronisate onkoppeling met bepaald design pattern zoals een observer constructie. En dan op het einde de meest up to date data updaten.
Maar ja innovatie en het roer valikant omgooien is vooral een risiko. Doordat het zo anders is is het moeilijk uit de vele factoren die meespelen te bepalen of iNtel failed of derde Retail GPU speler wordt. Of de Retail GPU markt op lange termijn gaat overheersen.
Daarbij staan nV en ATI ook niet stil.
Ben benieuwed.
Ten eerste maakt iNtel altijd al GPU's maar dan in IGP form.
Zelf vroeger een i740 van Asus gehad. Retail GKaart.
Ook IGP van nu hebben DX9 en dus een aantal shaders.
'n retail GPU verschil met IGP is dat ze van al die logische units zeg maar modulare delen zoals shaders TMU Rops etc gewoon veel meer van hebben.
iNtel kan dus makkelijk een GPU bakken de basis hebben ze al lang.
Waar ze op achter lopen is de Driver team die voor snelle en frequente solide high performance drivers zorgen. Maar dat kan ook komen.
Maar in plaat daarvan zijn ze extreem en risiko vol met hun innovatieve software oplossing bezig. Larrabee. Dat doet een achter loper niet.
Denk dat ze bij iNtel wel de nodige verstand van multicore en multitreading hebben.
Aangezien ze soms Developers bij staan met multitreaden en ook niet de minste zoals IDsoft met Quak4 geloof ik game,
Ze hebben zelfs een Multitreaded game demo staan smoke demo. Dat me toch ook wel sterk aan valve Multitreaded aanpak doet denken. Maar dan dan toch geavanceerder. Gezien ik Valve idee makkelijker te volgen vond dan die van iNtel.
Zoals Tread synchronisate onkoppeling met bepaald design pattern zoals een observer constructie. En dan op het einde de meest up to date data updaten.
Maar ja innovatie en het roer valikant omgooien is vooral een risiko. Doordat het zo anders is is het moeilijk uit de vele factoren die meespelen te bepalen of iNtel failed of derde Retail GPU speler wordt. Of de Retail GPU markt op lange termijn gaat overheersen.
Daarbij staan nV en ATI ook niet stil.
Ben benieuwed.
Goed dat Intel, Nvidia hiermee een hak zet, kan de consument tenminste voor een fatsoenlijke prijs SLI draaien.
Ik blijf het een..vreemd ( heb er eigenlijk geen woorden voor),
dat in de toekomst AMD EN NVIDIA GPU's met elkaar kunnen samenwerken. Als Jensen en Meyer dood geweest zouden zijn hadden ze zich 10x omgedraaid in hun graf.
Als je elkaar jaren zo hebt bestreden dan komt een ''verplichte'' samenwerking toch keihard aan?
Ik blijf het een..vreemd ( heb er eigenlijk geen woorden voor),
dat in de toekomst AMD EN NVIDIA GPU's met elkaar kunnen samenwerken. Als Jensen en Meyer dood geweest zouden zijn hadden ze zich 10x omgedraaid in hun graf.
Als je elkaar jaren zo hebt bestreden dan komt een ''verplichte'' samenwerking toch keihard aan?
Je hoeft je geen zorgen te maken. Hetgeen Lucid belooft zal nooit effectief werken...Als je elkaar jaren zo hebt bestreden dan komt een ''verplichte'' samenwerking toch keihard aan?
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
