Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties
Bron: EETimes

De EETimes meldt dat Sun tijdens de Async 2001 conferentie heeft geprobeerd ontwikkelaars ervan te overtuigen dan chips die niet met gezette timings werken vele malen sneller kunnen zijn dat chips die zich aan een strak tijdschema moeten houden, zoals alle chips die nu op te markt zijn. Het bedrijf heeft een proto-type van de 'FleetZero', een chip die pas over vijf jaar af zal zijn, maar nu al geschikt is om te demonstreren hoe belangrijk asynchrone verwerking kan zijn. Men roept al jaren dat er een eind moet komen aan de mogelijkheden om kloksnelheid verder op te voeren, maar keer op keer worden de grenzen verbroken. Toch denkt men dat het uiteindelijk onvermijdelijk is om over te stappen op een ander soort chips.

Volgens de naar buiten gebrachte documenten verspillen de huidige chips 95% van hun kracht omdat alles perfect synchroon moet blijven. De FleetZero maakt gebruik van een veld vol losse processor-cellen die met een netwerk van korte draadjes aan elkaar zijn verbonden. Het is de taak van de software om de communicatie tussen de onderdelen te regelen, niet die van de processorontwerper en een externe systeemklok:

FleetZero replaces synchronous arithmetic operations with data-movement operations among asynchronous processor blocks called ships. In place of synchronous chips' instructions are binary codes that specify the routes data items need to take among the processor blocks to accomplish the same tasks that synchronous chips perform via sequential operations. Software compilers would manage on-chip communications, routing data among the asynchronous blocks.

Sun Labs claims its processing ships will scale up gracefully to "flotillas" of systems-on-chip. Making data communications — not logical operations — the core problem of computing will lower costs, quicken overall execution speeds and cut power consumption compared with synchronous designs, Sutherland contends.

"Communications on a chip has become the most important chip-design problem," he said. "Not only do the wires by which chips communicate their data occupy more space than the transistors, but they are also slower and consume more power. FleetZero puts the compiler writer in charge of the wires, making much better use of computing resources."
Moderatie-faq Wijzig weergave

Reacties (36)

De FleetZero maakt gebruik van een veld vol losse processor-cellen die met een netwerk van korte draadjes aan elkaar zijn verbonden. Het is de taak van de software om de communicatie tussen de onderdelen te regelen, niet die van de processorontwerper en een externe systeemklok
Doet mij denken aan het Centraal Zenuwstelsel (oftewel de Hersenen), dat ook uit losse 'proces'-units bestaat. Ook wordt er van buitenaf (de software) geleerd hoe er met informatie omgegaan moeten worden, zo ook bij hersenen, die getraind worden (op school bv) om goed te functioneren. Het staat dus niet van te voren vast wat de capaciteiten van CPU zijn (net zoals bij de hersenen). Dit heeft dus als gevolg dat Sun/Digital-Alpha/Intel/AMD/en de rest, zich op een gegeven moment (wanneer de 'CPU' gereed is) voornamelijk met software gaan bezig houden om te optimaliseren. Misschien een rare vergelijking, maar zoiets dergelijks vindt ook al jaren in de game-console-industrie plaats => men ontwikkelt bv een Playstation-console en begint dan aan de optimalisatie van de software, met als gevolg dat nieuwe games er veel beter uitzien als oudere met dezelfde console.
Oftewel: er komt een mooie toekomst ons tegemoet, waarin je niet verplicht bent om iedere 2 jaar je pc compleet aan te passen om de nieuwste software te kunnen gebruiken.
Oftewel: er komt een mooie toekomst ons tegemoet, waarin je niet verplicht bent om iedere 2 jaar je pc compleet aan te passen om de nieuwste software te kunnen gebruiken.
Dat zal denk ik nog wel flink tegenvallen. Aangezien ze je niet steeds weer nieuwe hardware kunnen gaan verkopen, zullen ze je wel laten betalen voor die software updates...

Wel stoer... cdtje d'r in (als dan de cd nog bestaat ;)) ff updaten en je compu is bv. 4 keer zo snel :P
Leuk, die vergelijking met het centraal zenuwstelsel. De overeenkomsten zijn mij ook al vaker opgevallen.

Het lijkt natuurlijk ook een beetje op een technische oplossing die er al lang is, want feitelijk is dit dus een computernetwerk.
In de grotere bedrijven en universiteiten worden computernetwerken gebruikt, waarbij verschillende computers verschillende taken uitvoeren. Eigenlijk ben je zo'n netwerk nu aan het downscalen naar je processor en zo krijgen verschillende onderdelen binnen de processor een aparte functie met een apart adres.
Dus i.p.v. dat je iets uitrekent en er vervolgens mee verder gaat, gaat het met zo'n processor anders: ik moet een floating-point berekening doen, dat stuur ik over de "processor-bus" naar mijn floating-point unit en intussen ga ik even iets anders doen. Als het resultaat terugkomt, dan ga ik weer verder waar ik mee bezig was.

Nog mooier zou het zijn als het hierarchisch nog een stapje hoger gaat: verschillende processoreenheden met een dedicated taak: dan kun je gewoon een complexe opdracht of een clustertje instructies naar een onderdeel van de processor sturen, bijvoorbeeld: ik heb een zipbestand, daar staat het, dat (daarvoor geoptimaliseerde) stuk van de processor moet die Huffman-code maar eens gaan zitten uitrekenen. Ik hoor het wel als het klaar is...

Een interessant idee, dus, dat nog voor veel doorbraken (in efficiency) kan zorgen...
edit:

netwerkproblemen -> dubbelpost (sorry)
Het zat er natuurlijk aan te komen, de fysieke grens van de huidige chips is dan nu toch bijna echt bereikt.
Volgens de naar buiten gebrachte documenten verspillen de huidige chips 95% van hun kracht omdat alles perfect synchroon moet blijven.
Wat voor zin heeft het een nog snellere CPU te hebben als je geheugenbandbreedte nog steeds te klein is?

edit:
typo's
Dat ligt maar net aan de toepassing. Geheugen is inderdaad altijd een bottleneck, maar bijna nooit dé bottleneck. Anders zou niemand een nieuwe processor kopen tot er PC5000 RAM is.
het gaat hier om een cpu neit om geheugen
De software regelt de CPU helemaal? Dus een kleine patch en je hebt al een nieuwe revisie? Denk niet dat ze hiermee blij zullen zijn. Dan zijn er in principie geen nieuwe chips meer nodig. Of heb ik dit mis??
Je hebt het een beetje mis. Met dat de software alles regelt wordt hier bedoeld dat de software de verschillende delen van de processor moet aansturen. Wat er nu gebeurt is dat de software tegen de CPU zegt "voer dit rijtje instructies uit", en dat de CPU die dan in een handige volgorde uitvoert.

Bij deze CPU's zou de compiler de commando's in de goeie volgorde moeten zetten, zodat ze optimaal snel verwerkt kunnen worden. Als je dan dus een betere compiler hebt, kan je je software opnieuw compileren en wordt die dus sneller, omdat de processor beter wordt aangestuurd.

Het is dus niet zo dat je een compleet snellere processor kunt krijgen door je software te upgraden, maar wel dat-ie efficienter gebruikt wordt. Hetzelfde zie je al een beetje bij de P4, er zijn nog weinig programma's voor geoptimaliseerd. Bij deze dingen van Sun zou dat effect vele malen groter zijn.
Dit is wel heel erg interessant, maar als we met het sybchroon houden 95% verspillen, waarom is men hier dan niet eerder aan begonnen?... Ik denk omdat het gewoon heel erg moeilijk is om chips die via dat mechanisme werken te ontwerpen en te fabriceren... Maar ik ben zeker benieuwd wat het resultaat gaat worden...
Ik denk dat het gewoon een kwestie is van voortschrijdend inzicht, en dat de ontwerpers eerst gewoon nog niet zover doordachten; los dus van technische moeilijkheid of financiele middelen.

Je kunt het denk ik analoog zien aan objectgeoriënteerd programmeren. Het duurde een hele tijd (tot 1967 :)) voordat ontwerpers van programmeertalen die stap vooruit maakten vanaf het procedurele ontwikkelen.
Ik denk omdat het gewoon heel erg moeilijk is om chips die via dat mechanisme werken te ontwerpen en te fabriceren... Maar ik ben zeker benieuwd wat het resultaat gaat worden...
Daar ligt het probleem nu nog niet zo volgens mij.
Want het is hun probleem niet hoe ze degelijk te laten werken.
Dat moet de programmeur maar doen. Of met een goeie compiler die zelf een goed inzicht heeft en zo de chips kan aansturen.
Dat zelf door de programmeur laten doen kan voor sommige dingen handig zijn. Als het echt op PURE snelheid aankomt. Maar anders is dat niet te doen.

Je mag anders al eens beginnen met de i686 te assembler te leren :)
niet zo leuk en TIJDROVEND :(<div class=r>[Reaktie gewijzigd door [p]redator]</div><!-- end -->
Ik denk dat het gewoon een kwestie is van voortschrijdend inzicht, en dat de ontwerpers eerst gewoon nog niet zover doordachten; los dus van technische moeilijkheid of financiele middelen.
Nope, deze techniek is al heel lang geleden bedacht en ook wel eens gebruikt in een ver verleden d8 ik.
Want het is hun probleem niet hoe ze degelijk te laten werken.
Zoals ik al zei, het idee was er altijd al, alleen bij complexe processoren is dit ongeloofelijk ingewikkeld, want elk deel van de processor, moet weten wanneer de vorige 'unit' klaar is met zijn berekening, anders gaat ie rekenen met data die niet klopt (bijvoorbeeld van een eerdere berekening), dit is dus wel degelijk erg ingewikkeld.
In de C't stond hier 2 jaar geleden ofzo ook een artikel over in.
Dit zou inderdaad een geweldige stap vooruit kunnen zijn. Het geeft je als programmeur een ongekende hoeveelheid controle over hoe je de computer gebruikt. Het optimaliseren van je code wordt dan een van de belangrijkste dingen om de performance omhoog te halen. Buiten dat is het natuurlijk heel mooi dat zo het stroomgebruik behoorlijk verminderd kan worden.
<font color=#786562>* xipetotec</font>
En juist DAT vind ik een beetje het enge eraan... Je kunt nu al zoveel verkl#ten als je een slechte C++ programmeur bent (of juist een goede 't is maar hoe je het bekijkt }> ), kun je nagaan wat er dan allemaal mis kan gaan...
Dit had ik al eerder gelezen in een C't..dus na wat speur werk kwam ik uit in november 1999, daar hadden ze het over de Amulet2e en TITAC-2 en ook wat vergelijkingen ...de amulet2e is een asynchroon derivaat van de ARM7-RISC microprocessor..
ARM710 / Amulet2e
Proces : 600nm / 500nm
#transistors: 570.000 / 454.000
Cachegrootte: 8 KB / 4 KB
Rekenkracht: 23 MIPS / 38 MIPS

En dan nog TITAC-2, gemaakt met als basis de MIPS R2000(zit/zat in printers)
TITAC-2 / MIPS R2000
#transistors: 496.000 / 100.000
Kloksnelheid: - / 16.7 MHz
Voedingsspanning: 3,3V / 5V
Dissipatie: 2,11W / -
(Cache uit): 1,02W / 2W
Performance: 54,1 MIPS / -
(Cache uit): 26,5 MIPS / 12 MIPS
Vergelijking met cache uit, de R2000 heeft er geen..
Verder werd er nog gemeld : "Bijzonder kenmerk van deze component is dat hij met weinig tevreden is: bij een extreme test functioneerde de TITAC-2 bij voedingsspanningen van 1,5 tot 6 volt in een temperatuur bereik dat thuis hoort in het Guinness Book of Records : -196 to 100 graden C chiptemperatuur. Hij is hierbij bovendien prima als thermometer te gebruiken : hoe hoger de temperatuur des te langzamer hij wordt. "
Maarja...dit is al een aantal jaren geleden.....
hij lijkt dus op de strongarm cpu die in pda`s en raidcontrollers gebruikt wordt ...
Readers interested in a notably less goopy and considerably deeper explanation of the virtues of async logic and its many technical challenges are urged to check out the Manchester University AMULET project Web Site.
http://www.theregister.co.uk/content/archive/17356.h tml
Waarschijnlijk is dit nog hele verre toekomstmuziek... ;(

Het ontwerpen van asynchrone logica is iets wat vele malen complexer is dan het maken van 'gewone' synchrone logica.
Het probleem zit hem in het feit dat er bij asynchrone logica geen enkele zgn. glitches in de signalen mogen zitten. Dit zijn ongewenste wisselingen in de interne spanningen, die ontstaan door timingsproblemen in de hardware. Bij synchrone logica zijn deze niet zo belangrijk, als je er maar voor zorgt dat alle signalen de juiste waarden hebben bij een klokflank.

Het maken van dit soort asynchrone processen is dus vele malen gecompliceerder, vooral om qua grootte op te schalen. Zeker een hele processor zal dus nog wel jaren op zich laten wachten. Dus hoeven we ons in de tussentijd ook nog helemaal niet druk te maken over de bijpassende software 8-).
Je kunt asynchrone schakelingen zo ontwerpen dat timing helemaal geen rol speelt. Dan heb je delay-insensitive systems. Echt simpel is het niet, maar schaalbaarheid hoeft geen probleem te zijn. En als ik Suns plannen een beetje begrepen heb, willen ze een heleboel identieke rekeneenheden parallel zetten. Op die manier is het ontwerpen een stuk minder werk.

Er zijn trouwens al werkende asynchrone processoren, Philips heeft bijvoorbeeld een asynchrone 8051 (microcontroller). En Rudie_V noemt er ook een paar. Maar tot nu toe worden asynchrone processoren alleen gebruikt als laag energieverbruik een absolute must is.
En toen stierf de tweakersgemeenschap bij ontbreken van tweakbare onderdelen... :)
Zo'n asynchrone processor kun je heus wel overklokken: verlaag de temperatuur en hij gaat harder lopen!
Zo'n asynchrone processor? Welke?
Diegene die ze nog moeten bouwen?
Volgens mij heb je het niet begrepen. Megahertzen zijn totaal irrelevant bij dit concept. Dat proberen ze dus duidelijk te maken.
Dan gaan we toch gewoon over op het tweaken van de software }>. Die bepaalt hoe de processor zich gedraagd.
ze gebruiken een netwerk , als ze nou beginnen met 10mbit,en dan met groeipad naar 100mbit, 1gbit ..... :+
Asynchrone chips zijn nix nieuws, en de vuist regel is:
Hoe koeler hoe sneller. :)
Dus al vast oefenen met waterkoeling en dergelijke, ik heb gister een gast overtuigt om een vapochill-achtig ding proberen te bouwen. 8-)
wow zo kan je dus echt ff een efficiente patch ergens over gooien.... ik denk dat sun een erg goed punt heeft.. er komt een keer een einde aan en wat dan? als ze dit vrij snel al op de markt kunnen zetten denk ik dat t echt een hit wordt, al denk ik niet dat t echt geschikt is voor eindgebruikers en gamers.. draait er vast fantastisch op, maar t schrijven van de software kost extreem veel extra tijd en specialistische kennis, voor spelletjes met een 2 maanden sales duur is dit denk ik dus niet rendabel.. of de prijs gaat extreem omhoog
/edit/typo/edit
Er staat dat de compiler programmeurs de controle krijgen ( misschien de andere programmeurs ook, maar dan waarschijnlijk optioneel ) dus hoeft deze nieuwe techniek niet meteen een verlenging van het ontwikkelingsproces te betekenen..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True