mboost-dp1
morphos
larsp (1) skrev:Det kan vel også køre på intel chips, der jo understøtter AMD64, eller?
Ja, AMD64 er det som Microsoft kalder x64, så hvis den kan køre Windows 10 x64 så kan den også køre dette OS (med forbehold for at driverudvalget nok bliver ret begrænset).
#Itanium
Itanium (IA-64) var vel det mest teknisk lovende design.
x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.
VLIW ideen er genial.
Jeg vil ikke mene at x86-64 har udkonkurreret Itanium, Power, SPARC og Alpha fordi den har et bedre design.
x86-64 har vundet fordi den kunne køre x86 applikationer og dermed blev solgt i hundredevis af millioner af eksemplarer og dermed tjente så mange penge at der kunne investeres mere i design udvikling og fabriks udvikling.
Itanium (IA-64) var vel det mest teknisk lovende design.
x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.
VLIW ideen er genial.
Jeg vil ikke mene at x86-64 har udkonkurreret Itanium, Power, SPARC og Alpha fordi den har et bedre design.
x86-64 har vundet fordi den kunne køre x86 applikationer og dermed blev solgt i hundredevis af millioner af eksemplarer og dermed tjente så mange penge at der kunne investeres mere i design udvikling og fabriks udvikling.
arne_v (5) skrev:Itanium (IA-64) var vel det mest teknisk lovende design.
x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.
VLIW ideen er genial.
Det er mit indtryk at VLIW ikke er så genialt igen, for det lægger hele optimiseringsopgaven over på compileren hvor det har vist sig svært at lave kode der udnytter resourcerne optimalt. Dertil kan compileren kun lave ét bud på den optimale organisering af instruktionerne. Alt der sker i runtime kan jo ikke tages med i overvejelserne.
Fylder IA-64 kode ikke også ekstremt meget? Det straffer også performance.
Nu hvor transistorer og logik er blevet så billig, er det nok ikke så dumt at smide så meget som mulig af optimiseringsopgaven ned i CPUen, hvor der kan arbejdes med et midlertidigt oversat instruksionsset, og det er jo også det der har vist sig den vindende formel inden for x64 og ARM.
Jeg er glad for at Bigfoot og Co endelig valgte at se nærmere på AMD64
Det var der ellers ikke stemning for i lange tider :)
Hvor dejlig 68k og PPC end er så er det døde platforme men rart at de stadig kan køres via indbyggede emulatorer
Det var der ellers ikke stemning for i lange tider :)
Hvor dejlig 68k og PPC end er så er det døde platforme men rart at de stadig kan køres via indbyggede emulatorer
larsp (7) skrev:arne_v (5) skrev:Itanium (IA-64) var vel det mest teknisk lovende design.
x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.
VLIW ideen er genial.
Det er mit indtryk at VLIW ikke er så genialt igen, for det lægger hele optimiseringsopgaven over på compileren hvor det har vist sig svært at lave kode der udnytter resourcerne optimalt.
Den forklaring er ret gængs.
Men kan det virkeligt passe at en compiler med næsten uendelig tid til at optimere, adgang til hele koden og mulighed for at løbe gennem koden mange gange er dårligere til at optimere end en CPU som kender nogle få udførte instruktioner og de få næste instruktioner og hvor hvert et nanosekund tæller?
Det synes jeg ikke lyder logisk.
Jeg mener også at benchmarks viste at ved samme antal ekerner of samme frekvens var Itanium langt hurtigere end x86-64. Men Itanium sakkede bagud i antal kerner og frekvens.
larsp (7) skrev:
Dertil kan compileren kun lave ét bud på den optimale organisering af instruktionerne. Alt der sker i runtime kan jo ikke tages med i overvejelserne.
Ifølge den logik bør fortolkning eller ihvertfald JIT kompilering være hurtigere end AOT kompilering.
Selvom JIT kompilering er ret god idag, så er det vel de færreste som ser det som hurtigere end AOT kompilering.
arne_v (11) skrev:
Men Itanium sakkede bagud i antal kerner og frekvens.
Itanium:
2001: 1 core, 0.8 GHz
2006: 2 cores, 1.6 GHz
2010: 4 cores, 1.7 GHz
2012: 8 cores, 2.5 GHz
Xeon:
2001 (Foster): 1 core, 2.0 GHz
2005 (Paxville): 2 cores, 2.8 GHz
2006 (Clovertown): 4 cores, 2.7 GHz
2008 (Dunnington): 6 cores, 2.7 GHz
2010 (Beckton): 8 cores, 2.7 GHz
2011 (Westmere): 10 cores, 2.7 GHz
2012 (Ivy Bridge): 12 cores, 3.7 GHz
2014 (Haswell) : 18 cores, 3.7 GHz
2017 (Skylake) : 28 cores, 3.9 GHz
larsp (7) skrev:
Fylder IA-64 kode ikke også ekstremt meget?
Fylder mere.
32 bit CISC typisk:
instruktion: variabel længde
adresse: 4 bytes
integer data: 4 bytes
floating point data: 8 bytes
64 bit CISC typisk:
instruktion: variabel længde
adresse: 8 bytes
integer data: 4 bytes
floating point data: 8 bytes
64 bit RISC typisk:
instruktion: 4 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes
64 bit VLIW typisk:
instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes
Tilfældigt eksempel.
unzip.exe version 5.52:
VAX (32 bit CISC) - 112 KB
Alpha (64 bit RISC) - 160 KB
Itanium (64 bit VLIW) - 400 KB
Det er en pæn stor forskel.
Måske derfor at Itanium kom med pænt store cache.
De sidste modeller (2012 og 2017) kom med:
512 KB L2 I cache per core
256 KB L2 D cache per core
32 MB L3 cache per socket
Xeon Ivy Bridge fra 2012 kom med 256 KB L2 per core og 8 MB L3 per socket.
arne_v (13) skrev:64 bit VLIW typisk:
instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes
16 bytes bare for instruktion(er) Det er jo helt vildt. Jeg tror at det ofte slet ikke kan lade sig gøre at fylde kød på de kæmpe instruktioner, selv med en overnaturlig god compiler. Der er ingen tvivl om at konceptet vil være godt til store matrixberegninger og lignende, men f.eks. små dumme loops med små integers, som jo er ret normalt i kode, må blive straffet.
Det viser sig jo også ved at unzip.exe bliver så bloated. Al den plads der ikke bruges i binarien er vel ækvivalent med units i processoren der ikke laver noget, da processoren ikke kan lave dynamisk reschedulering af operationer osv til at fylde de tomme units ud.
Itanium arkitekturen synes mere egnet til GPU-agtig processering end til general purpose kode.
kblood (10) skrev:#8 PPC Amigaer har altid virker underligt for mig... de skulle netop stadig bruge emulator for at køre 68k software. Så hvorfor ikke bare skifte til x86 / x64? Tog dem godt nok lang tid... så håber jeg bare det også sker med AmigaOS4
Jeg tror bare det handler om to ting. På det tidspunkt at man skiftede til PPC, var der alligevel så meget software, som kørte på PPC i forvejen. Og hardware i form af acceleratorer. Til sidst er der jo det fakta, at Amiga verdenen er utrolig konservativ i mange henseender.
Tænk på hvor mange der stadig er imod ARM løsnings snakken.
Jeg mener at både ARM og x86 (64bit) er vejen frem. ARM til små opgaver så som simple spil og tekst behandling og såen. Hvorimod x86 løsning og geforce eller radeon til fotografen og animatoren (3D modellering og video redigering)
Retro (15) skrev:Ohh yes Amiga clone goes x64
Aros og aeros har længe kørt på x64
Ligesom amigaxl, amithlon og amiga forever
Mens morphos og amigaos kører ppc
Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)
CBM (17) skrev:
Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)
Bestemt.... Omend de stadig kun har driver understøttelse af få typer grafikkort så som Radeon, så er det muskler der mangles. Jeg ville også syntes det ville være rigtig godt, hvis de også portede til ARM. Jeg snakker ikke om at de skal skifte hele hardware platformen ud, men kun skifte til et par specifikke CPU og Chipset platforme.
Det er muskler der mangles, ikke så meget grafik accelration som sådan.
brostenen (18) skrev:CBM (17) skrev:
Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)
Bestemt.... Omend de stadig kun har driver understøttelse af få typer grafikkort så som Radeon, så er det muskler der mangles. Jeg ville også syntes det ville være rigtig godt, hvis de også portede til ARM. Jeg snakker ikke om at de skal skifte hele hardware platformen ud, men kun skifte til et par specifikke CPU og Chipset platforme.
Det er muskler der mangles, ikke så meget grafik accelration som sådan.
Jep men måske kan de blive inspireret af aeros og Linux driver wrapping
larsp (14) skrev:arne_v (13) skrev:64 bit VLIW typisk:
instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes
16 bytes bare for instruktion(er) Det er jo helt vildt.
Der er jo nok en grund til at det heder VLIW (Very Long Instruction Word) og ikke RSIW (Rather Short Instruction Word).
:-)
De 128 bits består af 3 instruktioner som hver fylder 41 bit og 5 bit med indholdsbeskrivelse.
larsp (14) skrev:
Jeg tror at det ofte slet ikke kan lade sig gøre at fylde kød på de kæmpe instruktioner, selv med en overnaturlig god compiler. Der er ingen tvivl om at konceptet vil være godt til store matrixberegninger og lignende, men f.eks. små dumme loops med små integers, som jo er ret normalt i kode, må blive straffet.
...
Itanium arkitekturen synes mere egnet til GPU-agtig processering end til general purpose kode.
Itanium er helt klart designet til parallel eksekvering.
Men den er meget forskellig fra GPU og vector/matrix beregninger.
De er SIMD orienteret.
Itanium er MIMD orienteret.
Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).
Så den kan faktisk udføre meget forskellige ting parallelt.
Hvis der ikke er data dependencies.
Men det er nemmere at undgå data dependencies i Itanium end i x86 / x86-64.
128 styk 64 bit integer registre + 128 styk 82 bit FP registre giver mulighed for at have en masse forskellige temporære værdier.
Rent teknisk er de 128 fordelt på 32 som bruges globalt og 96 som bruges til register windowing for argumenter. D.v.s. at man har et antal registre med de argumenter man er kaldt med, 32 registre til almindelig brug og et antal registre til argumenter man kalder med. Stadig meget pænt.
Jeg kan se noget ide i det.
Men hvis det er den halve frekvens og det halve antal kerner og den firdobbelte pris af x86-64, så falmer ideen meget hurtigt.
#21
Der er selvfølgelig også visse problemer med det niveau af parallelisme og antal registre.
Memory konsistens er noget mere tricky end med x86-64.
Microsoft fik et lille problem da de skulle tilføje Itanium support i .NET i 2.0.
Visse konstruktioner som altid ville virke på x86-64 ville ikke altid virke på IA-64.
Så de var nødt til at definere en .NET memory model, som udviklerne kunne programmere ud fra. Og det var jo i sagens natur nødt til at være en forsigtig model som kunne implementeres på alle platforme.
https://docs.microsoft.com/en-us/archive/msdn-maga...
har en lang forklaring.
Der er selvfølgelig også visse problemer med det niveau af parallelisme og antal registre.
Memory konsistens er noget mere tricky end med x86-64.
Microsoft fik et lille problem da de skulle tilføje Itanium support i .NET i 2.0.
Visse konstruktioner som altid ville virke på x86-64 ville ikke altid virke på IA-64.
Så de var nødt til at definere en .NET memory model, som udviklerne kunne programmere ud fra. Og det var jo i sagens natur nødt til at være en forsigtig model som kunne implementeres på alle platforme.
https://docs.microsoft.com/en-us/archive/msdn-maga...
har en lang forklaring.
arne_v (21) skrev:Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).
Så den kan faktisk udføre meget forskellige ting parallelt.
Hvis der ikke er data dependencies.
Det lyder som om branching og looping kan kaste grus i maskineriet. Hvis det ene eksekverings spor har brug for en anden execution path end de andre kan de jo ikke køre sideløbende.
Men IA-64 er bestemt en interessant case at lære om. Det kan vel minde lidt om PS3 og dens cell processor. Masser af teoretisk power, men ekstremt svært at udnytte det fulde potentiale i praksis. Hvorimod x86/arm/... kan ses som general purpose / brute force monsteret der bare æder sig igennem hvad som helst med glubende appetit.
#24 Fra linket.. har ikke læst det hele, men denne springer i øjnene:
C programmørens kommentar, _flag skal deklareres volatile!!! ellers skal der gives dummekage ;) Nå, men, gad vide om der overhovedet findes volatile i C#
class Test
{
private bool _flag = true;
public void Run()
{
// Set _flag to false on another thread
new Thread(() => { _flag = false; }).Start();
// Poll the _flag field until it is set to false
while (_flag) ;
// The loop might never terminate!
}
}
In this case, the .NET 4.5 JIT compiler might rewrite the loop like this:
if (_flag) { while (true); }
C programmørens kommentar, _flag skal deklareres volatile!!! ellers skal der gives dummekage ;) Nå, men, gad vide om der overhovedet findes volatile i C#
#26
De næste linier siger:
så ja - C# har volatile.
De næste linier siger:
In the single-threaded case, this transformation is entirely legal and, in general, hoisting a read out of a loop is an excellent optimization. However, if the _flag is set to false on another thread, the optimization can cause a hang.
Note that if the _flag field were volatile, the JIT compiler would not hoist the read out of the loop. (See the “Polling Loop” section in the December article for a more detailed explanation of this pattern.)
så ja - C# har volatile.
#27
Det er værd at bemærke at så vidt jeg ved (med mit begrænsede kendskab til memory modeller) så:
* har C volatile samme semantik som Java pre-1.5 volatile d.v.s. at de sikrer konsistent adgang til variablen der er volatile
* har C# volatile samme semantik som Java 1.5 og nyere volatile d.v.s som ovenstående plus etablerer en happens-before order
Det er værd at bemærke at så vidt jeg ved (med mit begrænsede kendskab til memory modeller) så:
* har C volatile samme semantik som Java pre-1.5 volatile d.v.s. at de sikrer konsistent adgang til variablen der er volatile
* har C# volatile samme semantik som Java 1.5 og nyere volatile d.v.s som ovenstående plus etablerer en happens-before order
larsp (25) skrev:arne_v (21) skrev:Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).
Så den kan faktisk udføre meget forskellige ting parallelt.
Hvis der ikke er data dependencies.
Det lyder som om branching og looping kan kaste grus i maskineriet. Hvis det ene eksekverings spor har brug for en anden execution path end de andre kan de jo ikke køre sideløbende.
Det er vel næsten perfekt til et for loop.
for(i = 0; i < n; i++) {
c[i] = a[i] + b[i];
}
er for hvert gennemløb:
* beregn address a[i]
* beregn address b[i]
* beregn address c[i]
* hent a[i]
* hent b[i]
* gem c[i]
* plus
* forøg i
* sammenlign i og n og hop hvis ikke mindre
* hop op
=
2 load
1 store
4 integer arithmetic
1 FP arithmentic
2 branch
Hvis compileren kan arrangere det rigtigt, så kan del vel parelleliseres til kun 2 clock cycles.
Itanium bruger speculative/predictive execution ligesom x86-64, så et forkert gæt koster for dem begge, omend det nok koster mere for Itanium da der formentligt er mere in fligth som er spildt.
Men for et loop som ovenfor er det n rigtige gæt og 1 forkert gæt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund