[P&W] 32 bit vs 64 bit processors

[Verwijderd]

Met de komst van nieuwe 64 bit processoren, rijzen er bij mij nogal wat vragen op wat dit met zich meebrengt bij onze zelfgebouwde proggies.

- Blijft dit gewoon werken (heb verhalen gehoord dat de nieuwe intel niet zo 1-2-3 backwards compatibel zou zijn)?

-En hoe zit het met de compilers van c++ en delphi bijvoorbeeld? Blijft dit gewoon werken of komt er een patch voor of moet het hele software pakket vernieuwd worden?

Wat denken jullie hiervan?

[mulder]

Lijkt me sterk, kan me dit bij een OS nog voorstellen, niet bij een processor.

[Verwijderd]

Intel zijn 64bit processor is gebaseerd op een hele nieuwe architectuur dus daar kan je sowieso geen x86 applicaties op runnen. De nieuwe AMD processor met 64bit extensies is daarentegen gewoon een 32bit processor met een extra set (64bit) instructies. Je kunt dus gewoon je oude compiler blijven gebruiken. Als je gebruik maakt van de nieuwe instructies van deze processor zul je waarschijnlijk wel een andere compiler en/of plugin nodig hebben.

[Soultaker]

Op vrijdag 28 juni 2002 22:27 schreef o_o het volgende:
- Blijft dit gewoon werken (heb verhalen gehoord dat de nieuwe intel niet zo 1-2-3 backwards compatibel zou zijn)?

Dat lijkt me heel sterk. Als er één bedrijf is dat goed begrepen heeft hoe belangrijk backward compatibility is, is het Intel wel.

Verder is fatsoenlijke software, of nieuwe CPU's nu wel of niet backward compatibel zijn, wel opnieuw te compileren. Stukjes assembly code zullen wel wat problemen geven, maar meestal hoort daar wel een stukje backup-code in C bij.

[Verwijderd]

Op vrijdag 28 juni 2002 22:55 schreef Soultaker het volgende:
Dat lijkt me heel sterk. Als er één bedrijf is dat goed begrepen heeft hoe belangrijk backward compatibility is, is het Intel wel.

Het is toch echt zo - de nieuwe 64bit intel proc is niet backwards compatible. Vond ik ook al vreemd overigens.

Verder is fatsoenlijke software, of nieuwe CPU's nu wel of niet backward compatibel zijn, wel opnieuw te compileren. Stukjes assembly code zullen wel wat problemen geven, maar meestal hoort daar wel een stukje backup-code in C bij.

Mjah, wat betekent het... Stomgezegd kun je zeggen dat in C code nauwelijks problemen zullen ontstaan, tenzij je lowleven stukjes code schrijft waarin je er vanuit gaat dat sizeof(void*)==sizeof(int) of s/void*/long/. Zolang je daar netjes rekening mee houdt, heb je geen problemen met je eigen code. Die hoef je alleen maar te recompilen. Zelf draait mijn (C) code behalve op de x86 al op 64bit alpha dingetjes, dus dat zit wel goed. .

Assembler zul je moeten herschrijven, en code die je alleen in binary hebt zul je weinig meer aan hebben (tenzij er een software x86 emulator komt).

Voor high-level scripting talen (PHP, perl) en VM talen (java) maakt het allemaal niks uit, die merken hier helemaal niks van.

Op vrijdag 28 juni 2002 22:27 schreef o_o het volgende:
-En hoe zit het met de compilers van c++ en delphi bijvoorbeeld? Blijft dit gewoon werken of komt er een patch voor of moet het hele software pakket vernieuwd worden?

Compilers moet je opnieuw maken, je moet namelijk andere assembler maken.

[marcusk]

Intel's Itanium heeft een hardwarematige IA32 emulator, dus daarop kunnen oude progjes gewoon draaien, maar niet bepaald met hoge snelheid. Als de IA64 processors er voor de gewone consument zijn is het dus te hopen dat alle belangrijke proggels voor deze nieuwe architectuur beschikbaar zijn of deze emulator sterk verbeterd is.

Overigens ziet de IA64 architectuur er IMHO erg goed uit, dus ik hoop dat ie het 'wint' van AMD's v x86/64 (zo heet het toch?)

[mbravenboer]

Kon de 64 bit processor van Intel niet emuleren? Als ik het me goed herrinner functioneerde dat niet bepaald goed, maar het kon dacht ik wel...

Alle details weet ik er echter niet van. In ieder geval zullen vrijwel alle applicaties prima werken op een 64 bits processor als deze opnieuw gecompileerd zijn met een compiler voor deze architectuur. Hercompilatie lost al deze problemen dus op, maar daar heb je natuurlijk niet zoveel aan als je leverancier alleen gecompileerde code levert. GNU systemen zijn wat dat betreft enorm in het voordeel, omdat je daar vaak de applicatie moet compileren tijdens het installeren.

De compiler heeft bij deze nieuwe architectuur van Intel trouwens nogal wat interessante (RISC achtige) taken tov de IA32 architectuur en hierdoor zal een goed optimaliserende compiler een grote invloed op de performance kunnen hebben.

Een paar quotes:

Itanium(TM) is Intel's new 64-bit architecture. It is based on the EPIC (Explicitly Parallel Instruction Computing) concept which exploits the high level of Instruction Level Parallelism (ILP) found in application software. To accomplish this goal, Itanium provides a powerful set of features such as control and data speculation, predication, register rotation, loop branches, and a large register file. By using these features, the compiler plays a crucial role in achieving the overall performance of an Itanium platform.

en hier vandaan:
http://www.devx.com/itanium/art_Perform.asp
dit:

The Itanium processor owes a lot of its boosted performance capability to the fact that the CPU, like a RISC processor, has few supervisor circuits to slow it down with the need to detect resource conflicts; that job becomes the responsibility of the compiler. While most other CPUs in general use do parallel processing behind the programmer's back, so to speak, Intel and Hewlett-Packard make use of what Intel calls "explicitly parallel instruction computing," or EPIC. With EPIC architecture, the instruction set relies on the compiler (or programmer) to provide "hints" about branch optimization, loop optimization, and memory access. This means fewer transistors expended on cycle-consuming "supervisors," which means more transistors on the chip to do more actual processing. And that means smaller, cooler CPU chips in your computer. The savings on transistors comes at a price: The development environment in general, and the compiler in particular, is more complicated than letting the CPU analyze the code during execution. The benefit, though, is that the compiler can take all the time it needs to determine the best way to tune the program, using the results of instrumented runs of the program to fine-tune everything and, arguably, generate big gains in performance and throughput.

Je ziet dus dat de compiler een belangrijkere rol gaat spelen bij deze architectuur. De keuze van de gebruikte compiler kan hierdoor weleens erg veel verschil gaan uitmaken.

Daarnaast is het misschien nog interessant om de runtimes te noemen.... Het Java Platform en Microsoft .NET kunnen uitermate goed profiteren van de overgang naar een nieuwe architectuur. De applicaties zijn daar namelijk 'gecompileerd' naar een soort intermediate language, die onafhankelijk is van een processor-architectuur. Just in time wordt dit gecompileerd door een compiler naar de architectuur waar de VM op draait. Als de just in time compiler in de Virual Machine geoptimaliseerd wordt voor het 64 bits platform profiteren gelijk alle applicaties die op deze VM draaien hiervan. Hierdoor kunnen alle Java en .NET applicaties volop profiteren van de nieuwe architectuur, zonder opnieuw gecompileerd te worden. Uiteraard voorkomt dit ook voor een groot deel een mogelijk chaos.

IBM heeft al een Java Virtual Machine ontwikkeld van de Itanium en ook Sun heeft nu JVMs die de architectuur van de Itanium benutten (zie het rijtje hier. Ik neem aan dat ook Microsoft hiermee bezig is, of dit al op de plank heeft liggen omdat dit natuurlijk ook zeer wenselijk is voor .NET.

[CyberSnooP]

Toch vraag ik me af of de bestaande Intermediate Languages van Java en .NET wel krachtig genoeg zijn straks optimaal gebruik te maken van o.a. EPIC. Ik gok namelijk dat de Virtual Machines helemaal niet zo heel veel vrijheid meer hebben omdat de ILs al redelijk specifiek zijn. Bij een hogere taal kan een compiler nog veel meer 'herschrijven' om het zo te optimaliseren.

Of zit ik er nu compleet naast?

[mbravenboer]

CyberSnooP: Of zit ik er nu compleet naast?

Ik begrijp je redenering, maar: ja .

.NET IL en Java Bytecode liggen allebei vlakbij resp. C# of Java. Compilatie van C# -> .NET IL of Java -> Java Bytecode is slechts een soort type-checking en met name in het geval van C# het verwijderen van wat suiker (wat ik zeker geen serieuze compilatie zou willen noemen). Zo laag is het niveau van deze intermediate representations dus niet en ze zijn zeker niet vergelijkbaar met echte assembly voor RISC of CISC. Het is meer een soort OO-assembly.

Er moet dus eigenlijk nog behoorlijk wat gecompileerd worden en dat is wel een probleem: ze hebben nog wel de vrijheid, maar hebben ze de tijd om die vrijheid goed te benutten? Zoals ik in mijn post zou hebben compilers bij IA64 een hele belangrijke rol en compilatie begint dus eigenlijk pas at runtime in een virtual machine als het Java Platform.

Omdat de compiler een belangrijke rol speelt, kost dat uiteraard ook tijd en met name op het Java Platform is die tijd er niet echt: de code wordt at runtime gecompileerd en je hebt dan maar beperkte tijd om hele intensieve optimalisaties uit te gaan voeren. Op .NET speelt dit probleem ook, maar met name in volgende releases van het framework toch minder dan bij het Java Platform omdat de native code voor assemblies dan gecached (opgeslagen) gaat worden. De JVM doet dit niet en zal dit waarschijnlijk ook niet zo snel gaan doen (maar komt wel met andere oplossingen).