News Qualcomms Server-Sparte: Nur 50 von 1.000 Angestellten bleiben

Sternengucker80 schrieb:
Ach dann kann ich von Win RT auf Win 10 Mobil updaten!? Okay, das hatte ich nicht gewusst.
Selbst mein Asbach Uralt Sockel 754 System ist von Win 98 bis Win 10 gelaufen.
Sowas hab ich bei ARM noch nicht gesehen.
Nuja, offiziell natürlich nicht. Aber durch das Windows Treibermodell dürfte das eigentlich möglich sein. W10M lief jedenfalls auf allen WP8 Geräten anstandslos. Und nur zur Info: W10M wurde quasi nur umbenannt in Windows 10 für ARM, der Code ist so gesehen quasi identisch und wurde nicht neu entwickelt. Also ein W10M mit Continuum Oberfläche.
 
fragemann schrieb:
Ja und weiter? Dass ARM Chips in der Pro Core Leistung deutlich langsamer sind als x86 ist ein Hut, der so alt ist wie Metusalem.
Eben nicht. Hier muss man ganz grundsätzlich ISA und Implementierung auseinander halten. Es gibt kein Naturgesetz, dass es verhindert, mehr als Qualcomms bzw. ARMs Kernschrott von der Stange zu verbauen.

Nimm einen Kabylake, pack ein ARM-Frontend dran, fertig ist ein Kern, der Kringel um Qualcomms/ARMs Kern rennt. (umgekehrt wäre ein Vortex mit x64-Frontend auch nicht langsam)

fragemann schrieb:
Was aber zählt ist das, was hinten raus kommt in Multi-Core gegenüber dem Stromverbrauch. Und hier ist es nun einmal so, dass diese deutlich effizienter sind.
Hinten raus kam bei Falkor: 950 Entlassungen, eine praktisch geschlossene Geschäfteinheit und eine Investition der kein (oder sehr geringer) generierter Umsatz gegenüber steht.

fragemann schrieb:
Was du also lernen musst, ist drei Informationen zusammenzufügen. Single Core Speed sagt nichts über das aus, was das Produkt am Ende abliefert in Gänze. Bekommt dein Hirn das hin? Ich ermuntere dich hiermit, es mal zu versuchen. Auch du kannst es schaffen!
Jetzt sitz ich hier wie das Kind vorm Weihnachtsbaum und frage mich, wo die "drei Informationen" versteckt sind.
 
incurable schrieb:
Eben nicht. Hier muss man ganz grundsätzlich ISA und Implementierung auseinander halten. Es gibt kein Naturgesetz, dass es verhindert, mehr als Qualcomms bzw. ARMs Kernschrott von der Stange zu verbauen.

Nimm einen Kabylake, pack ein ARM-Frontend dran, fertig ist ein Kern, der Kringel um Qualcomms/ARMs Kern rennt. (umgekehrt wäre ein Vortex mit x64-Frontend auch nicht langsam)

Und weiter? Wo ist da das Argument? Da bin ich dafür. Nur zu!! Niemand sagt, dass es nicht besser als QC ginge

incurable schrieb:
Hinten raus kam bei Falkor: 950 Entlassungen, eine praktisch geschlossene Geschäfteinheit und eine Investition der kein (oder sehr geringer) generierter Umsatz gegenüber steht.

Die Leistung eines Produkts sagt nie etwas über den Erfolg aus. Marketing, Kontakte, Marktträgheit und manchmal auch dirty illegal tricks (siehe IE+Kopplung mit WIndows, Intels Tricks gegen AMD etc) sind manchmal viel gewichtiger
 
Wenn ich Dich richtig verstehe, ist der Aufhänger für Dich, dass ich "Prozessoren" geschrieben habe, während Du lieber "Prozessorkerne" lesen würdest? (basierend auf der Frage, ob man Falkor als totes Projekt oder totes Produkt sieht)

Damit hab ich kein Problem, ich editier's mal. :daumen:
 
Steini1990 schrieb:
Was machen dann die verbliebenen 50 Mitarbeiter? Die Scherben aufsammeln?

Ne, die Entschuldigungsbriefe an die Aktionäre verschicken.
Das man in solchen Bereichen Sitzfleisch braucht, kommt wohl am Gabentisch der Aktienbesitzer nicht gut an.
 
incurable schrieb:
Qualcomm ist aktuell mit $80 Milliarden (deutsche, nicht US) bewertet, vor 2 Monaten waren es noch doppelt so viel.

Deutsche US-Dollar :watt:
 
Ich will mir gar nicht vorstellen, was dort im Moment für eine Stimmung herrscht, wenn man unter den letzten verbliebenen 5 % ist.
 
  • Gefällt mir
Reaktionen: Smartbomb und playthestation
Sternengucker80 schrieb:
Einen Laptop oder gar einen Rechner mit ARM würde ich mir nie kaufen. ... Nur weil der Treibersupport total miserabel ist.
Bin hier einmal bei Intel mit einen komischen Grafikchip hereingefallen, war denke ich PowerVR. Es gab einen Treiber da lief alles, Youtube, 1080p... Der Treiber wurden aber nicht weiter entwickelt und somit lief dann ein Jahr später unter Linux und Windows maximal Videos mit 480p und überall gab es Probleme.
 
... fielen überwiegend negativ aus, da das Software-Ökosystem fehlt. Die zweite Generation soll das alles besser machen

Frag mich ja wie die zu der Annahme kommen. Wo soll das denn bei einer Hand voll Endgeräte her kommen. Wenns schon mit dem Server nicht klappt, dann auf dem Enduser Markt schon 4x nicht.
 
iGameKudan schrieb:
ARM wird im Windows-Desktop genau so eine Bruchlandung wie im Server-Bereich.
Sehe ich auch so, die sind ja nicht die ersten die im Servermarkt die Segel streichen, die AMD Opteron A1100 sind zwar noch auf der Homepage von AMD zu finden, aber wo sind die praktisch im Einsatz?
XTR³M³ schrieb:
RM auf PC/Server ist halt nen rohrkrepierer feinster güte, wenn ich mir die mieserable leistung anschaue... wird halt auch in zukunft eher was für den ultramobile sektor bleiben(= smartphone/tablet)
Huawei hat mit dem HiSilicon Hi1620 gerade ARM Server CPUs vorgestellt und die fertigen viel Endgeräte für die ganze Netzwerkinfrastruktur, die könnten selbst genug davon gebrauchen damit sich das Geschäft lohnt, selbst wenn sie keine oder kaum CPUs an andere Abnehmer verkauft bekommen. Eine gewisse Nische für ARM Server mag es geben, aber die dürfte so klein sein das da nicht viel Platz für mehrere Anbieter bleibt.
incurable schrieb:
Qualcomm ist aktuell mit $80 Milliarden (deutsche, nicht US) bewertet, vor 2 Monaten waren es noch doppelt so viel.
Die Aktienmärkte allgemein und vor allem die Techwerte sind in der letzten Zeit massiv gefallen.
lynx007 schrieb:
Das sich AMD schwer tut könnte sich jetzt bald ändern wen Intel nicht schnell genug vom Monodiedesign weck kommmt.
Wieso? Gerade das Monodiedesign ist der große Vorteil für die Nutzer, der bisherige Ansatz von AMD bringt dem Nutzer technisch nur Nachteile und nur AMD hat einen Vorteil bei den Kosten. Wie das mit dem neuen Konzept von Rome mit den Chiplets und dem zentralen I/O Chip wird, muss man abwarten.
andi_sco schrieb:
Das man in solchen Bereichen Sitzfleisch braucht, kommt wohl am Gabentisch der Aktienbesitzer nicht gut an.
Damit outest Du Dich schon mal klar als jemand der keine Aktien besitzt, denn Aktionäre haben sehr von Verständnis dafür das Unternehmen erst investieren müssen bevor sie Gewinne machen können und haben auch Geduld, schau Dir nur an wie lange die Aktionäre vor Tesla auf Gewinne warten. Diese Geduld hört aber dort auf wo ein altes Sprichwort an der Börse anfängt zu greifen: „Wenn Du merkst, dass Du ein totes Pferd reitest, steig ab!”
 
Zuletzt bearbeitet: (technisch eingefügt)
  • Gefällt mir
Reaktionen: ^R4iD
  • Gefällt mir
Reaktionen: incurable
Holt schrieb:
...
Damit outest Du Dich schon mal klar als jemand der keine Aktien besitzt, ... und haben auch Geduld, schau Dir nur an wie lange die Aktionäre vor Tesla auf Gewinne warten. ...

Ja und? Muss ich dir jetzt meinen finanziellen Hintergrund erklären?

Oft genug hat der gemeine Angestellte das Gefühl, das erst die Aktionäre kommen, dann die Firma und irgendwann die Kunden und Angestellten.
Tesla kann man da eher als Ausnahme sehen. Wobei die ja noch gewisse Zeitvorteile gegenüber BMW und co. haben ;)
 
Die Aktionäre sind die Eigentümer einer Aktiengesellschaft, aber dies scheinen manche wohl nicht zu wissen oder verdrängen zu wollen.
 
  • Gefällt mir
Reaktionen: incurable
Holt schrieb:
Wieso? Gerade das Monodiedesign ist der große Vorteil für die Nutzer, der bisherige Ansatz von AMD bringt dem Nutzer nur Nachteile und nur AMD hat einen Vorteil bei den Kosten.

Steile These! Du musst schon mal erläutern in wiefern die aktuelle Verfügbarkeit von 16 Thread -64 Thread CPUs zu sensationellen Preisen für uns Kunden nur Nachteile hat.
 
Holt schrieb:
Die Aktionäre sind die Eigentümer einer Aktiengesellschaft, aber dies scheinen manche wohl nicht zu wissen oder verdrängen zu wollen.

Das vergesse ich nicht! Du brauchst trotzdem Angestellte und Kunden um Geld zu verdienen.
 
beercarrier schrieb:
Naja die Mitarbeiter aus R&D werden jetzt im Win on Arm bzw ChromeOS Projekt sitzen und die einzelnen Kerne erst mal hochzüchten. Nur weil im Serverbereich fast alle Software gut parallelisierbar ist heißt das nicht das Singlethread Perfomance verachtet wird. Aber es war von Anfang an ein sehr ambitioniertes Projekt. Neben den ganzen CPU´s benötigt man ja noch die komplette Infrastruktur und die passende Software. Da hat es Amazon deutlich leichter weil sie das Komplettpaket anbieten.
Von Single Thread Leistung hast du in Servern aber ohnehin nicht viel. Wie sieht so ein m5.24xlarge aws Instanz aus die hat 96 Thread fast 400GB Arbeitspeicher. Wenn du jetzt eine kleinere Instanz nimmst, wie eine m5.xlarge dann bekommst du einfach nur einen Teil von dem Server. In der Regel läuft dann ein Docker container der vielleicht 1-2 Threads braucht drauf auf einem Cluster von ein paar kleinen Instanzen (du braucht ja ein paar in unterschiedlichen Regions). Dann hast du 20-30 Container. Ob das Programm das da läuft viel Single Threaded Leistung hat ist egal. Auf dem fast 100 Thread Server laufen 6 Container von dir und 30 von irgendwem und du nutzt halt deinen 20 Threads meist eh nur zu 2-30%.
Wir sind von c5 auf t3 umgestiegen, weil der Performanceunterschied vernachlässigbar war. An einer Stelle waren es 6 statt 4 ms Latenzen. In 99% der Restlichen Fälle gabs keinen Unterschied. In der Regel musst du es Softwareseitig richten wenn die Leistung pro Thread nicht reicht, weil dann hast du ohnehin ein Problem. Für alles andere wo du viel Leistung brauchst, (machine Learning & Co) da lastet du soundso fast immer alle Threads zu 100% aus, da ist zwar eine c5 in Preis/Leistung besser aber Single Threaded Performance ist da egal.
Cool Master schrieb:
War abzusehen. Würde es keine Software geben welche die Serverbetreiber brauchen/nutzen könnte man überlegen auf ARM Basis die SW zu programmieren aber so ist es halt nicht. Dazu kommt, dass man mit x86_64 einfach deutlich flexibler ist als mit ARM.
Aber das stimmt ÜBERHAUPT nicht. Es gibt extrem viel Software die tadellos auf ARM läuft im Server Umfeld. Zum einen läuft fast alles auf Java was backend ist und das läuft einfach so auf ARM. Bei uns im Unternehmen läuft absolut nichts in AWS das nicht auch auf ARM laufen würde. Ich würde behaupten das stimmt auch für 90% aller kleineren jüngeren Unternehmen die nicht Altlasten migriert haben.
C programme wenn sie Open Source sind gibt es meist für ARM.
z.B. PostgreSQL läuft auf ARM. Redis läuft auf ARM. (btw selbst Oracle unterstützt theoretisch ARM)
Webserver und Frameworks PHP, Python, Ruby, Go, Rust, ... laufen alle auf ARM.

Im Endeffekt fast alle was Open Source und alles das man selbst Programmiert (in einer modernen Sprache) läuft problemlos auf ARM. Man musst nicht für ARM programmieren man muss es nur als compile target einstellen, wenn man Rust,Go,C kompiliert, bei Java, PHP, Python, JavaScript muss nur der container in dem es läuft passen.

Die Frage im Server Umfeld ist was läuft nicht auf ARM?
Bei Python ist es kein Problem wenn man rein in Python bleibt, wenn dann aber alle möglichen C libs geladen werden, wie in anaconda kann es etwas komplizierter werden. Die müssen dann für z.B. ARMv8 verfügbar sein und vorallem muss man die richtigen deployen.
Es gibt sicher kommerzielle Software die man nur einkauft die nicht für ARM kompiliert und getestet wird.

Für Entwickler wären dann ARMv8 Notebooks wie Chromebooks praktisch, oder ARM build server damit man beim build keinen Murks macht.


Man darf Server nicht mit Windows vergleichen. Bei Windows erstellt eine Softwareschmiede ein Programm und liefert die executables die nur für x86 sind. Apple hat z.B. verlangt bei ihrem PowerPC umstieg das alle immer beide binaries liefern mussten für eine Weile. Bei Apple ging das, bei MS ist viele alte Software in Verwendung die keiner mehr updated.
Auf Windows gibts aber auch schon viel mehr ARM. Chrome ist fast soweit, Office soundso, Media player auch. Sobald es wirklich einen Grund gibt ARM native Apps auszuliefern werden es viele Softwarehersteller auch tun. Der Aufwand ist meist nicht so groß wenn die Programme aktuell sind und noch weiterentwickelt werden.

Chromebooks laufen schon jetzt gut auf ARMs. Ich finde es geht einem nichts mehr ab an so einem Gerät. Google Docs/Calc... browser, media player, ...
So lange man nichts gegen Google hat gehts ja und wenn dann lädt man sich Linux drauf.
Bei Windows werden alle Bereiche die Chromebooks heute abdecken wohl auch als erstes ARMv8 native Unterstützung bekommen. Der Rest wird noch lange dauern, aber x86 Notebooks wirds auch noch lange geben.
 
  • Gefällt mir
Reaktionen: Mextli
andi_sco schrieb:
Du brauchst trotzdem Angestellte und Kunden um Geld zu verdienen.
Nur kann es sich ein Unternehmen nicht auf Dauer leisten Angestellt zu behalten, wenn sie mit deren Arbeit eben kein Geld verdienen, wonach es hier ja aussieht und es daher die ganze Abteilung in der diese Angestellten beschäftigt sind, eben schließt und von 1000 auf 50 zu reduzieren kommt einer Schließung ja sehr nahe. Der Rest dürfte wohl dazu da sein die Supportverpflichtungen gegenüber den Kunden einzuhalten.
 
Holt schrieb:
Wieso? Gerade das Monodiedesign ist der große Vorteil für die Nutzer, der bisherige Ansatz von AMD bringt dem Nutzer nur Nachteile und nur AMD hat einen Vorteil bei den Kosten. Wie das mit dem neuen Konzept von Rome mit den Chiplets und dem zentralen I/O Chip wird, muss man abwarten.

Welche Nachteile? Und warum will Intel jetzt selbst MCMs rausbringen wen sie so schlecht wären? Und warum sollte nur AMD den Kostenvorteil haben? Um so größer der Die um so teurer wird er. Und das im Quadrat. Das gleiche Problem hat jeder Hersteller, auch Intel. MCM mag siche rnicht in jeden Anwendungsbereich passen. Aber muss es das?
Das MCM Threadripper wiederum nicht in jeden Anwendungsbereich genauso gut wie Monodies abschließen mag ja sein. Aber sind sie deshalb auch in jedem Anwendungsbreich auch grundsätzlich unterlegen? Insbesondere wen sie weniger als die hälfte kosten?


http://www.pcgameshardware.de/Casca...cessor-56-Kerne-Multi-Chip-Modul-MCM-1258756/
https://en.wikipedia.org/wiki/Multi-chip_module
 
Zuletzt bearbeitet:
lynx007 schrieb:
Welche Nachteile?
Höhere minimale Latenzen sowohl beim Zugriff auf Speicher und I/O als auch bei der Kommunikation zwischen den Kernen.

Rome mit seiner Northbridge, durch die alle (1S) bzw. ein gros der (>1S) Informationen des ganzen Systems laufen müssen, erinnert im Systemdesign schon frappierend an frühe Xeons von vor 20 Jahren. (jaja, point to point vs shared bus :p)
 
Zurück
Oben