Kernel-changelog onthult x86-64-ontwikkeling door Intel

In navolging van de uitspraak van een analist gisteren dat Intel plannen heeft om in de tweede helft van 2004 of begin 2005 een 64-bits x86-processor aan te kondigen heeft Planet3dNow een opmerkelijke ontdekking gedaan in recente changelogs van de Linux-kernel. Len Brown, als programmeur werkzaam bij Intel, heeft voor Linux versie 2.4.23 een aantal problemen opgelost met betrekking tot de x86-64-code in de ACPI-module. Als recent aangestelde onderhouder van deze code kan dat uiteraard gewoon tot een van zijn verantwoordelijkheden worden gerekend, maar het feit dat er bij Intel ook naar de softwarekant van x86-64 wordt gekeken is ergens toch opvallend te noemen. Dat het bedrijf bij het ontwerpen van de 0,09 micron Pentium 4 zogenaamde Yamhill-technologie heeft ingebouwd is inmiddels publiek geheim geworden, maar omdat het onderwerp strategisch gezien zeer gevoelig ligt zwijgt men er officiëel nog steeds in alle talen over.

De door de analist genoemde tijdsspanne komt in ieder geval overeen met de periode waarin de Tejas-core verwacht wordt. Hans de Vries van Chip Architect vermoedde ook al dat Intel bij de opvolger van Prescott de overstap naar 64-bits zou gaan maken. Uit de roadmaps zijn op dit moment ook nog geen grote verschillen naar boven gekomen tussen de eerste en de tweede 0,09 micron Pentium 4; voor zover we weten blijven socket, FSB, L2-cache en productieprocédé tijdens de overstap van Prescott naar Tejas ongewijzigd. Wel wordt er gesproken over Tejas New Instructions, verbeterde HyperThreading en een groter L1-cache, maar deze punten kunnen maar een klein deel van de extra transistors verklaren.

Reacties (27)

[JeroenB]

Ik vind het helemaal niet raar dat de maintainer van een stuk code iets fixt dat toevallig te maken heeft met de technologie van een concurrent van zijn eigen werkgever. Belangrijk om te beseffen is dat het niet Intel is die deze code maintained, maar de werknemer persoonlijk. Dit is dus op geen enkele manier een goedkeuring oid van Intel.

[Verwijderd]

Intel komt zoiezo met een 64 bits processor daar kun je op wachten, maar iedereen wil weten wanneer dit gebeurd. En zulke dingen vallen natuurlijk al gauw op als je zit te wachten op een dergelijke processor, dan probeer je alles aan te grijpen om aan te geven dat hij zo komt, dan kan je er nog op wachten.

* 786562 thekip

[Papillon]

Nou om eerlijk te zijn heeft Intel al jaren een 64 bits processor te weten de Itanium (daar is dus eigenlijk niets bijzonders aan). Waarschijnlijk wordt de entry level processor in de loop van volgend jaar een 64 bits processor. Met andere woorden een 64 bits processor voor de consument.

Als je afgaat op de huidige memory grootte's, disk grootte's en dergelijke wordt het zo voorzichtig aan wel tijd. Nu komt men met trucjes als high en low memory aanzetten om boven de 4 GB grens (welke een beperking is van de 32 bits processor) te komen. Sterker nog het accessen van bestanden groter dan 4 GB (wederom de 32 bots grens) wordt ook al wat je noemt hinderlijk.

Kortom, voor mij is het niet meer dan logisch dat er een 64 bits processor voor het consument komt omdat de consument nu ook tegen dezelfde hindernissen aanloopt waar het bedrijfsleven jaren geleden al mee te maken kreeg.

[dasiro]

het gaat hier om een X86-64 ontwikkeling, terwijl de itaniums op IA64 zitten. daarom wordt de link met de aan te kondigen nieuwe cpu gelegd en niet met de itanium

[the_stickie]

het heeft toch zeker ook iets met het typische consumentenverhaal te maken:
Jan met de pet (Jmdp): Hallo, ik wil een goeie pc!
Verkoper: Je kan kiezen tussen amd en intel
Jmdp: Euh? --tilt-- wat is het verschil dan?
Verkoper: Niet zoveel, de een is beter in dit de ander in dat én de nieuwste amd's ondersteunen nu ook 64 bit
Jmdp: Euh? --tilt-- wat is 64 bit?
Verkoper: *zucht* Vroeger was alles 16 bit, nu 32 en later zal alles op 64 bit zijn
Jmdp: dus 64 bit is nieuwer?
Verkoper: *kijkt vertwijfeld* Mhh, ja eigenlijk wel
Jmdp: DIE WIL IK!

[Verwijderd]

"Met andere woorden een 64 bits processor voor de consument" dus eigenlijk een 64 bit processor die ook nog 32 bit emuleerd --> AMD 64 dus

"Als je afgaat op de huidige memory grootte's, disk grootte's en dergelijke wordt het zo voorzichtig aan wel tijd. Nu komt men met trucjes als high en low memory aanzetten om boven de 4 GB grens (welke een beperking is van de 32 bits processor) te komen. Sterker nog het accessen van bestanden groter dan 4 GB (wederom de 32 bots grens) wordt ook al wat je noemt hinderlijk.

Kortom, voor mij is het niet meer dan logisch dat er een 64 bits processor voor het consument komt omdat de consument nu ook tegen dezelfde hindernissen aanloopt waar het bedrijfsleven jaren geleden al mee te maken kreeg."

begrijp niet wat er logisch is aan consumenten met 4 GB geheugen op dit moment.
workstations ect. -> geen consumenten product

en ik zie nog geen hindernissen die consumenten hebben met 32bit aangezien alles nog in 32bit is wat de consument wil.

enige waar t om gaat is dat AMD die 64bit/32bit cpu al heeft en dat ie fucking blaaaaast

meer wilt de consument nie weten / horen anders heb je nix aan die 64bit (consumer thinking)

[Wouter Tinus]

Intel investeert jaarlijks tientallen miljoenen in Linux en Linux-software. In eigen huis bouwen ze ook een hele stapel applicaties en ontwikkeltools (compilers, performance analysers, libraries) èn werken ze mee aan de kernel. De IA-64 ondersteuning hebben ze bijvoorbeeld voor een groot deel zelf aangeleverd. Het is dus echt niet zo dat de betrokkenheid van Intel bij Linux beperkt is tot persoonlijke bijdrages van mensen die toevallig bij Intel werken maar in hun vrije tijd een beetje 'bijbeunen'. Nu is het natuurlijk niet na te gaan in hoeverre die Len Brown deze dingen tijdens werktijd doet, maar zo stellig als jij beweert dat het niet zo is zou ik het niet doen.

[Iblies]

Wat een ongelooflijk ***-argument. Het is toch niet meer dan logisch dat een processor-bouwer bepaalde optimalisaties schrijft voor een OS. Als er bepaalde nieuwe dingen worden geimplenteerd in de proc, dan moet je daar toch drivers voor schrijven. Kijk maar naar de GPU's. Daarbij komt nog dat ik wel enige twijfels heb over het bedrag dat je suggereert, tientallen miljoenen guldens?? Over hoeveel jaar praat je dan. Het personeel zal wel goed verdienen, maar zoveel mensen zullen er ook niet aan worden gezet. Linux is internationaal, en veel mensen optimaliseren de kernel beetje bij beetje. Dus dat komt niet compleet alleen van de hand van Intel. Ze zullen waarschijnlijk een alfa-beta versie aanbieden, waaraan weer verder wordt gesleuteld.

[Cheetah]

Intel heeft gedurende 2004 dan wel een aardige achterstand op AMD qua 64bit computing.
Aan de andere kant zou op de consumentenmarkt eind 2004 voor Intel ook wel een goed introductietijdstip zijn, omdat Micrsoft ook ongeveer in die periode de 64bit variant van Windows XP uitbrengt. Tot dan worden zouden de 64bit instructies van de CPU's grotendeels toch niet gebruikt worden, gezien het gros van de consumenten nog op 32bit Windows varianten draait.

Voor low-end servers en midrange echter, waar wel degelijk gebruik kan worden gemaakt van de 64bit extenties (bijv. middels 64bit Linux) zal Intel vermoedelijk wel tegen enige achterstand op AMD aanlopen, gezien de Opteron in een aardig deel van de benchmarks zelfs in 32bit de Xeon de baas is. Als hier 64bit routines bij gehaald worden kan het prestatieverschil in sommige gevallen aanzienlijk oplopen.

[TheGhostInc]

Intel is een bedrijf dat zelf heel sterk rekent, een beetje in de trant van "win some, lose some".

Stel dat Amd 10% sneller is, betekent dat niet dat er ook 10% meer vraag naar Amd's komt. Misschien een paar tienden van een procent per maand. Als je dan snel rekent betekent een voorsprong van Amd na een jaar niet meer dan een paar procent winst. Let wel op: Vanaf het moment dat ze 10% sneller zijn.
En dat zijn ze zeker nog niet, zonder 64bit OS, zonder 64bit applicaties, dan zijn ze *soms* sneller. Maar met de huidige prijzen is dat niet voldoende om de markt over te nemen.
Dus die achterstand, het is eerder een jumpstart voor Intel, zodra het publiek doorheeft dat er 64bit is, dan heeft Intel die processor ook liggen.

[Brons]

Ehm, zonder 64bit OS en applicaties?
Gcc kan al een heletijd 64bit code compilen.

[belstrekkie]

Goh, ik heb eens gekeken onder die link van Yamhill naar de wat oudere artikelen, vnl over de prescott. Wat een verwachtingen hadden ze daarvan zeg:
http://www.tweakers.net/nieuws/20829/?highlight=yamhill
introductie halverwege 2003 niet onder de 4 gig en aan het eind van het jaar 5-6 gig?? 'T is toch wat anders gelopen dan

[Martin Sturm]

Om heel eerlijk te zijn vind ik dit wel erg vergezocht hoor. Kernel-maintainers (en open-source programmeurs over het algemeen) moeten over het algemeen weinig van politieke invloeden of iets dergelijks hebben. Ik denk dat deze fix gewoon puur als 'verbetering van Linux' moet worden beschouwd dan als voorbereidingen van Intel. Ik denk ook niet dat het binnen de kernel-gemeenschap, om het zo maar eens te noemen, niet erg goed zal vallen als de maintainer van het ACPI gedeelte zich opdrachten van zijn werkgever laat opleggen die gevolgen voor het functioneren van het systeem in het algemeen zou hebben. Het is dus ook onvoorstelbaar dat hij een patch zou weigeren die een probleem met AMD proc's oplost omdat hij bij Intel werkt.

Is zeg maar net zoiets als je zou zeggen dat de TU/e over gaat stappen op Linux omdat een prof bijdrage verleent aan Linux.

[Verwijderd]

Wat zou het probleem zijn als open source programmeurs wél politiek beïnvloed zouden zijn? Zolang dit geen concessies oplevert in de code kan het enkel positief zijn.
Betere support voor Intel hardware omdat Intel hun ontwikkelaars instellen is toch prima. So what als AMD dan achterblijft, dan moet AMD óók maar ontwikkelaars op Linux zetten. Het zou pas een probleem zijn wanneer huidige code op Intel hardware wordt aangepast met als gevolg dat AMD chipjes trager gaan.
Overigens kun je bij ACPI ook niet bepaald spreken van onpartijdigheid; ACPI is deels door Intel ontwikkeld en Intel is de grootste promotor van ACPI, kijk maar op www.acpi.info .

[Femme]

Als een werknemer van Intel verantwoordelijk is voor de ACPI-code in Linux dan moet hij er ook voor zorgdragen dat de ACPI-ondersteuning voor andere platformen dan die van Intel wordt onderhouden anders kan zo iemand niet de van hem verlangde verantwoordelijkheid dragen. Het feit dat ACPI deels door Intel is ontwikkeld heeft daar weinig mee te maken aangezien het hier gaat om de ondersteuning in Linux. De gebruikers van Linux willen volwaardige ACPI ondersteuning voor alle mogelijke platformen.

[Verwijderd]

Tuurlijk, maar je kan 't 'm moeilijk kwalijk nemen als hij zich primair op de producten van z'n eigen werkgever richt en dáárna pas op die van de concurent. Als de concurent hier bezwaar tegen heeft is er niemand die ze tegenhoudt om zelf óók aan de ACPI ondersteuning te werken, 't is tenslotte niet alsof die Inteller wijzigingen die door AMD aangeleverd worden zomaar kan tegenhouden.

[Wouter Tinus]

Ik denk ook niet dat het binnen de kernel-gemeenschap, om het zo maar eens te noemen, niet erg goed zal vallen als de maintainer van het ACPI gedeelte zich opdrachten van zijn werkgever laat opleggen die gevolgen voor het functioneren van het systeem in het algemeen zou hebben. Het is dus ook onvoorstelbaar dat hij een patch zou weigeren die een probleem met AMD proc's oplost omdat hij bij Intel werkt.

Dit zijn implicaties die jij er zelf bij verzint, nergens in het artikel of de bron wordt ook maar de flauwste suggestie gewekt dat hij AMD probeert te dwarsbomen ofzo. Feit is dat je om dit soort bugfixes te testen x86-64-hardware nodig hebt, en als die bij Intel zelf staat (en dat is dus de grote vraag) dan praten we waarschijnlijk niet over Opterons .

[Verwijderd]

Misschien wordt het nu eindelijk eens een trend dat hardware fabrikanten elk een mannetje aan het kernel gedeelte dat hun hardware aanstuurt laten werken...

Goeie ontwikkeling!

[blade181]

Ik vind dat je daar gelijk in hebt, maar producenten van apparaten, vooral multimedia, mogen naar mijn inziens wel is beginnen met het leveren van hun volledige werking van zulke apparaten doorspelen aan de verschillende afdelingen van de kernel maintainers.

Nu is het zo dat ze het zelf maar uit moeten vissen en dan krijgen we een beetje van die half werkende apparaten. Met als duidelijk voorbeeld, de soundcards!

Ooh en hier is dus ook een groot voorbeeld dat er tegenwoordig geen Wintel bestaat!

[Verwijderd]

Misschien krijgt die gewoon een geheugen controller net zoals AMD nu heeft. Dat zou al direct een grote toename van transistoren verklaren.

[Beaves]

De ontwikkeling van Yamhill is begonnen voordat precies duidelijk was wat de Hammer serie van AMD ging doen kwa prestatie, prijs en acceptatie, dus Yamhill is geen reactie op het succes van x86-64, maar een voorzorgsmaatregel.

Intel heeft gewoon op twee paarden gewed, hun eigen IA-64 en x86-64 (al dan niet compatible met de implementatie van AMD). Dit in het geval dat IA-64 geen succes wordt op de consumenten markt. Dan willen ze dus niet dat ze in dat geval nog eerst een CPU moeten ontwerpen met x86-64 code erin. Dat zou teveel tijd, moeite en geld kosten.

Nu ze een CPU hebben waar die code al in zit is het een kwestie van de code inschakelen en ze zijn "klaar". Dat is wel gezichtsverlies, maar beter dan achter de feiten aanlopen. Nu kan Intel binnen een jaar x86-64 CPU's leveren, zonder Yamhill had dat veel langer geduurd.

[Verwijderd]

Yamhill is wel degelijk een reactie op het mogelijke succes van Hammer, dus Intel vond het wel nodig om rekening te houden met de mogelijkheid dat AMD een winner in handen heeft.

[OldButNotSoWise]

Ach volgens mij maakt intel zich gen zorgen over die paar tweakers.

Ik in ieder geval wacht met overstappen op een 64bits CPU totdat er een Intel on Intel consumenten combinatie is.
Heb daar meer vertrouwen in als in AMD op VIA/SiS/AMD.

oke de AMD's zullen nu een stuk beter zijn als in het begin maar zo'n solide naam als intel krijgen ze voorlopig niet.

En dan zal XP-64 dan misschien niet echt lekker draaien op Intel's CPU de opvolger van XP zal dat gebrek niet meer hebben lijkt me.

[mr._Anderson]

Sorry maar dit is echt niet waar.

AMD systemen zijn tegenwoordig net zo rock-stable als intel systemen.

Verder draai ik nu al een tijdje op AMD, en beide keren met VIA chip-set en heb er nog nooit, nee nooit problemen meegehad. Beide systemen zijn zeer stabiel en snel.

Dat AMD nog steeds soms word achtervolgd als kwalitatief minder komt door mensen die meningen zoals de jouwe verspreiden.

Zo stond ik eens in een computerwinkeltje waar ik vroeg of ze de Athlon64 gingen verkopen (die was nog niet uit), ze zeiden AMD? Troep...
M'n mond viel open,
nee sinds de Athlon (K7) is AMD gewoon perfect in orde.
En ook de chipset zijn gewoon stabiel, snel en goed. Via heeft wat mindere modellen gehad, dat geef ik ook toe, maar dan zijn er nog altijd andere chip-set waar je naar toe uit kan wijken.

En nu met de K8 series processors is AMD helemaal net zo kwalitatief goed als Intel. Heatspreaders, het koelings system is goed, de processors zijn stabiel, en ook de moederborden met chipsets.

En als AMD niet zo'n solide naam heeft, waarom denk je dat ze gaan samen werken met Sun. Waarom zou HP AMD systemen gaan leveren?

Conclusie: AMD is net zo solide als Intel.

Ik draai zelf nu een Athlon64, en ik kan objectief zeggen dat ik nog wat probleempjes heb met Cool 'n' Quiet in te schakelen. Maar ook zonder WindowsXP-64 is mijn system snel en stabiel.
Om de nieuwe drivers voor de Athlon64 te installeren had ik wat problemen, maar dat was opgelost met een bios update. Elk nieuw platform heeft zo wel zijn dingetjes. Maar bottom-linen, ik installeerde alles, starte windows weer op en alles was direct stabiel en snel. Dat zijn mijn zo objectief mogelijk bevindingen.

[Verwijderd]

Uiteraard ligt 64-bit in het verschiet. Ik vindt dit niet zo'n grote ontdekking. Vraag is eerder wanneer komt Intel hiermee. Vooralsnog vindt ik dat AMD het uitstekend doet. Intel zal niet te lang achter mogen blijven lopen anders heeft straks AMD ook al de budget-markt in 64-bit veroverd wanneer Intel zijn nieuwe technologie gaat introduceren.

[CH4OS]

Ligt misschien aan mij...
Maar als de software x86-64 ondersteund, neemt dat nog niet weg, dat Intel snel met x86-64 processors komt hoor... Want de core zelf, moet het ook nog immers ondersteunen... En niet alleen de software... Anders zou het geen x86-86 processor zijn...