ARM: Windows muss kompatibel werden

[mRAC [HWLUXX]]

<img style="margin: 10px; float: left;" alt="hardwareluxx_news_new" src="images/stories/logos/hardwareluxx_news_new.jpg" height="100" width="100" />Seit langer Zeit ist Windows lediglich x86-Kompatibel und <a href="http://www.microsoft.com/germany/" target="_new">Microsoft</a> scheint wenig interessiert an einer Portierung auf andere Plattformen. Bob Morris von ARM ist jedoch anderer Meinung: Wenn es nach ihm geht, sollte Microsoft die Entscheidung schnellstens überdenken. So sollen 2013 Dreiviertel aller mobilen Geräte mit ARM-Prozessoren ausgestattet sein und zu einer Marktführung kein Weg an einem Betriebssystem für entsprechende Geräte vorbeigehen. Zwar ist das Vorhaben, Windows für eine andere Plattform zu portieren, ein kostspieliges Unterfangen, soll sich aber -...<p><a href="/index.php?option=com_content&view=article&id=12735&catid=34&Itemid=99" style="font-weight:bold;">... weiterlesen</a></p>

 

[Hadan_P]

Ist nicht Windows Mobile zu ARM kompatibel?

 

[Gani]

Ich will doch gar kein windows auf mobil-krücken. Nicht mal windows mobile mag ich haben...

 

[Opteron]

Ist nicht Windows Mobile zu ARM kompatibel?

Jo, aber Windows Mobile ist zu nix kompatibel

Bei der Meldung fehlt auch ein wichtiger Punkt ... auf nem ARM Win laufen noch lange keine x86 Win Programme ...

Bei Linux kann man zwecks OpenSource wenigstens noch selbst kompilieren, bzw. es findest sich immer einer für die wichtigen Sachen .. aber bei Win .. viel Spass.

ciao

Alex

 

[BloodredSandman]

Naja es wird sich bestimmt eine Firma finden, die dann mal eben iwas nützliches für Windows ARM rausbringt und dann wollen alles anderes das auf einmal auch... das ist doch windows, da will jeder sein Süppchen mitkochen....
Also um genug Programme mache ich mir keine Sorgen...nur ob die was taugen

 

[CommanderDuplex]

windows sollte ein GPU version rausbringen bei der die GPU nativ mitbeschleunigt , so das man später mit Lynfield z.b deutliche performance steigerungen hätte da man 1. eine CPU hat , und 2. eine GPU die beiedes nur für Windows beschleunigen da sind

das wäre viel wichtiger als ARM

 

[KeinNameFrei]

Eine GPU ist aber denkbar ungeeignet für normale Rechenaufgaben und würde wahrscheinlich höchstens die CPU auf Ergebnisse warten lassen, anstatt das System zu beschleunigen.

GPUs sind gut darin, extremst simple Aufgaben massiv Parallel auszuführen. So kann zum Beispiel ein Shaderprozessor mit einer Schleife oder Sprunganweisung nur wenig anfangen (Und wenn, dann rechnet er sich daran dumm und dämlich). Wenn man dem Shaderprozessor aber sagt, er soll einen Bildpunkt eines Bildes, das gerade in der Größe skaliert wird, umtransformieren - das macht er dann. Dabei ist er immer noch etwas langsamer als ein x86-CPU-Kern, allein vom Takt her... allerdings hat so ein Shader z.B. auf einer Radeon 4870 dann noch 799 Brüder, die genau dasselbe in genau derselben Zeit durchführen. Und die CPU hat eben nur noch maximal 3 weitere Kerne, die zwar schneller getaktet sind, aber von der schieren Masse der Shader schlichtweg plattgemacht werden.

Deswegen nimmt man GPU-Berechnung für Videokodierung und Grafikfilter, aber nicht für Alltagsaufgaben des Betriebssystems!

 

[Lord]

So kann zum Beispiel ein Shaderprozessor mit einer Schleife oder Sprunganweisung nur wenig anfangen (Und wenn, dann rechnet er sich daran dumm und dämlich).

Ein Shader ist im wesentlichen eine FP-ALU, in manchen Fällen auch vektorfähig, aber das ist erstmal egal. Natürlich kann die mit einer Branch Instruction nichts anfangen. Das ist aber beim Prozessor genauso, dessen ALU(s) können mit derartigen Befehlen auch nichts anfangen. Es ist die Steuerlogik bzw. eventuelle BCC-Units, die für Sprünge zuständig sind. Und Schleifen werden für gewöhnlich vom Steuerwerk unter Nutzung eines Indexregisters realisiert und das können "Shader" auch, die haben nämlich auch GPRs zur Verfügung. Das zeigt, wie irreführend der Begriff "Streamprozessor" eigentlich ist, denn ein Prozessor ist das im klassischen Wortsinn nicht, nur, weil da Datenstreams ge"processed" werden.

 

[[W2k]Shadow]

windows sollte ein GPU version rausbringen bei der die GPU nativ mitbeschleunigt , so das man später mit Lynfield z.b deutliche performance steigerungen hätte da man 1. eine CPU hat , und 2. eine GPU die beiedes nur für Windows beschleunigen da sind

das wäre viel wichtiger als ARM

dafür wird doch aktuell open-cl entwickelt, oder? ich mein, das ist nicht windows-nativ, aber gerade programme die damit was anfangen können, würde darauf zugreifen können, und dann würde dieses hickhack mit cuda udn stream ein ende haben

windows-nativ wäre zwar auch ne idee würde aber dann wohl bis 2013 auf sich warten lassen, dann lieber schneller und unabhängig von win, so kan mans auch auf linux einsetzen...

 

[KeinNameFrei]

Ein Shader ist im wesentlichen eine FP-ALU, in manchen Fällen auch vektorfähig, aber das ist erstmal egal. Natürlich kann die mit einer Branch Instruction nichts anfangen. Das ist aber beim Prozessor genauso, dessen ALU(s) können mit derartigen Befehlen auch nichts anfangen. Es ist die Steuerlogik bzw. eventuelle BCC-Units, die für Sprünge zuständig sind. Und Schleifen werden für gewöhnlich vom Steuerwerk unter Nutzung eines Indexregisters realisiert und das können "Shader" auch, die haben nämlich auch GPRs zur Verfügung. Das zeigt, wie irreführend der Begriff "Streamprozessor" eigentlich ist, denn ein Prozessor ist das im klassischen Wortsinn nicht, nur, weil da Datenstreams ge"processed" werden.

Jaja ist ja gut, ich wollt's einfach halten...

 

[H_M_Murdock]

windows sollte ein GPU version rausbringen bei der die GPU nativ mitbeschleunigt , so das man später mit Lynfield z.b deutliche performance steigerungen hätte da man 1. eine CPU hat , und 2. eine GPU die beiedes nur für Windows beschleunigen da sind

das wäre viel wichtiger als ARM

Dafür gibts ab Windows 7 DirectX 11.
Siehe dazu auch: http://www.pcgameshardware.de/aid,6...der-Grafikkarte-unter-Windows-7/Windows/News/

 

[A.l.e.x]

Bei der Meldung fehlt auch ein wichtiger Punkt ... auf nem ARM Win laufen noch lange keine x86 Win Programme ...

Naja, wenn ein Programm auf ein Framework oder VM setzt, ist das kein Problem.

Beispielsweise müsste ein Tool das in Visual Basic 2008 auf einem x86/x64 PC gemacht ist problemlos auf einem IA64 Rechner laufen, da das Framework ja alles passend übersetzt.

 

[[W2k]Shadow]

jupp schon, aber da skostet auch einiges an leistung,
wenn man das auf so "schwachen" arm-systemen auch tut, wirds siche rnicht gerad ene freude :-\
muss man halt im einzelfalls ehen, abr alles ist da siche rnicht sinnvoll.
andererseist braucht man aufm "handy" auch keien high-end software

 

[Opteron]

Naja, wenn ein Programm auf ein Framework oder VM setzt, ist das kein Problem.

Huh .. VM auf nem ARM Chip ... das kann lustig werden ... v.a. muss x86 emuliert werden, das ist was ganz andres Programmierkaliber, als eine x86 VM auf nem x86 Rechner.

Beispielsweise müsste ein Tool das in Visual Basic 2008 auf einem x86/x64 PC gemacht ist problemlos auf einem IA64 Rechner laufen, da das Framework ja alles passend übersetzt.

Tja ... aber so ein Framework gibts halt noch nicht, abgesehen von GCC, aber welche Profischmiede programmiert schon damit.

@[W2k]Shadow:
Rechenleistung sollte genug vorhanden sein, gibt auch schon ARM QuadCores in der Pipline ;-)

ciao

Alex

 

[[W2k]Shadow]

schon, aber ein kleiner handheld wird immer nur nen bruchteil derleistung eines desktops bieten, udn es gibt programme die auf dem framework aufsetzen und nen desktoprechne rgut auslasten, sowas würde nen arm einfach überfordern,
die frage ist dann natürlich, brauch man das auf nem handheld