Soft Machines "Virtual Cores" VISC

[mboeller]

http://nextbigfuture.com/2014/10/virtual-cores-and-virtual-threaded.html

http://www.softmachines.com/


The startup aimed for 10x improvements but on average expects to deliver still respectable 4x gains.

The VISC architecture achieves 3-4 times more instructions per cycle (IPC), resulting in 2-4 times higher performance per watt on single- and multi-threaded applications. Moreover, VISC uses a light-weight “virtual software layer” that makes VISC architecture applicable to existing as well as new software ecosystems.


Nette Präsentation (verlinkt unter dem Link)

die quatschen was von einem IPC von 2.1 (32bit Code) bei Spec 2006 wohingehend ein Haswell nur 1,39 (64bit Code) erreicht. Das Verhältnis von A15 zu A57 (0,71 zu 0,87 passt, soweit ich das sagen kann).

die Heise-Meldung dazu ist irgendwie an mir vorübergegangen:
http://www.heise.de/newsticker/meldung/VISC-Ein-virtueller-Single-Core-Prozessor-2435023.html


AMD ist übrigens an Soft Machines beteiligt, genauso wie der bei Intel gescheiterte frühere Mikroprozessorchef Albert Yu, wie Samsung und Globalfoundries-Besitzer Mubadala.

[samm]

"Der bei Intel gescheiterte... Albert Yu"? Sehr verdächtige Formulierung, was möchte heise da suggerieren? Von 1972 bis 2002 hat der gute Mann bei Intel gearbeitet. Scheitern sieht für mich anders aus.

Wiedermal ein Fall von "inverse hyperthreading" oder wie das hiess reverse hyper-threading. Ich bin gespannt, ob das und wenn ja dann wieviel von der tollen IPC in der Praxis erreicht werden kann, was die letztlichen Taktraten sind, und was die Latenzen sind, die man sich durch die zusätzlichen Schichten einhandelt. Sicher spannend, aber ich bin von der praxistauglichkeit so vom ersten Eindruck her noch kein bisschen überzeugt.

[mboeller]

auf der Homepage findest du auch noch den Microprocessor Report:

http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

Der hat zwar auch nicht mehr Informationen, gibt aber eine Einschätzung was davon in der Praxis noch übrig bleiben kann. Wenns stimmt wäre es schon genial, vor allem eben weil es mir vorhandener Software funktionieren soll.

Ein simpler QuadCore wie ein Beema mit 2GHz wäre dann bei SingleThread so schnell wie ein Haswell mit 3GHz (2,1/1,39 x2Ghz) ....wenns stimmt. :)

[Akkarin]

Bei S|A höhrt es sich irgendwie komplett anderst als bei den meisten an. Während z.b. heise und "The Linley Group" immernoch von cores sprechen und ein thread auf mehrere cores aufgeteilt werden kann ("reverse hyper-threading"), spricht S|A nicht/kaum von "hardware cores", sondern von "virtual cores" welche dann sehr feinkörnig einzelne recourcen (ALU, FPU, busses, memory blabla) zugeordnet bekommen. Der "dual core" den sie vorgestellt haben hätte dann einfach 2 virtual cores welche verteilt werden können.

tbh weiß ich nicht was ich glauben soll. Charlies erklärungen lesen sich sehr sinnvoll, aber die slides die überall gepostet werden sprechen immer von "richtigen" cores auf die dann ein thread aufgeteilt wird.

[samm]

Super, danke für den Lesestoff mboeller :)Charlies erklärungen lesen sich sehr sinnvollEs gibt für alles ein erstes Mal ;) Ernsthaft, ich denke, die "virtual cores" werden wohl das sein, was dem OS präsentiert wird, und keinen direkten Zusammenhang mit den physikalisch vorhandenen ALUs etc. haben. Ob die physikalischen Ressourcen on-the-fly verteilt werden können, sehe ich beim ersten Überfliegen des PDFs noch nicht.

[drkohler]

Also es geht doch bei dem Ding darum, einen Single-Thread so neu zu "zerstückeln", dass bis zu vier Cores diesen einen Thread zusammen beackern können?
Wenn dann eine Website MisterxMediaLogic anwendet, kommt dann ein Titel wie "Neuer Prozessor 40% schneller als Intel Haswell" heraus (gerade sowas gefunden im Netz). Sowas ist ganz toll für Programme, die vor ca 1990 geschrieben wurden (oder für ein Handy, da läuft ja meist nir ein Thread wirklich?)...

[mboeller]

Also es geht doch bei dem Ding darum, einen Single-Thread so neu zu "zerstückeln", dass bis zu vier Cores diesen einen Thread zusammen beackern können?
Wenn dann eine Website MisterxMediaLogic anwendet, kommt dann ein Titel wie "Neuer Prozessor 40% schneller als Intel Haswell" heraus (gerade sowas gefunden im Netz). Sowas ist ganz toll für Programme, die vor ca 1990 geschrieben wurden (oder für ein Handy, da läuft ja meist nir ein Thread wirklich?)...

aus dem Microprocessor Report:

Although the test chip has only two physical cores, Soft Machines has run simulations on a four-core design. As one might expect, the performance gains diminish for the additional cores: the third core adds 20–30% to single-thread performance, and the fourth adds only 10–20%. In total, the four-core design delivers about twice the performance of a single core. The unused resources in the extra cores, however, can be devoted to additional threads. For example, a four-core design could run two threads at close to their maximum performance.


nirgends steht das mit dem System nur 1 thread pro CPU läuft. Es steht nur da, das die Resourcen optimal verteilt werden und SingleThread beschleunigt wird. Wäre für AMD natürlich ideal. Bei MultiThreading haben sie ja kein Problem.

[Akkarin]

Gibt es irgendwo n ausfürhliches paper von Softmachines selbst ?

[GloomY]

die quatschen was von einem IPC von 2.1 (32bit Code) bei Spec 2006 wohingehend ein Haswell nur 1,39 (64bit Code) erreicht. Das Verhältnis von A15 zu A57 (0,71 zu 0,87 passt, soweit ich das sagen kann).

die Heise-Meldung dazu ist irgendwie an mir vorübergegangen:
http://www.heise.de/newsticker/meldung/VISC-Ein-virtueller-Single-Core-Prozessor-2435023.htmlHeise erwähnt auch, dass Haswell bei andere Messungen (mit Intel- statt veraltetem gcc 4.6 Compiler) bei SPECint_2006 einen IPC von 1,9 erreicht.

auf der Homepage findest du auch noch den Microprocessor Report:

http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

Der hat zwar auch nicht mehr Informationen [...]Doch, hat er:
Das Front-End ist geshared und nahezu identisch mit einem klassischen Prozessor. Die Befehle werden gefetched (aus einem gemeinsamen L1-I Cache), dekodiert, falls notwendig Sprünge vorhergesagt und falsche Ausgabeabhängigkeiten durch "globales" Register-Renaming aufgelöst.

Der Unterschied ist dann das Dispatchen: Es werden mehrer dekodierte Befehle zu Bündeln zusammengefasst (meist welche, die Abhängigkeiten untereinander haben) und an einen "Kern" verteilt ("Kern ist hier eigentlich nicht der richtige Ausdruck; "Backend" wäre eher treffender).
Jeder Kern hat seine eigenen Ausführungseinheiten, Scheduler, Renamed Register und L1 D-Cache. Diese führen dann ihre zugeordneten Befehle aus. Danach erfolgt das Retirement, wobei das Retirement auf die ausgeführen Befehle aus allen "Kernen" in der richtigen Reihenfolge zusammensuchen muss.

Ich sehe da verschiedene Probleme oder Fragestellungen:

Register-Zugriff/Renaming/Invalidierung: Das Renaming macht das Front-End, jeder Core hat seinen eigenen Register-Satz. Bei Branch-Mispredictions müssen Register aus Register-Sätzen verschiedener "Kerne" invalidiert werden. Also muss aus dem Front-End heraus auf alle Register-Files zugegriffen werden können. Genauso muss beim Retirement auf Register aus Registersätzen aller "Kerne" zugegriffen werden können. Und während der Ausführung müssen Register-Inhalte zwischen "Kernen" transferiert werden, um echte Abhängigkeiten aufzulösen. Das kostet Zeit, wie im MicroProcessor Report erwähnt wird.
Man muss Abhängigkeiten zwischen Befehlen in Bündeln auf verschiedenen "Kerne" verfolgen. Insbesondere kann man die Bündel nicht beliebig groß machen, da man sonst nur auf einem "Kern" ausführt und die anderen nutzlos nichts-tun. Man kommt also unweigerlich in die Situation, dass es Bündel-Abhängigkeiten zwischen verschiedenen Kernen gibt. Diese müssen getrackt werden, und somit braucht man wiederum sowas wie eine globalen Scheduler.
Wo der Vorteil gegenüber einem "klassischen" Prozessor mit einem (globalen) Scheduler und Register-File sein soll, wird mir hierbei nicht klar.
Jeder "Kern" hat seinen eigenen L1 D-Cache. Da alle "Kerne" an dem gleichen Software-Thread arbeiten, wird es unweigerlich dazu kommen, dass diese auf die gleichen Daten zugreifen auf Grund der Befehlsbündel-Zuweisung. Es wird also jede Menge Daten mehrfach in den L1 D-Caches aller "Kerne" vorhanden sein. Das senkt die Effektivität (und erhöht den Cache-Kohärenz-Verkehr) gegenüber einem "traditionellen" Multi-Core, wo jeder Kern seinen eigenen Thread abarbeitet und damit meist seine eigenen Daten getrennt zugreift. Die gleichen Daten mehrfach in Hardware vorzuhalten ist eine Verschwendung von SRAM.
Je nachdem wie groß die Befehlsbündel sind, verliert man möglicherweise IPC, wenn nämlich im Bündel mehr Parallelität vorhanden ist, als man in einem "Kern" parallel ausführen kann. Das kann man dadurch lösen, indem man die Bündel sehr klein macht, was aber den Verwaltungsaufwand in Hardware erhöht. Es gibt keine Angaben dazu, aber eventuell verliert man hier ein wenig Performance.


Zusammenfassung: Der Ansatz besteht also daraus, das Back-End in n Teile aufzuspalten und damit jeden Teil weniger komplex zu machen. Trotzdem müssen in bestimmten Situationen aus allen Backends Daten transferiert werden und Informationen über die Abhängigkeiten zwischen Befehlen zwischen den Backends ausgetauscht werden.

Ob das Die-Platz und/oder Strom spart, ist hier wohl die alles und entscheidende Frage. Das kann man aber aus den bisher veröffentlichten Zahlen nicht annähernd sagen.

[GloomY]

Das ganze erinnert auch an das Gruppieren von Befehlen im IBM PowerPC 970MP, um das dispatchen zu erleichtern:

These five boxes represent what IBM calls a "group", and each "group" consists of five IOPs arranged in program order according to certain rules and restrictions. It is these organized and packaged groups of five IOPs, and not single IOPs in isolation, that the 970 dispatches in-order to the six issue queues in its execution core. Once the IOPs in a group reach their proper issue queues, they can then be issued out of order to the execution units [...]
Quelle (http://archive.arstechnica.com/cpu/02q2/ppc970/m-ppc970-4.html) (leider nur die Mobil-Version mit Google gefunden).

[StefanV]

@Gloomy

Was du so zu dem ganzen sagst, klingt einerseits irgendwie recht stark nach dem Prinzip nach dem ein aktueller Grafikchip arbeitet, andererseits aber auch nach einer Weiterführung der Idee hinter dem Bulldozer...

[Coda]

Das riecht so extrem nach Bullshit. Die Intel-CPUs haben sicher keine Probleme mehr mit Execution Resources sind also fast pur dadurch limitiert wie viel Parallelität im Instruction-Stream vorhanden ist. Wie will man da bitte magisch 2-4x (!) so viel rausquetschen? Es ist ja nicht so als würde man nicht schon seit dem Pentium Pro Instruktionen parallel ausführen falls möglich.

Selbst 50% mehr wäre ein mittleres Wunder.

Das einzige was ich mir vorstellen könnte ist, dass sie das auf extrem simple Kerne beziehen. Und was ist dann genau der Punkt?

[mboeller]

Laut Soft Machines soll der Benchmark SPEC2006 beim VC-2-Prototypen bei IPC auf einen sehr guten Wert von 2,1 kommen, gegenüber einem Wert beim nicht weiter spezifizierten Haswell von 1,39, beim Apple A7 von 1,0, ARM A57 von 0,87, ARM A15 von 0,71 und Intel Atom von nur 0,69.



aus dem Heise-Artikel

[Coda]

Kann sein, dass es bei Spec den Fall gibt dass man extrem viele Instructions parallel ausführen kann durch die ganzen Matrix-Multiplikationen und man tatsächlich von mehr Execution-Resources profitieren könnte als Haswell hat.

Der Regelfall sieht anders aus.

[Gipsel]

Haswell kommt mit Intel-Compiler laut Heise auf einen IPC-Wert von 1,9. Dabei läuft er im Zweifelsfall mit 4 GHz, der Prototyp von Soft Machines schafft angeblich nur 350MHz. Da liegt bei der Performance also so grob Faktor 10 dazwischen.
Ob der Ansatz bei vergleichbaren Taktraten noch mehr IPC generieren kann (also auch absolut von der Leistung her konkurrenzfähig wäre) oder Strom spart, halte ich doch im Moment noch für arg zweifelhaft.

[GloomY]

@Gloomy

Was du so zu dem ganzen sagst, klingt einerseits irgendwie recht stark nach dem Prinzip nach dem ein aktueller Grafikchip arbeitet, andererseits aber auch nach einer Weiterführung der Idee hinter dem Bulldozer...Richtig - nur mit dem Unterschied, dass der Bulldozer zwei verschiedene Threads abarbeitet während es hierbei nur ein Thread ist. Beim Bulldozer ergeben sich daher einige positive Effekte, die beim VISC nicht vorhanden sind:

Fehlende Instruktions-Parallelität in einem Thread kann zu mehr verfügbaren Ausführungseinheiten (und damit mehr Instruktions-Parallelität) für den anderen Thread führen.
Branch-Missprediction in einem Thread stalled nicht die Ausführung des anderen Threads; Ebenso Cache-Misses;
Ungenutzte Ausführungseinheiten eines Threads (z.B. Floating-Point) stehen dem anderen Thread exklusiv zur Verfügung

Das riecht so extrem nach Bullshit. Die Intel-CPUs haben sicher keine Probleme mehr mit Execution Resources sind also fast pur dadurch limitiert wie viel Parallelität im Instruction-Stream vorhanden ist. Wie will man da bitte magisch 2-4x (!) so viel rausquetschen? Es ist ja nicht so als würde man nicht schon seit dem Pentium Pro Instruktionen parallel ausführen falls möglich.

Selbst 50% mehr wäre ein mittleres Wunder.Da stimme ich dir zu.

Das einzige was ich mir vorstellen könnte ist, dass sie das auf extrem simple Kerne beziehen. Und was ist dann genau der Punkt?Eventuell ist das ganze stromsparender?

Wie gesagt ist das nur eine Vermutung. Ich weiss es nicht.

[StefanV]

Das einzige was ich mir vorstellen könnte ist, dass sie das auf extrem simple Kerne beziehen.
So würd ich das auch verstehen wollen, das ganze klingt irgendwie so als ob man etwas GPU-artiges als CPU benutzen möchte.

Sprich eher kleinere, einfache Kerne nutzen statt dicker Kerne wie man es aktuell macht.

[Loeschzwerg]

http://www.golem.de/news/visc-shasta-mojave-soft-machines-neue-cpus-beherrschen-reversed-hyperthreading-1510-116771.html

VISC ist wieder in den News.

XwnbphWp4Hw

Dank dem Software Layer ist VISC zwar evtl. kompatibel zu allen anderen CPU Architekturen, aber ob das wirklich performant ist? Ich denke da z.B. an Transmeta und deren CPUs waren lahm ohne Ende :D

[mboeller]

Heise News dazu:

http://www.heise.de/newsticker/meldung/Neuer-VISC-Prozessor-von-Soft-Machines-2840028.html

2GHz hört sich nicht schlecht an.

[-/\-CruNcher-/\-]

Ein netter neuer Competitor wenn er die Preise down bringt immer her damit ;)

Die ISA Agnostic ist wohl das interessanteste zusammen mit dem Effizienz potential aber Performance mal abwarten vor allem AMD mit ihrem ARM server approach und auch Nvidia momentan könnten da die Augen weit auf machen ;)

Intel hat da wohl das wenigste interesse dran von allen :D

Was auch wurmt wenn man schon peak multithreaded ist was soll das dann wirklich noch bringen ?

Wollen die jetzt das ganze Multithreaded wissen erasen und fordern Singlethreaded zu optimieren damit sie besser da stehen ;) ?

[Air Force One]

Wäre eher etwas für AMD

[Milchkanne]

Gibts eigentlich schon einen Thread über Mill Computing (http://millcomputing.com/docs/belt/)? Die entwickeln einen VLIW-ähnlichen Prozessor, der ohne Register auskommt und dafür eine FIFO Speicherstruktur auf unterste Ebene hat.
Die wollen DSP Leistung pro Watt für general-purpose single-thread Anwendungen liefern (Multicore natürlich möglich). Wenn ich mich recht erinnere wollen die einen IPC von >30 erreichen können.

[Lokadamus]

Wüsste spontan nicht, dass wir dazu schon etwas haben.

https://en.wikipedia.org/wiki/Mill_CPU_Architecture
http://www.golem.de/news/cpu-architektur-startup-will-mit-mill-prozessorarchitektur-revolutionieren-1405-106736.html

Glaube nicht, dass es viel bringen wird. Wahrscheinlich bringt es mit bisheriger Software früher oder später merkwürdige Fehler, die man zum Beispiel auch in Dosbox findet. Zu MS-DOS Zeiten wurden die Register eben manchmal etwas zweckentfremdet, wodurch bei etwas anderem Verhalten Fehler entstehen.

[Tesseract]

Gibts eigentlich schon einen Thread über Mill Computing (http://millcomputing.com/docs/belt/)?

ja, hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10224870#post10224870)

[Korfox]

Selbst 50% mehr wäre ein mittleres Wunder.
Offensichtlich gut getroffen ;).
Es gibt Neuigkeiten:
Die aktuelle Generation (die offensichtlich Ende diesen Jahres dann auch in Serienproduktion sein soll :eek:) kommt bei normierter Fertigung und gleichem Takt auf 50% mehr SPEC CPU2006 Punkte als Skylake, wenn ich das jetzt Mal richtig lese...

http://www.golem.de/news/visc-roadmap-soft-machines-will-apples-und-intels-prozessoren-schlagen-1602-118929.html
http://www.heise.de/newsticker/meldung/Soft-Machines-gegen-Cortex-72-Apple-A9x-und-Skylake-3093388.html

[Gipsel]

Das sind doch die gleichen Graphen wie schon vor ein paar Monaten.
Ich würde da einen pragmatischen Ansatz verfolgen: Wait and see.
Bevor die keine lauffähige Hardware vorzeigen, die ihre Heilsversprechen auch außerhalb einiger weniger Benchmarks einlösen können, bleibe ich zurückhaltend mit der Begeisterung.

[y33H@]

Nein, die sind neu mit A9X und Skylake.

EDIT
Damals war u.a. Haswell (8-wide OoO):

54696

[Korfox]

Aber wait&see ist nicht schlecht.
Wenn sie Ende des Jahres mit knapp 50% Effizienzplus vgl. zu heutigen CPUs aufschlagen ist das immernoch gut. Wobei die Messungen wohl die SingleCore Performance bescheinigen, das ist ja die Stärke der CPU.

[urpils]

Anandtech hat mal wieder nen guten Artikel rausgehauen - habe gerade angefangen:

http://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipc

[Lokadamus]

Anandtech hat mal wieder nen guten Artikel rausgehauen - habe gerade angefangen:

http://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipcHau den Scheiß in die Tonne. Wir befinden uns am Ende der 90er, wo Quake per Name in den Exen optimiert wurde.

Es ist irgendwie immer von 2 Sachen die Rede (oder ich hab die Grafiken nicht verstanden):
1.) Spec2006
2.) Stromverbrauch

Einfach mal die Randbedingungen anschauen.
Es wird GCC 4.9 (5.3 ist Devel) und Apple Clang (äh, was? Clang wird mittlerweile nicht mehr alleine von Apple weiterentwickelt, also welche Version?) verglichen.
http://images.anandtech.com/doci/10025/Testing%20%285%29.jpg
Wie sieht es mit den anderen Sachen aus? https://www.spec.org/benchmarks.html
Was soll ich mit einem "hochoptimierten" VLC, wenn die normale Fassung schon flüssig läuft?

Irgendwie erinnert es ein bischen an den Versuch Cuda/ Mantle auf einem X86 zu bringen. :uhammer:
Edit: Mich würde mal interessieren, was Jim Keller (ehemals AMD, CPU Guru) oder die Leute von Intel von dem Ding halten. Gibt es dazu irgendwelche Aussagen?

[Complicated]

Da AMD Teilhaber und Mitinhaber der Technik ist, scheint das eine recht klare Sache zu sein was AMD davon hält.
http://www.kitguru.net/components/cpu/anton-shilov/startup-unveils-visc-cpu-architecture-vows-2-4-times-performance-improvement/
Soft Machines was established around 2007 and since then has got $125 million from various companies and organizations, including AMD, GlobalFoundries, Samsung as well as govern-ment investment funds from Abu Dhabi (Mubadala), Russia (Rusnano and RVC), and Saudi Arabia (KACST and Taqnia). Sanjay Jha, chief executive officer of GlobalFoundries, is the chairman of Soft Machines. At present Soft Machines has more than 250 employees and 75+ issued patents.AMD/Samsung/GF

[Lokadamus]

Da AMD Teilhaber und Mitinhaber der Technik ist, scheint das eine recht klare Sache zu sein was AMD davon hält.
http://www.kitguru.net/components/cpu/anton-shilov/startup-unveils-visc-cpu-architecture-vows-2-4-times-performance-improvement/
AMD/Samsung/GFNicht wirklich, eventuell sind sie eher an den Patenten interessiert als an der Technik selber.

Die ältere Meldung vom Oktober 2015 zeigt, was mich die ganze Zeit an dem Ding stört.
http://www.heise.de/newsticker/meldung/Neuer-VISC-Prozessor-von-Soft-Machines-2840028.html
Als Benchmark wird der geometrische Mittelwert der beiden SPEC-CPU2006-Suiten herangezogen, 32bittig kompiliert mit gcc 4.6/4.7 ohne Autoparallelisierung. Haben sie das bei dem neuen Ergebniss wieder ohne Autoparallelisierung gemacht und wie sind die Ergebnisse mit Autoparallelisierung?
Wie auf Seite 1 die anderen schon geschrieben haben, es erinnert irgendwie an Bulldozer, Transmeta oder GPU auf CPU.

[Complicated]

Ja die Präsentation der Ergebnisse hat nicht nur diese Verschmelzung der SPECint und SPECfp Werte als Mangel. Da kommt noch einges mehr an "Schätzungen" zusammen, ebenso wie die verwendeten SKUs. Anand hat das recht ausführlich analysiert:
http://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipc/5
zu den SKUs:
The platforms used are not all what they appear to be. So for example, the best Cortex-A72 16nm data point would be the Kirin 950 in the Huawei Mate 8, but instead a dual A72 was used from the Amazon Fire TV which as a 28nm MediaTek MT8173 running at 1.98 GHz. One could argue that A72 is new enough and only recently on 28nm that it isn’t fully optimized for the process yet and this is probably a low end version of that silicon. The Apple A9X numbers are actually taken from a 14nm A9 and the assumption was made that the dynamic power in a cold environment was similar to the A9X. The Skylake numbers were a mid-range Core i5-6200U in a Dell laptop, which could be prone to variable turbo modes or overheating, and that specific SKU is hardly the most power efficient model in Intel’s Skylake lineup.

Allerdings erinnert das alles stark an HSA und an den HSAIL-Layer den AMD anbietet. Zumindest kann ich mir die Integration von VISC in HSA gut vorstellen. Mit so einem VISC Prozessor auf dem Interposer könnte man die x86 Kerne endlich für Multithreading optimieren und die bei alter Software wichtige Singlethreadleistung damit abfangen. Im Stil von Big-LITTLE bei Mobile-Chips. Sozusagen eine Fixed Function Unit für Singlethread so wie AES, VCE oder UVD eben bestimmte Workloads übernehmen.

[y33H@]

Zumindest vorerst ist das witzlos, da ein Shasta bei 2,5 GHz "nur" rund +50 % vor einem Skylake liegt - wohlgemerkt vor einem mit 3 MByte L3. Die Singlethread-Leistung eines i7 mit 8MB und 4,x GHz Turbo ist weit von dem entfernt was Soft Machines für den Shasta ansetzt. Und bei Intel wird die IPC die nächsten Jahre wohl kaum sinken.

[blinki]

Und jetzt ist es passiert, laut aktuellem Prozessorgeflüster (1/2017) hat Intel die Firma für 250 Millionen aufgekauft. Die überlegen sich ja auch wo die nächste oder übernächste IPC-Steigerung herkommen soll.

[y33H@]

Das war aber schon im Herbst, September oder so ... und damals hieß es, will kaufen. Ob es tatsächlich so kam, ist nicht öffentlich.

[blinki]

1. Lies doch bitte meine Quelle nach,
https://www.heise.de/ct/ausgabe/2017-1-Von-Instruktionen-und-Takten-3575493.html
und sag mir dann ob deine Aussage gleich bleibt.
2. Vielleich wollen sie ja auch nur der Konkurrenz die übernächste IPC_Steigerung verbauen/erschweren.
3. Die Frage ist haben sie die Katze im Sack gekauft oder erst nach eigenen Analysen zugeschlagen? - Das ist von hier wohl nicht zu beantworten

Gruß

[y33H@]

Nun, wenn Stilli sagt, da hängt ein Schild :biggrin:

Ich meinte schlicht, der Kauf wurde weder seitens Intel noch seitens Soft Machines per PM oder so verkündet.