Fujitsu lanserar världens snabbaste processor

Permalänk
Medlem

Så länge som majoriteten av alla PC kör Windows så kommer vi inte bli av med x86 arkitekturen.
Krävs nog en stor gemensam internationellt överenskommelse för att vi ska kunna byta arkitekturen och skriv helt nya program som vi använder idag.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Kilroy
En del bra svar som dock för det mesta går över huvudet på mig.

En annan stor invänding mot x86 är ju helt enkelt det att Intel har patent på det och alla som använder det måste betala licens på ett eller annat sätt.

Vet inte om det "behövs" egentligen. Endera Cyrix eller Rise (numera döda tillverkare av x86 kompatibla processorer) sades inte ha någon licens, minns inte vilken det var. Men det är ju inte säkert att det var så, dom kanske hade någon typ av hemligt avtal.
För övrigt har både Intel och AMD ett flertal patent som gäller x86...

Citat:

Kina håller ju på och utvecklar/lanserar en processor som ska konkurrera i konsumentmarknaden som inte bygger på x86 utan emulerar det.
Ska bli intressant att se hur den står sig.

Ja den baserar sig på MIPS vilket är en ganska trevlig grundarkitektur. Jag tvivlar att den kommer ha bra prestanda på x86 kod men som en möjlighet att köra vissa kritiska x86 program kan det nog fungera bra.

PBGP: Som jag har fattat det körs moderna BIOS i emuleringsläge under UEFI firmware, men om UEFI är bättre kan väl diskuteras...

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av PBGP
Man borde även ta och dumpa BIOS.. där kan vi tala om vårta!

På mina SGI-maskiner hamnar man i en grafisk miljö redan innan datorn börjat ladda operativsystemet och man kan i ett rudimentärt skal lista hårddiskar och kolla vilka partitioner som finns på dom. Alpha-maskinerna och VAX:arna jag har kan liknande saker och mer.

Nått motsvarande i PC-världen vore mumma.

Du verkar ha missat att MSI har dumpat BIOS och använder EFI i stället på några av sina Intel moderkort.
Men lösningen är långt ifrån perfekt. Tror industrin är lite för lata och inte vill samarbeta för att att ta fram en riktig öppen ersättare till BIOS. (Varför fixa något som redan fungerar?)

Tycker det är dax att kasta ut Floppy, IDE och BIOS från majoriteten av all moderkorten på marknaden! Kan spara den funktionaliteten till moderkort som redan har stöd för både DDR2 och DDR3 för all bakåtsträvare.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av boldtaar
Så länge som majoriteten av alla PC kör Windows så kommer vi inte bli av med x86 arkitekturen.
Krävs nog en stor gemensam internationellt överenskommelse för att vi ska kunna byta arkitekturen och skriv helt nya program som vi använder idag.

Vilken grej, starta om från början.
då borde konkuransen om OS kunna bli nått samtidigt som man får mycke bättre processorer.

Visa signatur

"I wrap my raskal two times, because i like it to be joyless and without sensation. Its a way to punishing supermodels."

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av boldtaar
Tycker det är dax att kasta ut Floppy, IDE och BIOS från majoriteten av all moderkorten på marknaden! Kan spara den funktionaliteten till moderkort som redan har stöd för både DDR2 och DDR3 för all bakåtsträvare.

Tror inte att majoriteten är berädda att byta till SCSI eller SAS hårddiskar så IDE kan få stanna

Visa signatur

Et ipsa scientia potestas est
(För övrigt anser jag att upplösningen 1366x768 ska dö)

Permalänk

Me Likey! Äntligen något som sticker ut ur mängden

Visa signatur

Gigabyte GA-MA770-DS3 | AMD Phenom II X3 720BE @ 3.5GHz | LeadTek GTX 260 | 4GB OCZ Reaper | Corsair 650W | 3DMARK06: 16723

Permalänk
Inaktiv
Citat:

Ursprungligen inskrivet av QuantoR
Tror inte att majoriteten är berädda att byta till SCSI eller SAS hårddiskar så IDE kan få stanna

Vad har SCSI och SAS att göra med konsumentdatorer?

Permalänk
Citat:

Ursprungligen inskrivet av QuantoR
Tror inte att majoriteten är berädda att byta till SCSI eller SAS hårddiskar så IDE kan få stanna

.... SATA/SATA2?

Visa signatur

ASUS P8Z68-V | Intel i7 2600K @4,5GHz | Corsair VENGEANCE 1600MHz 2x4GB | GTX570 DC2 | Systemdisk: WD Black 500GB 6.0Gbit + OCZ Agility 3 60GB med SRT | Dell U2711 H-IPS 2560x1440 | Corsair 550w| Antec P280 | ASUS Essence STX -> H/K 970 + Dynavoice M-65 & Denon AH-D1100 | Övrig hårddiskplats: 2xWD 1TB + WD 640Gb & 1TB Hitachi | Driving Force GT & Xbox 360 controller

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av SoulShatter
.... SATA/SATA2?

som är IDE?

Visa signatur

Et ipsa scientia potestas est
(För övrigt anser jag att upplösningen 1366x768 ska dö)

Permalänk
Avstängd

T.om INTEL anser att x86 är omodern och något nytt behövs. Annars skulle inte Itanium skapats. Varför skapa en ny CPU om man är nöjd med x86 man har? Alla säger att x86 är förlegad, vilket den är. Det finns MASSOR av gammal barlast. Om man kunde skippa barlasten skulle det gå toksnabbt. Men Intel har tokmycket pengar att satsa på forskning så x86 är mycket snabb ändå. Fatta hur snabbt det skulle gå om man kunde skippa barlasten.

Permalänk
Hedersmedlem

Med slänga IDE tror jag postaren menar att man ska nyttja AHCI istället.

Citat:

Ursprungligen inskrivet av Ragganof
Vilken grej, starta om från början.
då borde konkuransen om OS kunna bli nått samtidigt som man får mycke bättre processorer.

Man behöver inte ändra OS. Bara incitamentet fanns skulle Microsoft inte ha så svårt att porta windows.
I början när windows NT skapades så gjordes det inte på x86 för att programmerarna inte skulle kunna slinka in något x86 specifikt, sen portade dem det till x86 (mer korrekt att de bytte ut HAL).
Windows NT-serien har ju förutom x86 och x86-64 funnits på PowerPC, MIPS, DEC Alpha och IA64.

Kunde man bara få en modern arkitektur att emulera (inte något extra chip) x86 och x86-64 i tillräckligt bra hastighet så skulle man ju kunna köra någon hybridövergång.

Visa signatur

Forumregler | Feedbackforumet | Något som behöver modereras? Tryck på Anmäl inlägget och ge en anledning, någon moderator kommer granska inlägget och göra (egen) bedömning
"Fate. Protects fools, little children and ships named Enterprise." - Riker - ST:TNG

Permalänk
Citat:

Ursprungligen inskrivet av Megol0
x86 har variabel längd på intruktionerna. Det i sig själv behöver inte vara något större problem inom rimliga gränser men x86 är inte rimlig. För att kunna avkoda mer än en instruktion/klockcykel måste Intel och AMD använda sig av parallella avkodare.
-> "RISC" eller en intruktionsuppsättning med mer fix längd kan avkoda minst 2x - 8x mer instruktioner per klockcykel än x86 med motsvarande hårdvara.

x86 är tydligt stegvist utvecklad. Det finns massor av redundans i instruktionsuppsättningen, en massa saker är onödiga eller helt enkelt dyra implementationsmässigt.
-> En modern processor skulle kunna ha en renare instruktionsuppsättning och undvika arkitekturella "vårtor".

x86 har en del saker som kräver mycket mer hårdvara än en väldesignad arkitektur, t.ex. behövs mycket dyr (transistorintensiva, effektslukande) hårdvara för att minneshanteringen ska ske enligt specifikationen.
-> En modern processor skulle kunna undvika detta. T.ex. DEC Alpha hade inte samma problem.

Slutsats: en modern processor skulle kunna vara effektivare, kallare och snabbare än x86. Sannolikheten att någon skulle kunna konkurrera med Intel/AMD i fråga om processteknik och optimeringar är dock mycket osannolikt.

Väldigt bra argument! Trevligt att se!

Kodningen av x86 gör det ju lite småbökigt att avkoda, speciellt att ta reda på var nästa instruktion börjar innan man kodat av den föregående. Men detta är ju ett löst problem. Visst det går åt lite fler transistorer och det är ju illa om man försöker bygga en väldigt billig och strömsnål processor (mikrokontroller eller liknande) men i de enorma OoOE monster som vi använder idag är det nog en droppe i havet. En fördel med den variabla instruktionslängden är att x86 kod är väldigt snällt mot cache-minnen eftersom man helt enkelt får plats med fler instruktioner i samma mängd minne.

Angående nedsmutsning av opkod utrymmet så är ju det aldrig bra men mycket lull försvann med AMD64 (x86-64 eller vad nu folk vill kalla det) och det finns ju inget som säger att man inte kan göra fler sådana ändringar i framtida bakåtkompatibla x86 varianter och fasa ut det gamla precis som vi gör nu med 32 bitars kod. Onödiga och oanvända funktioner är väl inte heller nått som stjäl speciellt mycket resurser. Mycket av de problematiska "CISCiga" instruktioner som är kvar implementeras med mikrokod eftersom de inte behöver vara snabba, ingen modern kompilator genererar dem ändå.

Minnesmodellen (segmenteringen är ju i stort sett borta nu så det kan man ju inte klaga på längre) och framförallt ordningen tycker jag också kan ses som lite av en avvägning. x86 har väl en av de mer strikta ordningarna. Detta kan ju leda till att vissa optimeringar inte är tillåtna eftersom transaktioner måste ske i en given ordning. Detta skulle dock jag vilja se som en bra sak. Nu var det länge sen jag tittade på hur Alpha gjorde men jag har för mig att den fick göra lite som den ville. Den typen av arkitektur är givetvis väldigt rolig att implementera i hårdvara men också extremt spännande att skriva mjukvara för. Att behöva sätta minnesbarriärer runt nästan allt är ju inte så roligt.

Slutsats: x86 har en hel del nackdelar men jag tycker inte de är så stora som många verkar påstå. Mycket har hänt med arkitekturen under de år som gott och x86 har också en hel del bra saker som nästan alltid glöms bort.

Tyvärr lär vi precis som du säger inte få se en riktig RISC arkitektur ta upp kampen mot x86 då kostnaden för att spela i den här ligan är väldigt hög och Intels tillverkningsteknik slår alla på fingrarna än så länge. Kanske, kanske kan ARM med partners lansera nått intressant till slut och äta sig uppåt från inbyggda system och mobila plattformar. CortexA9 är hur som helst en väldigt intressant processor...

Visa signatur

/Hej hopp!

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av QuantoR
som är IDE?

IDE

SATA/SATA2(/SATA3)

Permalänk
Citat:

Ursprungligen inskrivet av Gräs-Mannen
Det var ett väldigt konstigt påstående. Det handlar om att x86 använts väldigt länge och känns förlegad. I artikeln hävdades det att den skyhöga prestandan kom av Sparc-arkitekturen, och då menade jag att det vore på tiden att även persondatorn fick sig en välbehövlig nystart med en ny och fräsh arkitektur. (Observera att ny och fräsh i detta avseende betyder allt som är yngre än 40 år. x86 introducerads -78 och hur mycket man än patchar något så når man ändå till slut en nivå när det inte längre går så bra.)

Att prestanda försprånget skulle ha speciellt mycket med Sparc vs x86 att göra har jag svårt att tro. Nu var det väldigt sparsmakat med information i artikeln men på siffrorna verkar det som de har redovisat maximal teoretisk flyttalsprestanda. Den siffran beror ju enbart på hur många exekveringsenheter man har och hur fort de går och är på det hela taget en rätt meningslös siffra som har väldigt lite med valet av arkitektur att göra egentligen. Speciellt när de hävdar att de är jättebra för att de är dubbelt så snabb när de har dubbelt så många kärnor. Det känns inte jättehäftigt.

Nu kan det mycke väl vara så att den här processorn kommer vara ett riktigt monster när den lanseras men den infromation som finns i artikeln säger väldigt lite om det. Och att dra några slutsatser om att Sparc arkitekturen ger dubbelt så snabba processorer som x86 från detta är lite som att säga att röda bussar är bättre än blå eftersom två röda bussar kan flytta dubbelt så mycket folk som en blå.

edit: För att förtydliga, ta kommande Larrabee som exempel. ~32 x86 baserade kärnor med 16 element breda vektorenheter => teoretisk prestanda i storleksordningen tio gånger mer än den processor som nämns i artikeln. Det säger fortfarande absolut ingenting om att x86 skulle vara bättre än Sparc eller tvärt om. Det visar bara på vilken marknad processorn riktar sig till och vilka designbeslut som tagits utifrån det.

Visa signatur

/Hej hopp!

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av XaaR
IDE
http://gallery.techarena.in/data/513/sata-ide_lg.jpg
SATA/SATA2(/SATA3)

SATA är en uppgradera verison av PATA (aka IDE)

Visa signatur

| Q9550 @ 3.8Ghz | Asus P5Q-PRO | AMD Radeon HD6950 2GB (Unlocked @ 865Mhz) | Corsair TX650W | Corsair XMS2 (2+1)x2GB | A-Data SP900 128GB| WD Caviar Blue 320GB | Fractal Design R3 | Noctua NH-U9B |

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Zee_13
SATA är en uppgradera verison av PATA (aka IDE)

Okej visst många kallar PATA hårddiskarna för IDE men det är en felaktig användning av IDE.

IDE står för Integrated Drive Electronics och som utvecklades till ATA (AT Attachment) alltså är en SATA hårddisk lika mycket IDE som en PATA. Skilladen ligger i om den är seriell eller parallel

Visa signatur

Et ipsa scientia potestas est
(För övrigt anser jag att upplösningen 1366x768 ska dö)

Permalänk
Medlem

Den processorn och quad sli gtx295 xxx

Visa signatur

Pentium 3.6 |8800gs | E2400hd | modded X-fi extreme music |Marantz sr 4010|Dynavoice m-85 ||~*

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av multimiffo
Väldigt bra argument! Trevligt att se!

Kodningen av x86 gör det ju lite småbökigt att avkoda, speciellt att ta reda på var nästa instruktion börjar innan man kodat av den föregående. Men detta är ju ett löst problem. Visst det går åt lite fler transistorer och det är ju illa om man försöker bygga en väldigt billig och strömsnål processor (mikrokontroller eller liknande) men i de enorma OoOE monster som vi använder idag är det nog en droppe i havet. En fördel med den variabla instruktionslängden är att x86 kod är väldigt snällt mot cache-minnen eftersom man helt enkelt får plats med fler instruktioner i samma mängd minne.

Det är ganska mycket mer än småbökigt Först måste man ha parallella längdekoders per läst byte (minst 32st för modern processor) som i sin tur dekodas av flera lager logik för att bestämma längd på ett fåtal instruktioner. Därefter lagras längdinformationen i intruktionscachen. Men det räcker tyvärr inte, den riktiga avkodningen kan vara riktigt klurig att få snabb eftersom x86 stöder s.k. prefixes: koder som finns framför en instruktion och kan ändra hur instruktionen ska hanteras. Det är hemskt komplext.
Har läst på ett flertal ställen att medellängd på en x86 instruktion idag är runt 4 bytes, samma som vanliga RISC instruktioner. Program optimerade för SSE är värre eftersom en enda instruktion kan vara 6byte lång.

Citat:

Angående nedsmutsning av opkod utrymmet så är ju det aldrig bra men mycket lull försvann med AMD64 (x86-64 eller vad nu folk vill kalla det) och det finns ju inget som säger att man inte kan göra fler sådana ändringar i framtida bakåtkompatibla x86 varianter och fasa ut det gamla precis som vi gör nu med 32 bitars kod. Onödiga och oanvända funktioner är väl inte heller nått som stjäl speciellt mycket resurser. Mycket av de problematiska "CISCiga" instruktioner som är kvar implementeras med mikrokod eftersom de inte behöver vara snabba, ingen modern kompilator genererar dem ändå.

Är faktiskt inte så mycket CISC aspekten som är problemet eftersom det hanteras med mikrokod precis som du säger. Däremot så kan man se att eftersom det finns så många sätt att göra olika saker så kan kompilatorerna inte välja rätt instruktionssekvenser för att få bra prestanda. Även så nya instruktioner som i SSE har ett flertal sätt att hantera vissa saker. Vissa sätt kan vara snabbare i vissa fall men det finns inte mycket dokumentation om detta och ingen garanti att samma regler gäller i framtiden.
AMD missade chansen att rensa upp, det enda dom gjorde var att ta bort en del av segmenthanteringen (tyvärr!) men ändå lämna kvar såpass mycket att hårdvaran inte kan snabbas upp märkbart.

Citat:

Minnesmodellen (segmenteringen är ju i stort sett borta nu så det kan man ju inte klaga på längre) och framförallt ordningen tycker jag också kan ses som lite av en avvägning. x86 har väl en av de mer strikta ordningarna. Detta kan ju leda till att vissa optimeringar inte är tillåtna eftersom transaktioner måste ske i en given ordning. Detta skulle dock jag vilja se som en bra sak. Nu var det länge sen jag tittade på hur Alpha gjorde men jag har för mig att den fick göra lite som den ville. Den typen av arkitektur är givetvis väldigt rolig att implementera i hårdvara men också extremt spännande att skriva mjukvara för. Att behöva sätta minnesbarriärer runt nästan allt är ju inte så roligt.

Segmenteringen har inte varit något att klaga på sen i386 tiden tycker jag.
Jepp minnesordningen är mycket strikt vilket underlättar en del multiprocessorsynkronisering men det begränsar även exekveringshastigheten en del. Alpha har en del nackdelar och problem men generellt sett kan dessa gömmas bakom standardkod

Citat:

Slutsats: x86 har en hel del nackdelar men jag tycker inte de är så stora som många verkar påstå. Mycket har hänt med arkitekturen under de år som gott och x86 har också en hel del bra saker som nästan alltid glöms bort.

Tyvärr lär vi precis som du säger inte få se en riktig RISC arkitektur ta upp kampen mot x86 då kostnaden för att spela i den här ligan är väldigt hög och Intels tillverkningsteknik slår alla på fingrarna än så länge. Kanske, kanske kan ARM med partners lansera nått intressant till slut och äta sig uppåt från inbyggda system och mobila plattformar. CortexA9 är hur som helst en väldigt intressant processor...

Ja det finns betydligt värre arkitekturer.
Jag skulle gärna vilja se en optimerad out-of-order 64bits ARM själv, men är väl inte riktigt det segment den processorn riktar sig mot.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av boldtaar
Så länge som majoriteten av alla PC kör Windows så kommer vi inte bli av med x86 arkitekturen.
Krävs nog en stor gemensam internationellt överenskommelse för att vi ska kunna byta arkitekturen och skriv helt nya program som vi använder idag.

Fanns det inte rykte om att Windows 7 skulle komma till ARM processorerna eller var det bara Warren East's våta dröm??

Permalänk
Medlem

128 GFLOPS?
Pfft. Mycket för en CPU kanske, men inte så mycket jämfört med en GPU. Ett HD 4890 har t.ex. 1.36 TFLOPS, d.v.s. drygt 10 gånger högre.

Permalänk
Trollfabrik 🫶🏻

x86 och alla dess "expansioner" tar en sju-jävla massa die-utrymme på dagens Intel/AMD processorer kan vi ju lägga till, så ja en nystart skulle vara att föredra.

Visa signatur

Kontaktas enklast via PM. Önskas svar i forumet citera mina inlägg eller pinga @Jacob. Finns även på Twitter.

"Science and technology have progressed to the point where what we build is only constrained by the limits of our own imaginations." – Justin R. Rattner

Permalänk
Citat:

Ursprungligen inskrivet av Megol0
Det är ganska mycket mer än småbökigt Först måste man ha parallella längdekoders per läst byte (minst 32st för modern processor) som i sin tur dekodas av flera lager logik för att bestämma längd på ett fåtal instruktioner. Därefter lagras längdinformationen i intruktionscachen. Men det räcker tyvärr inte, den riktiga avkodningen kan vara riktigt klurig att få snabb eftersom x86 stöder s.k. prefixes: koder som finns framför en instruktion och kan ändra hur instruktionen ska hanteras. Det är hemskt komplext.
Har läst på ett flertal ställen att medellängd på en x86 instruktion idag är runt 4 bytes, samma som vanliga RISC instruktioner. Program optimerade för SSE är värre eftersom en enda instruktion kan vara 6byte lång.

Ahh... det där med prefix hade jag glömt bort. Så fort man läser en spec för nästa genertions SIMD instruktioner så är det nya prefix hit och dit. Det är ju kanske inte så elegant alla gånger...

Jag trodde faktiskt att x86 låg lite under 4 byte/instr i medel, så går det när man inte har koll på läget... :P. En annan intressant faktor är ju hur "kraftfull" varje instruktion är. Jag tänker på att x86 tex. tillåter minnesoperander hit och dit och på så sätt kan koda mer arbete i en och samma instruktion. Det kan ju ge en viss skillnad i antalet instruktioner som krävs för varje given uppgift. Jag har aldrig sett siffror på hur stor inverkan det har så om du vet på ett ungefär hur stor skillnad det ger gämfört mot en RISC arkitektur så vore det roligt att veta.

Citat:

Är faktiskt inte så mycket CISC aspekten som är problemet eftersom det hanteras med mikrokod precis som du säger. Däremot så kan man se att eftersom det finns så många sätt att göra olika saker så kan kompilatorerna inte välja rätt instruktionssekvenser för att få bra prestanda. Även så nya instruktioner som i SSE har ett flertal sätt att hantera vissa saker. Vissa sätt kan vara snabbare i vissa fall men det finns inte mycket dokumentation om detta och ingen garanti att samma regler gäller i framtiden.
AMD missade chansen att rensa upp, det enda dom gjorde var att ta bort en del av segmenthanteringen (tyvärr!) men ändå lämna kvar såpass mycket att hårdvaran inte kan snabbas upp märkbart.

Intel har ju ett väldigt kompetent kompilator team så man tycker ju att de borde driva arkitekturen att blir så kompilatorvänlig som möjligt.

Jag tror inte AMD vågade rensa för mycket. De visste ju inte om det skulle bli 3DNow-fiasko av det hela. Därför tror jag inte de ville gör för radikala ändringar och tvingas lägga allt för mycket resurser på att designa den nya standarden och implementationen.

Citat:

Ja det finns betydligt värre arkitekturer.
Jag skulle gärna vilja se en optimerad out-of-order 64bits ARM själv, men är väl inte riktigt det segment den processorn riktar sig mot.

Jag tycker det pekar i rätt riktning. Det kanske tar ett tag innan det finns 64-bitars ARM implementationer men vi har ju redan fyrkärniga out-of-order varianter. Med lite tur så kanske ARM är med i leken om 10 år eller så.

Visa signatur

/Hej hopp!

Permalänk
Medlem

pris?

Visa signatur

"overclocked budget-monster":amd athlonX2 5200+@ 3.2 ghz -:- k9a2vm -:- 2600pro 512mb (core:850 mem:580) -:- 2gb crosair...

Permalänk
Medlem

Ser man på öppna system som Linux, då är det väl inga problem med en ny arkitektur? Det enda som behövs är väl en kompilator som klarar den nya arkitekturen?

Visa signatur

Archlinux, Sway och Rust, vad mer behövs?

Permalänk
Medlem

För PC så finns det ingen anledning att byta. Kompabilitet är oerhört mycket viktigare än prestandaökning i vissa specialfall. CPU:er för PC kommer att fortsätta utvecklas långsamt. Helt enkelt för att det inte finns något behov av köra 6 core eller mer i Office, Internet och de flesta företagsapplikationer.

Den enda anledningen till ett skifte enligt mig skulle vara en öppen standard. Jag menar så vi kom ifrån att Intel sitter med sitt feta arsle på x86 licenser.

Intels Larrabee eller andra GPGPU lösningar kommer att vara framtiden för de applikationer som behöver extrem FP kapacitet. Helt enkelt för att det är då valfritt att stoppa i den om man behöver den kapaciteten.

Kapaciteten i Larrabee är oerhört mycket högre än denna kommande CPU från Fujitsu. Precis som Hummus nämnde så kommer antagligen Larrabee ge över 10-15 ggr högre GFLOPS resultat.

Permalänk
Citat:

Ursprungligen inskrivet av Gräs-Mannen
Ser man på öppna system som Linux, då är det väl inga problem med en ny arkitektur? Det enda som behövs är väl en kompilator som klarar den nya arkitekturen?

Det är lite mer komplicerat än så. Det beror lite på hur passa lika arkitekturerna är. Om de är väldigt olika kan det behövas en massa jobb med att uppdatera källkoden för att få det att fungera.

Man kan ju också göra som Apple gjorde när de bytte till x86, översätta maskinkoden från PowerPC till x86. De hade dock en liten fördel eftersom de gick från en "enklare" och mindre strikt arkitektur till x86. Jag gissar på att det är betydligt lättara att gå åt det hållet än att göra tvärt om. Dock så förlorar man ju alltid prestanda vid alla typer av emulering och översättnings tekniker så att kompilera om programmen är ju önskvärt ur prestanda synpunkt.

Visa signatur

/Hej hopp!

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av multimiffo
Intel har ju ett väldigt kompetent kompilator team så man tycker ju att de borde driva arkitekturen att blir så kompilatorvänlig som möjligt.

Jag tror vagnen drar åsnan i ditt resonemang där... Det är nog snarare så att arkitekturen gör att de _måste_ ha ett väldigt kompetent kompilatorteam.

Visa signatur

Gammal och gnällig

Permalänk
Medlem

Någon här som har varit i kontakt med moderna sparc maskinner?
idg har gjort ett försmak test
http://www.idg.se/2.1085/1.213631/en-forsmak-av-framtidens-pr...

De tar den nästan som det skulle vara vilken alternativ server som helst. Men i mina ögon låter det mer som ett alternativ till IBMs stordatorer . Där marknaden i Sverige ligger på 1-4 burkar per år (om ens det) :-/

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av Hummus
128 GFLOPS?
Pfft. Mycket för en CPU kanske, men inte så mycket jämfört med en GPU. Ett HD 4890 har t.ex. 1.36 TFLOPS, d.v.s. drygt 10 gånger högre.

En teoretisk siffra som kortet aldrig kommer nära. Försök nu dessutom komma upp i den prestandan med 8 beräkningsenheter istället för 800.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Meto
Någon här som har varit i kontakt med moderna sparc maskinner?
idg har gjort ett försmak test
http://www.idg.se/2.1085/1.213631/en-forsmak-av-framtidens-pr...

De tar den nästan som det skulle vara vilken alternativ server som helst. Men i mina ögon låter det mer som ett alternativ till IBMs stordatorer . Där marknaden i Sverige ligger på 1-4 burkar per år (om ens det) :-/

360 000 kronor, som hittat

Visa signatur

Et ipsa scientia potestas est
(För övrigt anser jag att upplösningen 1366x768 ska dö)