[Sammelthread] VISC CPU Architektur, NEWS Thread zu AMD, ARM, Samsungs Start Up

Unrockstar

Unrockstar

Enthusiast
Thread Starter
Mitglied seit
16.01.2005
Beiträge
2.762
Ort
HH\Wandsbek\Hinschenfelde
Hallo Luxxer,

Diese Meldung ist nun schon 3 Tage Alt, aber sehr Intressant. Das Startup Softmachines, welches seit 2006 existent ist, arbeitet an einer Architektur, die stark paralellisierte Anwendungen beschleunigen soll. Bisher ist nicht viel über das StartUp Bekannt, nur dass AMD, GloFo und auch Samsung sich erhoffen Intels perf/w Verhältnis zu schlagen.
Das Prinzip ist einfach: Man will möglichst die ST Programme auf mehrere Threads auslagern, derzeit stecken 125Mio US-Dollar im Unternehmen.




Originalmeldung vom 23.10.2014

Soft Machines breaks cover with the VISC architecture - SemiAccurate
Soft Machines Unveils VISC

Hier auch die Meldung von techreport.com
CPU startup claims to achieve 3x IPC gains with VISC architecture - The Tech Report

Meldung von Extremetech, das ganze Etwas Ausfürlicher:
VISC CPU ‘virtual core’ design emerges: Could this be the conceptual computing breakthrough we’ve been waiting for? | ExtremeTech
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Fein Fein! Ich verstehe zwar nicht alles komplett ist aber erstmal sehr interessant. Wie soll das denn dann laufen? SoftMachines verkauft dann quasi die Architektur als Patent?
 
klingt auf jedenfall erstmal gut,
bin gespannt ob und was daraus mal wird :d
 
@ K3im

Also wenn ichs richtig Verstanden habe, soll es wohl Softwareseitig machbar sein. Sollte man also Samsung, AMD und ARM die Möglichkeit bieten durch die Paralelliserung der Kerne mehr Power pro Thread zu erzeugen, rückt das aber auch den Bulldozer nun in ein anderes Licht. Hier würde solche eine Technologie ja einen extremen Mehrwert haben, also wieder das Typische AMD Problem: Der Zeit Vorraus.
Ich stelle mir das Quasi so vor, dass man dann einen Thread mit 3 Kernen belegt und somit eine um 300% Höhere Leistung hat als bei einem Kern.. Intressant ist, ob es nachher im Chip Integriert ist, oder via Zusatzchip realisiert wird, denn dann könnte man auch Intel Systeme mit ausrüsten. Aber es klingt alles ja noch sehr Experimentell

Weitere Infos:

http://www.brightsideofnews.com/wp-content/uploads/2014/10/VISC5.jpg
http://images.bit-tech.net/news_images/2014/10/soft-machines-visc/article_img.jpg

Also für mich klingt es nach einem effektiveren Sheduler
 
Zuletzt bearbeitet:
Hmmm... ich denke daß das ganze aber nicht auf z.B. Spiele anwendbar sein wird. Vielleicht eher für so Sachen wie rendering oder wisenschaftliche Berechnungen wo im Vorfeld ungefähr klar ist was für Daten abgearbeitet werden müssen und nicht ständig neue unvorhersehbare Sachen übergeben werden. Kann aber auch völlig falsch sein mit meiner Kinderdenke :)
 
Hmm.. interessant! So richtig klar ist mir allerdings auch nicht wie sie das Problem lösen wollen, dass z.B. Hardwarethread-1 nicht anfangen kann etwas mit Daten zu berechnen, die Thread-2 erst noch bereitsstellen muss.
Es scheint eher so, als würde diese virtualisierende Schicht die Berechnungen so vorbereiten dass (in dem Beispiel) immer zuerst die Sachen von Thread-2 berechent werden und dann erst Thread-1 und das ohne dass Thread-2, Thread-1 blockiert. Das würde wohl tatsächlich was an Leistung bringen, aber es können immernoch nicht mehrere Kerne gleichzeitig an der selben Berechnung arbeiten.
Eine Echtzeitmaschine die nur einen einzigen echten (programmierten) Thread nutzt, würde daher überhaupt nicht von dieser Technik profitieren.

Also die Skalierung hängt mal wieder extrem vom Code ab...

Bleibt auf jeden Fall spannend!
Frage mich aber, wird die Software einen Lock gegen Intel haben? Sonst wird das nichts mit der Bevorzugung AMDs/Samsungs.
 
@k3im
eher das Gegenteil müsste der Fall sein.
Die haben sozusagen einen virtuellen Layer dazwischen, der die Anweisungen effizient verteilt, eben dort, wo bspw. bei Sprungvorhersagen, die womöglich eben falsch ausgehen, Leerlauf entsteht kann dieses Prinzip punkten, denn selbst dann, also wenn die Sprungvorhersage falsch ausgeht und bei "herkömmlichen Weg", Leerlauf entsteht, setzt diese Technik an um diesen Leerlauf zu umgehen, indem man einfach andere Instructions ausführt, die von einem anderen virtuellen "Thread" kommen.

Klingt auf jedenfall vielversprechend das Ganze... Mal schauen was draus wird.



Man sollte das aber definitiv nicht überbewerten. Gerade bei Anwendungen im Alltagsgebrauch. Ein Faktor, der für stark unterschiedliche Performance sorgen kann/könnte ist immernoch die Software bzw. das OS.
Mit aller größter Warscheinlichkeit wird man sich für so ein Konzept nicht irgendwelchen Programmcode suchen, der denkbar ungünstig ist, sondern eher das Gegenteil wird der Fall sein -> um den Vorteil aufzuzeigen.
Sprich in der Praxis, abseits von "generischem" Code muss klar abgewartet werden, was da an Performance hinten bei rum kommt.

Vor allem sehe ich immernoch den Programmierer in der Pflicht, möglichst effizienten Programmcode zu erzeugen.
Und was man halt nicht vergessen darf bei aller Euphorie darüber. A + B und das Ergebnis geteilt durch C wird IMMER! zwei Schritte benötigen. Da kann man virtualisieren wie man will, das lässt sich nicht beschleunigen sondern kostet dann eben die Zeit für zwei Schritte. Je nach Anwendung und Workload können mal mehr, mal weniger solcher ungünstigen Fälle entstehen.
Was will ich damit sagen? -> es lässt sich nicht beliebig alles beschleunigen, was in der Theorie möglich erscheint... Hier muss dann die Praxis zeigen, was am Ende bei rumkommen kann.
 
fdsonne schrieb:
@k3im
eher das Gegenteil müsste der Fall sein.
Die haben sozusagen einen virtuellen Layer dazwischen, der die Anweisungen effizient verteilt, eben dort, wo bspw. bei Sprungvorhersagen, die womöglich eben falsch ausgehen, Leerlauf entsteht kann dieses Prinzip punkten, denn selbst dann, also wenn die Sprungvorhersage falsch ausgeht und bei "herkömmlichen Weg", Leerlauf entsteht, setzt diese Technik an um diesen Leerlauf zu umgehen, indem man einfach andere Instructions ausführt, die von einem anderen virtuellen "Thread" kommen.
Zum Vergrößern anklicken....
Uhm.. macht nicht Intels Hyperthreading exakt das was du beschreibst auf Hardwarebene? Hatte ich zumindest immer so verstanden...

Diese Technologie hier habe ich aber irgendwie anders verstanden. Da ist ja nicht die Rede von dr Sprungvorhersage.
 
Zuletzt bearbeitet:
Woher nehmt ihr, dass es sich um eine Softwarelösung handelt?

In den Texten steht doch klar, das eine "Out of Order Architektur" sehr komplex ist und man versucht diese Komplexität mit der VISC Architektur zu umgehen.

Letztenendes klingt das ganze für mich nach vielen sehr einfach gehaltenen Kernen, die nicht viel können und einem Großen "komplexen" Frontend, das diese Versorgt, ähnlich wie wir es aktuell bei Grafikkarten haben.

E: Man sollte aber auch bedenken, das das Sample nur mit 350MHz lief und dadurch auch eine sehr kurze Pipeline möglich ist und auch die Effizienzprobleme bei hohem Takt nicht vorhanden sind. Man wird wohl abwarten müssen, was am ende dabei raus kommt, schlecht klingt es aber für den Anfang nicht.
 
Zuletzt bearbeitet:
Ich hab auch nix von Sprungvorhersage bzw. deren Verbesserung gesagt. Ich sagte, das durch Sprungvorhersagen Leerlauf entsteht... Das war ein Beispiel, nicht mehr und nicht weniger.
 
why_me schrieb:
Woher nehmt ihr, dass es sich um eine Softwarelösung handelt?

In den Texten steht doch klar, das eine "Out of Order Architektur" sehr komplex ist und man versucht diese Komplexität mit der VISC Architektur zu umgehen.

Letztenendes klingt das ganze für mich nach vielen sehr einfach gehaltenen Kernen, die nicht viel können und einem Großen "komplexen" Frontend, das diese Versorgt, ähnlich wie wir es aktuell bei Grafikkarten haben.

E: Man sollte aber auch bedenken, das das Sample nur mit 350MHz lief und dadurch auch eine sehr kurze Pipeline möglich ist und auch die Effizienzprobleme bei hohem Takt nicht vorhanden sind. Man wird wohl abwarten müssen, was am ende dabei raus kommt, schlecht klingt es aber für den Anfang nicht.
Zum Vergrößern anklicken....
Aus dem S|A Link:

What is Softmachines going to actually make? They are aiming to license cores and technology, not to make SoCs themselves. They will either make a core for license or allow you to roll your own with their architecture depending on your needs. If they provide the x86 and/or ARM software translation layers, VISC chips could be a very attractive way to go for many mobile SoC maker. More interestingly this does not necessarily compete with ARM or AMD/Intel directly, it could work with them too if the customer does not want to use the Soft Machines ISA.
Zum Vergrößern anklicken....
Das hört sich wirklich vielversprechend an, der single Thread Overhead muss weg! :bigok:
 
Weiss einer was der "EEMBC RGB-CMYK DBENCH benchmark" direkt macht worin VISC geführt hat?
Klingt irgendwie nach Konvertierung von Farbräumen in Bildern was ja viele parallele Prozesse erlauben dürfte und in Richtung GPU tendiert.
 
fdsonne schrieb:
Ich hab auch nix von Sprungvorhersage bzw. deren Verbesserung gesagt. Ich sagte, das durch Sprungvorhersagen Leerlauf entsteht... Das war ein Beispiel, nicht mehr und nicht weniger.
Zum Vergrößern anklicken....

Wo soll den die Architektur bei Sprungvorhersagen etwas bringen?
Da wird so lange die Pipeline gefüllt, bis klar ist das der Spring misst war und dann kommt der Flush und es wird sofort am anderen Sprung weiter gemacht.
Die Pipeline hat dadurch keinen Leerlauf, der irgendwie ausgenutzt werden könnte. Irgendwo mitten in die Pipeline wird VISC auch nicht Daten schaufeln können, warum auch? Dann ist ja eine andere Pipeline an der selben stelle leer ;)

--
Und es ist wie Why_me schon geschrieben hat eine Hardwarelösung und keine Softwarelösung, wie sich manche das hier vorstellen.

Man könnte den Decoder der VISC-CPU auf x86 umbauen und dann entsprechend auch für solchen Code nutzen, selber kann er es aber nicht.
 
fdsonne schrieb:
@k3im
eher das Gegenteil müsste der Fall sein.
Die haben sozusagen einen virtuellen Layer dazwischen, der die Anweisungen effizient verteilt, eben dort, wo bspw. bei Sprungvorhersagen, die womöglich eben falsch ausgehen, Leerlauf entsteht kann dieses Prinzip punkten, denn selbst dann, also wenn die Sprungvorhersage falsch ausgeht und bei "herkömmlichen Weg", Leerlauf entsteht, setzt diese Technik an um diesen Leerlauf zu umgehen, indem man einfach andere Instructions ausführt, die von einem anderen virtuellen "Thread" kommen.
Zum Vergrößern anklicken....

zB. hier
 
??
bspw. steht immernoch für beispielsweise...
Die haben sozusagen einen virtuellen Layer dazwischen, der die Anweisungen effizient verteilt, eben dort, wo bspw. bei Sprungvorhersagen, die womöglich eben falsch ausgehen, Leerlauf entsteht kann dieses Prinzip punkten...
Ich hab dir das relevante mal markiert -> Offenbar ist die Sprungvorhersage ein Beispiel. Und jetzt? Wo habe ich das also behauptet?

Auch scheinst du den falschen Gedanken zu verfolgen. In meiner Aussage gibt es nicht nicht um Leerlauf in der Pipeline, sondern den Leerlauf in den Teilen des Prozessors. Brach liegende Einheiten bringen keinen Speed. Könnten aber was machen.

Steht sogar so im Text von SemiAccurate:
"These threads are then dynamically allocated to hardware resources based on the needs of the thread, this hardware is a virtual core. If you have a ‘heavy’ thread it gets more of the appropriate resources, a light thread will get less, but in theory both should get what they both need and will use. You can see the power and performance benefits here, the optimal case is where the hardware is perfectly aligned with the software and nothing is unused."

Es bleibt also dabei...
 
Wenn man etwas mit den Zahlen spielt dann könnte man zu dem Schluss kommen daß der tolle neue Prozessor einfach nur ein 10/12-way-Design ist mit 11 INT/ALU + gut abgestimmtem Frontend+SMT. AnandTech | Intel's Haswell Architecture Analyzed: Building a New PC and a New Intel
Den gleichen Weg geht Intel ja mit Haswell http://www.hotchips.org/wp-content/...epub/HC25.27.820-Haswell-Hammarlund-Intel.pdf Folie 23 "Deeper Buffers".
Das einzige Problem an der Sache ist das Powergating wenn nur wenig oder keine Last anliegt -> sollte das behoben sein dann werden wir Singlecores sehen die aktuelle 15-Kerner in die Tasche stecken - falls es jedoch weiterin besteht bleibt der Prototyp ein nettes Spielzeug aber nichts was ernsthaft weiterverfolgt werden kann - der Energieverbrauch im Teillastbereich wäre abnorm hoch und damit niemals konkurrenzfähig.
 
Legt man das geschriebene im SemiAccurate Artikel auf die Goldwaage, dann lese ich ja nix von niedrigem Verbrauch. Sondern man will eher die Effizienz, also Leistung pro Watt bzw. die absolute Leistung steigern/verbessern.
Wenn die Leistung derart ansteigt, das die Effizienz am Ende in Sachen Leistung/Watt immernoch stark über dem aktuellen liegt, wäre das ja "OK"...
 
Schön, endlich mal ein AMD Thread wo Sachlich diskutiert wird. Freut mich :)

Nunja Thema Effizienz, wenn der Cpu unter Load und Idle gute Effizienz hat, ist das mehr als Ausreichend.. Full Load dürfte kein Tablet Erreichen und auch keine Desktop CPU auf dauer. Wenn man Ehrlich ist, dann denke ich kaum, dass man mit den derzeitigen Prozessen in 28nm noch große Effizienzsprünge erreichen kann. Insofern wäre eine neue Sheduler Einheit Onboard oder gar Integriert im DIE keine schlechte Lösung. Hier noch ein Artikel von Extremetech

VISC CPU ‘virtual core’ design emerges: Could this be the conceptual computing breakthrough we’ve been waiting for? | ExtremeTech

Pinne den oben auch gleich an

Das hier finde ich auch sehr Intressant:

extremetech schrieb:
The approach is supposedly OS- and vendor-agnostic; VISC can handle both ARM and x86 code with a roughly 5% performance hit from translation. This may remind you of Transmeta, whose Code Morphing Engine translated x86 ops into a VLIW-compatible structure that the CPU could execute, but Soft Machines stresses that VISC is actually the opposite approach. Instead of an incredibly complex and difficult translation engine that relies on software execution, the work of extracting ILP and scheduling the code to run across hardware is done on-chip.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
senbei schrieb:
Wenn man etwas mit den Zahlen spielt dann könnte man zu dem Schluss kommen daß der tolle neue Prozessor einfach nur ein 10/12-way-Design ist mit 11 INT/ALU + gut abgestimmtem Frontend+SMT. AnandTech | Intel's Haswell Architecture Analyzed: Building a New PC and a New Intel
Den gleichen Weg geht Intel ja mit Haswell http://www.hotchips.org/wp-content/...epub/HC25.27.820-Haswell-Hammarlund-Intel.pdf Folie 23 "Deeper Buffers".
Das einzige Problem an der Sache ist das Powergating wenn nur wenig oder keine Last anliegt -> sollte das behoben sein dann werden wir Singlecores sehen die aktuelle 15-Kerner in die Tasche stecken - falls es jedoch weiterin besteht bleibt der Prototyp ein nettes Spielzeug aber nichts was ernsthaft weiterverfolgt werden kann - der Energieverbrauch im Teillastbereich wäre abnorm hoch und damit niemals konkurrenzfähig.
Zum Vergrößern anklicken....
Soweit ich das verstanden habe, geht es nicht darum alle Kerne auf die Singlethread Aufgabe zu fokussieren, auch wenn es möglich wäre.
Sondern flexible die Leistung zu verteilen unabhängig vom Code.
Hier gibt es auch ein paar weitere Infos:

Soft Machines hopes to license the VISC technology to other CPU-design companies, which could add it to
their existing CPU cores. Because its fundamental benefit is better IPC, VISC could aid a range of applications from
smartphones to servers. The company has applied for more than 80 patents on its technology.
Zum Vergrößern anklicken....
http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf
 
Soweit ich das verstehe, versucht man RISC und CISC durch VISC zu ersetzen. Jetzt bleibt die Frage wieviel davon Marketing ist und wieviel revolutionär... In jedem Falle ist es eine Art reverse-SMT, aus einem Thread viele machen. Das ist nichts anderes als der Heilige Gral der CPU-Entwicklung, von daher ist gesunde Skepsis angebracht.
In jedem Fall ist es eine Hardwareimplementation, keine Softwareimplementation (außer EFI). Man kann zwar existierende Architekturen verwenden, eine neue Maske wird meiner Ansicht nach dennoch fällig. Und optimal ist sicherlich nur eine explizit angepasste Architektur. Letztendlich bleibt noch die Frage, mit welcher Effizienz das Ganze laufen kann. Taugt es, um über das für x86 typische IPC2-Limit zu kommen? Intel versuchts ja über Erweiterung der ISA, die anderen Hersteller gehen offenbar andere Wege.
 
Zuletzt bearbeitet:
@hot:

Ja du triffst den Nagel auf den Kopf. Es gibt ja wohl schon einen Prototypen bei SoftMachines, der das Funktionsprinzip erläutert und auch Funktionsfähig sein soll.. Ich bin auch gespannt welche Effizienz dabei raus kommt, denn damit könnte man ja wieder anfangen, die Chips in die Breite zu bauen.. Man stelle sich mal einen theoretischen Magny Cours vor mit 32Threads, damit würde man im Serverbereich verdammt gute Werte erzielen, und sonst eben auf die Breite viele Threads abarbeiten. Dass wir hier von der Premier League der CPU Entwicklung reden, und selbst Intel dieses Prinzip nicht verfolgt, sollte ja klar sein, wie gut das Technisch machbare ausfällt.. Hier wird eben nicht nur ein leistungsfähiger Sheduler benötigt sondern man müsste wie Hot schon sagte, das RISC und CISC Verfahren komplett aufgeben. Bin echt gespannt ob hierraus mehr wird, als nur ein Papiertiger.

Info an die Mods: Habe hierraus nun einen News Sammler gemacht, damit nicht 100Threads hierfür aufgemacht werden.
 
@[HOT]
Von ersetzen kann ich nichts heraus lesen oder translaten!
Bisher war sowas nur auf RISC oder CISC Architektur möglich, nun soll es auch mit x86 möglich sein.
Würdest du die Wahrscheinlichkeit auch ausschließen?
 
Phantomias88 schrieb:
@[HOT]
Von ersetzen kann ich nichts heraus lesen oder translaten!
Bisher war sowas nur auf RISC oder CISC Architektur möglich, nun soll es auch mit x86 möglich sein.
Würdest du die Wahrscheinlichkeit auch ausschließen?
Zum Vergrößern anklicken....

Ui, das ist doch nicht wörtlich gemeint gewesen. Natürlich "ersetzt" VISC nicht RISC/CISC. Der Satz ist eher aus Marketingsicht zu betrachten, nicht realistisch. Aber das weist eben eindeutig auf Hardware hin, das ist kein reiner Softwarelayer.
 
Die Werte sind leider nicht vergleichbar/real. Die Suite wurde in 32-bit mit gcc 4.6 und ohne Autoarallelisierung compiliert -> gcc 5.2 und Autoparallelisierung geben ganz andere Werte für nahezu alle ARMs/Haswells. Warum schönt diese Firma ihre "Messdaten" so dreist?
 
Und wenn die Benches einfach schon 3 Jahre alt sind? ;)
 
Würde das Ganze noch unglaubwürdiger machen, denn wieso sollte man mit derart alten Daten vergleichen wollen wenn man eh das beste Pferd im Stall hat?
 
senbei schrieb:
Die Werte sind leider nicht vergleichbar/real. Die Suite wurde in 32-bit mit gcc 4.6 und ohne Autoarallelisierung compiliert -> gcc 5.2 und Autoparallelisierung geben ganz andere Werte für nahezu alle ARMs/Haswells.
Zum Vergrößern anklicken....
In dem Artikel von Tech Report steht nichts zu Compilerversionen und -einstellungen. Woher stammt die Info, dass da unterschiedlich getestet worden sein soll?
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh