Forum: PC Hard- und Software x86/x64 vs. ARM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus (Gast)


Lesenswert?

Hi Leute,

mal eines Vorweg: Ich will hier jetzt keine generelle Diskussion pro / 
contra Apple führen.

Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt, dass 
Apple nächste Woche auf der WWDC bekannt geben wird, dass zukünftige Mac 
Plattformen wahrscheinlich auf ARM statt auf Intel CPUs aufsetzen 
werden.
Das heißt also, Apple wird die CPUs selber designen.

Als Hauptargument wird dort immer wieder Energieeffizienz genannt.


Jetzt stelle ich mir nur so paar Fragen:

1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von 
ARM

2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein 
Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz

-> Muss also eine ARM CPU einen vergleichbar komplexen Algorithmus wie 
eine Intel-CPU rechnen (und man hat vergleichbare Technologiegröße + 
Taktfrequenz) müsste doch eigentlich ARM immer im Nachteil liegen?

Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie 
einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung 
auskommen soll.

von auweia (Gast)


Lesenswert?

> dass zukünftige Mac Plattformen wahrscheinlich auf ARM

Das ist mir sowas von voellig egal.
Der Obstkonzern spielt bei Plattformen die "echte" Leistung
bringen schon lange keine Rolle mehr.

von (prx) A. K. (prx)


Lesenswert?

Markus schrieb:
> 1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von
> ARM

x86 schleppt eine lange Geschichte von Architekturvarianten und 
Befehlssatzerweiterungen mit rum. Das macht den Befehlssatz vor allem 
grösser und die CPU aufwändiger, aber nicht zwingend mächtiger. Dafür 
hat ARMv8 32 Register, amd64 nur 16.

Interessanter als der skalare Befehlssatz ist der Vektor-Kram, also 
beispielsweise die SSE-Varianten. Wenn man das brauchen kann.

> 2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein
> Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz

Und zwar multipliziert mit der Anzahl pro Takt schaltender Komponenten. 
Ebendort liegt der Hase im Pfeffer, denn x86 ist wesentlich aufwändiger 
zu dekodieren. Das war allerdings früher bedeutender als heute.

> Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie
> einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung
> auskommen soll.

Wieso ohne Kühlung?

Geh davon aus, dass Macs auf ARM-Basis andere CPUs verwenden werden, als 
jene in den iPhones. Die Cores könnten vielleicht die gleichen sein, 
zumal anfangs, aber dafür mehr Cores bei höherer Taktfrequenz. Mit 
Kühlung. Je nach Zielmarkt des Gerätes mit niedrigen TDPs für extrem 
leichte Notebooks und Prozessoren mit zig Watt für Desktops.

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Vor Jahren sind sie den umgekehrten Weg gegangen.
Weil die exklusive Hardware zu teuer wurde.
Warum nicht wieder anders, wenn die Bedingungen stimmen?

von (prx) A. K. (prx)


Lesenswert?

Wenn man sich die Performance-Daten von Apples Prozessoren in den 
iPhones ansieht, dann entsteht der Eindruck, dass Apple einen verdammt 
guten Job macht. Sie haben die wohl leistungsfähigsten Cores aller in 
Handys verbauten ARMs, bei vergleichbarem Stromverbrauch.

Samsung hat natürlich auch das nachzumachen versucht, mit den 
vollständig selbst entwickelten M1..M6 Cores. Aufgrund chronischer 
Erfolglosigkeit wurde das aber im Herbst letzten Jahres eingestellt. 
Samsung hat es nicht geschafft, die durchaus höhere Leistungsfähigkeit 
dieser Cores so umzusetzen, dass dabei für den Anwender mehr Leistung 
bei ähnlicher Akkulaufzeit rauskam - im Gegenteil.

Wer sich für Details zum Unterschied zwischen den Samsung- und 
Qualcomm-Prozessoren interessiert, der sollte sich die Artikel von 
Andrei Frumusanu von Anandtech über die beiden CPU-Varianten des Galaxy 
S9(+) ansehen.

: Bearbeitet durch User
von oerks (Gast)


Lesenswert?

> Weil die exklusive Hardware zu teuer wurde.
> Warum nicht wieder anders, wenn die Bedingungen stimmen?

Die PowerPC-Architektur war fuer Apple ein intellektuelles
Zukaufteil. Keine Chance um es mit eigenen Resourcen nennenswert
zu verbessern. Das PowerPC nicht tot ist, beweisen aktuelle
Modelle der IBM.

Wenn ich mir aber Rechner wie den neuen Mac Pro ansehe, habe ich so
meine Zweifel ob die Rechnung da aufgeht.
Sinnarmes "Designer-"Zubehoer steht mit 3-4 stelligen Summen
in der Preisliste. Die Kunden die wirklich Leistung brauchen,
werden Apple nicht mal im Ansatz in Erwaegung ziehen.
Und Software fuer ARM in diesem Umfeld steht auch noch nicht
bereit.

> Performance-Daten von Apples Prozessoren in den iPhones ansieht

Das ist ein Consumerspielzeug. Vielleicht sehr leistungsfaehig.
Aber trotzdem nur ein Conumserspielzeug.

von Operator S. (smkr)


Lesenswert?

Markus schrieb:
> Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt, dass
> Apple nächste Woche auf der WWDC bekannt geben wird, dass zukünftige Mac
> Plattformen wahrscheinlich auf ARM statt auf Intel CPUs aufsetzen
> werden.

Wenn das so ein Fakt ist, wo ist dann die Quelle?

Meines Wissens ist das Gerücht, sie steigen von Intel auf AMD um (!= 
ARM)
Und da bleibt die Architektur erstmal gleich.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

oerks schrieb:
> Aber trotzdem nur ein Conumserspielzeug.

Deine Meinung sei dir unbenommen (wenngleich sie auf die Fragen des TE 
in keiner Weise eingeht), aber die Einhaltung der Forenregeln ist auch 
für dich erforderlich: ein Name pro Thread bitte.

von Radar mit der Rute (Gast)


Lesenswert?

Markus schrieb:
> Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie
> einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung
> auskommen soll.

Naja, weil für den Computernutzer von heute die Performance der CPU's 
von vorgestern völlig ausreichend ist.

Und die Anwendungen die wirklich Performance brauchen, sind eh nicht für 
Apples verfügbar. bspw FPGA-synthese.

>2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein
>Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz

Ach, je kleiner die Struktur, desto geringer die Verlustleistungen? - ja 
wenn es die leckströme nicht gäbe.

von Radar mit der Rute (Gast)


Lesenswert?

https://www.zdnet.de/88380636/bericht-apple-stellt-plaene-fuer-eigene-cpus-in-macs-auf-der-wwdc-vor/#:~:text=Die%20ersten%20Mac%20mit%20Apples,zufolge%202021%20auf%20den%20Markt.&text=Apple%20soll%20anl%C3%A4sslich%20seiner%20Entwicklerkonferenz,f%C3%BCr%20seine%20Mac%2DComputer%20ank%C3%BCndigen.

Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in 
seinem Computern gewechselt sondern viermal:

6502->68k->PowerPC->intel

Falls man den Newton PDA hinzuzählt wäre es eine fünfte, und mit den 
pod/pads/tablets ARM als sechste CPU-Familie im Portfolio.

von (prx) A. K. (prx)


Lesenswert?

Radar mit der Rute schrieb:
> Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in
> seinem Computern gewechselt sondern viermal:
>
> 6502->68k->PowerPC->intel

Zähl lieber noch einmal nach. Die Wechsel, also die Pfeile, nicht die 
CPU-Familien. ;-)

Und wenn du den 6502 mitrechnest, der ja kein Mac antrieb, dann ist ARM 
nichts Neues, denn den haben sie schon in den iPhones.

: Bearbeitet durch User
von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Sie hatten auch noch 6809 und VAX probiert.

von Radar mit der Rute (Gast)


Lesenswert?

A. K. schrieb:
> Radar mit der Rute schrieb:
>> Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in
>> seinem Computern gewechselt sondern viermal:
>>
>> 6502->68k->PowerPC->intel
>
> Zähl lieber noch einmal nach. Die Wechsel, also die Pfeile, nicht die
> CPU-Familien. ;-)

Hehe, ich zähl von Undefiniert auf Init-Zustand (hier 6502) auch als 
Wechsel, isse wohl Berufskrankheit ;-)

> Und wenn du den 6502 mitrechnest, der ja kein Mac antrieb, dann ist ARM
> nichts Neues, denn den haben sie schon in den iPhones.
Nee, iphone war nicht das erste ARM-Geschoß bei Apple, davor gabs es 
IPod (ARM7TDMI) und davor der Newton (ARM610-StrongARM). Und ARM ohne 
Apple reicht sogar noch weiter zurück, zum Acorn Archimedes und so (Ja 
das A in ARM, steht nicht für Apple, sondern für Acorn).

Aber OK, manche sagen Apple ohne Steve Jobs war nicht Apple und lassen 
den Newton unter den Tisch fallen (so wie Steve Jobs es bei seiner 
Rückkehr tat).

>Sie hatten auch noch 6809 und VAX probiert.
VAX ist mir neu, da lern ich gern zu, 6809 war die kaputtgesparte Spec 
von Jef Raskin für den Ur-Mac, die glücklicherweise nie als 
Apple-Produkt realisiert wurde. Da war es Steve Jobs, der den 68k 
durchdrückte. Ohne diesen (zweiten) Schritt zum 68k wäre Apple nach dem 
Lisa-Desaster nie in die Profiliga aufgestiegen.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Den 6809 kippten sie, weil das geplante Mac-GUI darauf nicht 
realisierbar war.
Die VAX emulierte Macs, als sie QuickTime entwickelten und die Macs wohl 
zu der Zeit zu langsam waren.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

michael_ schrieb:
> Vor Jahren sind sie den umgekehrten Weg gegangen.
> Weil die exklusive Hardware zu teuer wurde.
> Warum nicht wieder anders, wenn die Bedingungen stimmen?

Ich glaube mich an die Rede von Steve Jobs zu erinnern, in der er den 
Weggang vom PowerPC zu Intel begründete. Grob vereinfacht ging es darum, 
dass Apple immer zuletzt und nur unzureichend beliefert wurde, weil 
PowerPCs gerade für die Server anderer Hersteller wie geschitten Brot 
gingen ... so nach dem Motto: Jetzt reichts!

von C. A. Rotwang (Gast)


Lesenswert?

Frank E. schrieb:
> Grob vereinfacht ging es darum,
> dass Apple immer zuletzt und nur unzureichend beliefert wurde, weil
> PowerPCs gerade für die Server anderer Hersteller wie geschitten Brot
> gingen ... so nach dem Motto: Jetzt reichts!

Da der heise-report zum Wechsel PPC->intel:
https://www.heise.de/ct/artikel/Apple-faellt-vom-Stamm-289950.html

Das Top-End (3 GHz, dualCore) hat IBM ewig nicht lieferbar bekommen, und 
mit intel als CPI hat man auch Zugriff auf deren Chipsätze, die nebenher 
einige wichtige Peripherie und integrierte Graphikbeschleuniger 
mitbrachten.

von xyz (Gast)


Lesenswert?

Jetzt ist es offiziell:

Macs werden auf ARM umgestellt.
Das heißt wohl dann auch Windows per Bootcamp wirds nicht mehr geben :(
https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/

von Rolf M. (rmagnus)


Lesenswert?

Markus schrieb:
> Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt

Na wenn wenigstens das Vorhandensein von Gerüchten ein Fakt ist…

A. K. schrieb:
>> 2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein
>> Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz
>
> Und zwar multipliziert mit der Anzahl pro Takt schaltender Komponenten.
> Ebendort liegt der Hase im Pfeffer, denn x86 ist wesentlich aufwändiger
> zu dekodieren. Das war allerdings früher bedeutender als heute.

Ja, schon alleine deshalb, weil trotz dieser Komplexität moderne CPUs eh 
vor allem aus Cache bestehen.

oerks schrieb:
>> Performance-Daten von Apples Prozessoren in den iPhones ansieht
>
> Das ist ein Consumerspielzeug. Vielleicht sehr leistungsfaehig.
> Aber trotzdem nur ein Conumserspielzeug.

Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in ganz anderen 
Leistungsklassen. Da frage ich mich schon, wie die mal kurz einen ARM 
aus dem Hut zaubern wollen, der es mit einem i7 oder einem aktuellen 
Ryzen aufnehmen kann. Und wo sie die "higher performance GPUs" aus ihrem 
Announcement her kriegen wollen, bleibt auch unklar. Was gibt's denn da 
aktuell, das schneller ist als die PC-Grafikchips von NVidia und AMD?

von Pandur S. (jetztnicht)


Lesenswert?

Einen eigenen Prozessor .. so, so. Es gab auch schon mal so eine Firma, 
eine Riesenfirma, sehr erfolgreich, die dachte als Marktfuehrer muessten 
sie was Eigenes haben.
Die Firma hiess DEC (Digital Equipment Corporation) der Prozessor 
Alpha-64, war als 64bit Controller gedacht. Extrem advanced in den 
mid-80ern. Irgendwie gibt's die Firma heute nicht mehr...

von Christoph Z. (christophz)


Lesenswert?

Die hatten auch nicht ein paar hundert Milliarden auf der hohen 
(offshore) Kante :-)

Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht 
gibts dann sogar noch RiscOS ;-)

von Dussel (Gast)


Lesenswert?

Markus schrieb:
> 1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von
> ARM
Ich bin in dem Thema nicht mehr so drin, aber ich glaube, dass RISC eher 
Vorteile hat.
Früher als die Compiler noch nicht so gut optimiert haben, war es gut, 
spezielle komplexe Befehle zu haben, die für komplexe Aufgaben 
aufgerufen werden konnten.
Heute optimieren die Compiler sehr gut und da ist man flexibler und 
nicht langsamer, wenn man die komplexen CISC-Befehle aus einer Reihe von 
RISC-Befehlen nachbaut.

von (prx) A. K. (prx)


Lesenswert?

Joggel E. schrieb:
> Einen eigenen Prozessor .. so, so. Es gab auch schon mal so eine Firma,

> Die Firma hiess DEC (Digital Equipment Corporation) der Prozessor
> Alpha-64, war als 64bit Controller gedacht. Extrem advanced in den
> mid-80ern. Irgendwie gibt's die Firma heute nicht mehr...

Nur sind die nicht so sehr an Alpha ersoffen, sondern am vorherigen 
Versuch, die VAX Architektur über das natürliche Ende ihrer 
architekturbedingten Zeitspanne hinaus am Leben zu erhalten. Da wurde zu 
viel Zeit und Geld drin versenkt.

Alpha war allerdings zu ziemlich das Gegenteil eines Controllers. Und es 
waren die 90er, nicht die 80er.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Dussel schrieb:
> Früher als die Compiler noch nicht so gut optimiert haben, war es gut,
> spezielle komplexe Befehle zu haben, die für komplexe Aufgaben
> aufgerufen werden konnten.

Bereits in den 70ern stellte IBM intern fest, dass die Compiler solche 
komplexen Befehle wenig bis überhaupt nicht verwendeten und eine 
einfacher aufgebaute RISC Maschine den Mainframes das Wasser abgesehen 
könnte.

Auch VAX Anwender, die sich in Assembler abmühten, nutzten hochkomplexe 
gut gemeinte Befehle hauptsächlich dann, wenn sie es nicht eilig oder 
keine Ahnung hatten. Denn zu Fuss wars meist schneller.

von Arno (Gast)


Lesenswert?

xyz schrieb:
> Jetzt ist es offiziell:
>
> Macs werden auf ARM umgestellt.
> Das heißt wohl dann auch Windows per Bootcamp wirds nicht mehr geben :(
> 
https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/

Das erste Argument ist dabei aber auch nicht "mehr Leistung" oder 
"weniger Energieverbrauch" sondern:

> This transition will also establish a common architecture across all Apple
> products, making it far easier for developers to write and optimize their
> apps for the entire ecosystem.

Ich halte es nicht für unmöglich, dass das sogar für Apple das 
wichtigste Argument ist.

Und es gibt durchaus Windows auf ARM. Muss also nicht das Ende für 
Windows per Bootcamp sein.

MfG, Arno

von Blechbieger (Gast)


Lesenswert?

A. K. schrieb:
> Alpha war allerdings zu ziemlich das Gegenteil eines Controllers. Und es
> waren die 90er, nicht die 80er.

Und lebt ein bisschen bei AMD weiter. Viele ehemalige DEC-Entwickler 
sind nach der Pleite zu AMD und haben entscheidend zum Athlon (oder war 
es der K6?) beigetragen.

von Rolf M. (rmagnus)


Lesenswert?

Arno schrieb:
>> This transition will also establish a common architecture across all Apple
>> products, making it far easier for developers to write and optimize their
>> apps for the entire ecosystem.
>
> Ich halte es nicht für unmöglich, dass das sogar für Apple das
> wichtigste Argument ist.

Warum? Ob man das jetzt für x86 oder ARM compiliert, ist doch für den 
Entwickler ziemlich egal. Intel hat bei seinen Atom-Prozessoren mal 
behauptet, der große Vorteil von x86 gegenüber ARM im Handy sei genau 
das, dass Entwickler leichter Code dafür schreiben und optimieren 
können. Hat dort auch schon nicht geklappt.

Es gibt aber den Vorteil, dass man für iPad compilierte Apps nativ auf 
dem Mac laufen lassen kann, was ja auch erwähnt wurde:
"And for the first time, developers can make their iOS and iPadOS apps 
available on the Mac without any modifications."

> Und es gibt durchaus Windows auf ARM.

Aber wie viele Programme laufen da auch drunter?

: Bearbeitet durch User
von Arno (Gast)


Lesenswert?

Rolf M. schrieb:
> Arno schrieb:
>>> This transition will also establish a common architecture across all Apple
>>> products, making it far easier for developers to write and optimize their
>>> apps for the entire ecosystem.
>>
>> Ich halte es nicht für unmöglich, dass das sogar für Apple das
>> wichtigste Argument ist.
>
> Warum? Ob man das jetzt für x86 oder ARM compiliert, ist doch für den
> Entwickler ziemlich egal. Intel hat bei seinen Atom-Prozessoren mal
> behauptet, der große Vorteil von x86 gegenüber ARM im Handy sei genau
> das, dass Entwickler leichter Code dafür schreiben und optimieren
> können. Hat dort auch schon nicht geklappt.

Den ersten Teil, "common architecture across all Apple products". Ob das 
den Entwicklern von Apps etwas bringt, wage ich zu bezweifeln, aber 
intern für Apple könnte es etwas bringen. Sorry, das habe ich nicht klar 
herausgestellt.

MfG, Arno

von Rolf M. (rmagnus)


Lesenswert?

Arno schrieb:
> Den ersten Teil, "common architecture across all Apple products".

Ach so. Na dann stimme ich dir zu.

von S. R. (svenska)


Lesenswert?

Rolf M. schrieb:
> Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in
> ganz anderen Leistungsklassen. Da frage ich mich schon, wie
> die mal kurz einen ARM aus dem Hut zaubern wollen, der es mit
> einem i7 oder einem aktuellen Ryzen aufnehmen kann.

Man kann aktuelle Smartphone-CPUs durchaus als gebrauchbare Buildserver 
benutzen - wenn man da entsprechende Kühlung ranflanscht. Was natürlich 
mit dem Smartphone-Formfaktor nicht geht, weil niemand mit einem 
70°C-Telefon in der Tasche umherlaufen will.

A. K. schrieb:
> Bereits in den 70ern stellte IBM intern fest, dass die Compiler
> solche komplexen Befehle wenig bis überhaupt nicht verwendeten
> und eine einfacher aufgebaute RISC Maschine den Mainframes das
> Wasser abgesehen könnte.

Naja, und heute haben wir eine RISC-Architektur namens ARM mit so 
Befehlen wie "FJCVTZS" ("Floating-point Javascript Convert to Signed 
fixed-point, rounding toward Zero"). Ich weiß ja nicht.

Alle 10 Jahre muss Krypto erneut verboten werden.
Alle 30 Jahre müssen CISC-CPUs neu erfunden werden?
(Natürlich immer unter anderem Namen, wissenschon.)

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

S. R. schrieb:
> Rolf M. schrieb:
>> Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in
>> ganz anderen Leistungsklassen. Da frage ich mich schon, wie
>> die mal kurz einen ARM aus dem Hut zaubern wollen, der es mit
>> einem i7 oder einem aktuellen Ryzen aufnehmen kann.
>
> Man kann aktuelle Smartphone-CPUs durchaus als gebrauchbare Buildserver
> benutzen - wenn man da entsprechende Kühlung ranflanscht. Was natürlich
> mit dem Smartphone-Formfaktor nicht geht, weil niemand mit einem
> 70°C-Telefon in der Tasche umherlaufen will.

Nun sind Apple-Rechner nicht die typischen Geräte, die man als 
Build-Server verwendet.
Soweit ich weiß, kann x86 im Bezug auf die Energiesparfunktionen nicht 
mit ARM mithalten, dafür kann ARM bei der maximalen Leistung nicht 
mithalten. Mein letzter Stand war, dass die schnellsten ARM-Prozessoren 
gerade so an die Einsteiger-CPUs von Intel ran reichen. Das kann sich 
inzwischen etwas geändert haben, aber dass sie flotter sein sollen als 
ein i5 oder gar i7, will ich erst sehen, bevor ich es glaube.

> A. K. schrieb:
>> Bereits in den 70ern stellte IBM intern fest, dass die Compiler
>> solche komplexen Befehle wenig bis überhaupt nicht verwendeten
>> und eine einfacher aufgebaute RISC Maschine den Mainframes das
>> Wasser abgesehen könnte.
>
> Naja, und heute haben wir eine RISC-Architektur namens ARM mit so
> Befehlen wie "FJCVTZS" ("Floating-point Javascript Convert to Signed
> fixed-point, rounding toward Zero"). Ich weiß ja nicht.

Naja, ich finde es eher krass, wie viele verschiedene Instruktionen es 
alleine gibt, um einen Wert von A nach B zu kopieren. Da sind dann so 
Sachen dabei wie:

CASPA - "Compare and Swap Pair of words or doublewords in memory."

Die Instruktion hat 5(!) Operanden. Die Beschreibung: "reads a pair of 
32-bit words or 64-bit doublewords from memory, and compares them 
against the values held in the first pair of registers. If the 
comparison is equal, the values in the second pair of registers are 
written to memory."

Also wenn das noch RISC sein soll, dann weiß ich auch nicht…

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Rolf M. schrieb:
> Mein letzter Stand war, dass die schnellsten ARM-Prozessoren gerade so
> an die Einsteiger-CPUs von Intel ran reichen.

Meldung von heute: "ARM-based Japanese supercomputer is now the fastest 
in the world"
https://www.theverge.com/2020/6/23/21300097/fugaku-supercomputer-worlds-fastest-top500-riken-fujitsu-arm

: Bearbeitet durch User
von René F. (therfd)


Lesenswert?

Ich habe keine Zweifel daran, das Apple den Architektur-Wechsel 
problemlos schafft (haben sie ja schon mehrfach bewiesen).

Die Frage ist eher ob die neuen Produkte von der vollen Markt-Breite 
angenommen werden. Die Fraktion Internet, Multimedia und Office wird den 
Wechsel vermutlich nicht einmal merken. Ich kann mir aber vorstellen, 
das im professionellen Bereich sich einige von Apple abwenden werden. 
Ich kenne einige die mit Macs ihr Geld verdienen und der Großteil hat 
ein virtualisiertes Windows zusätzlich am laufen.


Mich würde es interessieren wie sich in Zukunft die Hackintosh Szene 
entwickelt.

von Rolf M. (rmagnus)


Lesenswert?

A. K. schrieb:
> Meldung von heute: "ARM-based Japanese supercomputer is now the fastest
> in the world"

Ja, gut, der braucht dazu aber auch über 150.000 Prozessoren mit je 52 
Kernen. Die Frage ist, wie ein einzelner Kern so im Vergleich 
abschneidet, weil normale PC-Anwendungen größtenteils nicht 
hochparallelisierbar sind. Und das, was man sehr gut parallelisieren 
kann, wird eher in der Grafikkarte gerechnet.

René F. schrieb:
> Die Frage ist eher ob die neuen Produkte von der vollen Markt-Breite
> angenommen werden. Die Fraktion Internet, Multimedia und Office wird den
> Wechsel vermutlich nicht einmal merken.

Das kommt aber auch darauf an, wie schnell es die Anwendungen für ARM 
gibt, bzw. wie performant die x86-Emulation sein wird.

> Ich kann mir aber vorstellen,das im professionellen Bereich sich einige von
> Apple abwenden werden. Ich kenne einige die mit Macs ihr Geld verdienen und
> der Großteil hat ein virtualisiertes Windows zusätzlich am laufen.
>
> Mich würde es interessieren wie sich in Zukunft die Hackintosh Szene
> entwickelt.

Vielleicht gibt's dann MacOS für den Raspi.

von Gustl B. (-gb-)


Lesenswert?

oerks schrieb:
> Die PowerPC-Architektur war fuer Apple ein intellektuelles
> Zukaufteil. Keine Chance um es mit eigenen Resourcen nennenswert
> zu verbessern.

Da sollte man unterscheiden. Apple hat selber keine PPC entwickelt, sie 
haben die PPCs von IBM gekauft.
Aber sie haben eine Chipentwicklerbude gekauft. Und zwar PA-Semi. Und 
das zu Zeiten als Apple von PPC nach Intel gewechselt ist/war.

Meine Vermutung ist also, dass die auf Basis von ARM ihre eigenen SoCs 
bauen und gebaut haben - für die Mobilgeräte eben.

Operator S. schrieb:
> Meines Wissens ist das Gerücht, sie steigen von Intel auf AMD um (!=
> ARM)

Nein.
Allerdings ist auch unklar ob sie auf ARM umsteigen. Ja, Apple hat ARM 
Lizenzen und auch IP und zumindest am Anfang waren die iPhone SoCs 
ziemliche standard ARM CPUs.
Aber das hat sich deutlich geändert. Aktuelle Apple SoCs sind deutlich 
schneller als das was man mit dem bauen kann was man von ARM als IP 
bekommt.
Ich vermute, das wird zwar noch ein ARM oder ARMähnlicher Befehlssatz 
sein, aber sonst haben die die CPUs und GPUs im SoC stark verändert dass 
die nurnoch wenig mit dem gemeinsam haben was ARM als IP verkauft.

Arno schrieb:
> Ich halte es nicht für unmöglich, dass das sogar für Apple das
> wichtigste Argument ist.

Jap und auch, dass man möglichst viel der Herstellungskette in eigener 
Hand hat und aufeinander optimieren kann.

Das siehet man auch bei Tesla und Amazon, beide haben ihre eigenen Chips 
gebaut, Amazon für die Cloud und Tesla weil sie so ein deutlich 
schnellerers neuronales Netz haben als es mit Chips von Nvidia möglich 
wäre bei gleichzeitig geringerer Leistungsaufnahme (der Tesla IC hat 
ziemlich viel SRAM und eine extrem breitbandige Speicheranbindung).

Ich finde das auch die richtige Strategie. Während hier in Deutschland 
die Autobauer und Andere immer mehr outsourcen gibt es ein paar 
aufstrebende/wachsende Firmen die möglichst alles selber bauen wollen.

Tja wie ist das mit den Binarys?
Gar nicht so tragisch. LLVM und somit auch Xcode können Bitcode, das ist 
eine intermediate representation und unabhängig von der Architektur. 
Wenn man seine Software also schon als Bitcode gebaut hat oder Xcode das 
kann, dann kann man daraus recht einfach auch Binarys für eine andere 
Architektur bauen. Man kann sich das wohl so vorstellen wie webassambly. 
Also ein Binary, aber nicht für iregendeine real existierende 
Architektur, sondern nur um entweder nochmal auf eine Architektur 
übersetzt zu werden oder um in einer VM ausgeführt zu werden.
Jedenfalls hat Apple in den letzten Jahren ziemlich viel in diese 
Richtung getan und es würde mich nicht wundern wenn der Großteil der 
Apps problemlos neu kompiliert werden kann.

Tja und wie ist das mit Windows?
Nun, warum denn Windows auf dem Mac, da gibt es doch günstigere 
Hardware. Aber egal, Windows 10 gibt es für ARM und Apple hat mit 
Rosetta 2 einen echten Emulator für x86 der angeblich auch recht flott 
ist. Wenn man schon für manche Programme mit Rosetta 2 x86 anbietet, 
dann geht das vermutlich auch für ein ganzes OS. Bootcamp wird das aber 
nicht, Windows x86 wird wenn überhaupt in einer VM laufen.
Aber auch das mit dem ARM Windows ist fraglich. Ich vermute (oben), dass 
sich Apple in letzter Zeit ein ganzes Stück von dem standard-ARM 
entfernt hat. Ob da Windows also kompatibel ist zu dem eigenen Chip und 
ob man das überhaupt möchte und da Zeit und Geld investiert weiß ich 
nicht. Ich vermute nein.

von Rolf M. (rmagnus)


Lesenswert?

Gustl B. schrieb:
> Allerdings ist auch unklar ob sie auf ARM umsteigen.

Hmm, das ist ein gute Punkt. Der Begriff "ARM" kommt in dieser 
Ankündigung von Apple nicht vor. Es ist immer nur von "Apple silicon" 
die Rede.

: Bearbeitet durch User
von Jemand (Gast)


Lesenswert?

Gustl B. schrieb:
> LLVM und somit auch Xcode können Bitcode, das ist
> eine intermediate representation und unabhängig von der Architektur.
> Wenn man seine Software also schon als Bitcode gebaut hat oder Xcode das
> kann, dann kann man daraus recht einfach auch Binarys für eine andere
> Architektur bauen.

LLVM IR ist nicht platformspezifisch, generiertes IR ist aber meist 
NICHT platformunabhängig!

von Gustl B. (-gb-)


Lesenswert?

OK, ich kenne mich da nicht wirklich aus, ich habe das vor ein paar 
Jahren gelesen und da wurde das als großer Schritt von LLVM gefeiert und 
schon damals (2015) gemutmaßt, dass Apple bald auf ARM umsteigen wird.

Und seit spätestens 2017 erlaubt Apple im Appstore nur noch Apps mit 
Bitcode. Ich habe gelesen, dass Apple die App dann besser auf das Gerät 
optimieren kann. Ob sie die App dann auch noch für eine andere 
Architektur bauen könnten ist für mich unklar. Wäre aber cool. Also wenn 
der Entwickler die App nur als Bitcode abliefert und Apple die dann 
einmal für alle Geräte übersetzt.

von (prx) A. K. (prx)


Lesenswert?

Also so wie Google das seit Jahren bei Android macht. Der Entwickler 
liefert generischen Code, die Maschine setzt den auf sich um.

Damit ist nämlich auch eine Optimierung  für die konkrete Version des 
Prozessors möglich. Und - heute nicht unwichtig - das Umschiffen von 
später erkannten Prozessorproblemen auch für bestehende Anwendungen.

: Bearbeitet durch User
von Hubert (Gast)


Lesenswert?

Ich denke auch - es wird in Richtung Emulation gehen.

Ich habe privat ein 13" MBP von 2014. Nutze es zusammen mit einem 27" 
Thunderbolt Display auch an meinem Schreibtisch.
Das ist aber nicht mein erster Mac. Ich war relativ am Anfang dabei als 
Apple auf Intel rübergegangen ist.

Für mich die absolute Traumkombi bisher! Habe dadurch faktisch ein 
MacBook und oder quasi ein iMac und dazu zwei Betriebssysteme.
Quasi ein 4 in 1.

Normalerweise nutze ich immer das Mac OS.
Wenn ich aber produktiv was basteln will (Altium, Xilinx Vivado, ADI 
SigmaStudio, uC programmieren, 3D CAD, etc.. pp..) dann habe ich immer 
Windows  im Backup.

Ich beobachte schon die ganze Zeit was Apple macht, da mein Laptop jetzt 
schon 6 Jahre auf dem Buckel hat, aber prinzipiell noch absolut ohne 
Probleme läuft. Ein neuer Mac ->war<- daher die ganze Zeit schon mehr 
oder weniger auf meiner Investmentliste gestanden für die nächsten 1-2 
Jahre.

Ich bin aber seit einiger Zeit auch schon mit der Preispolitik nicht 
mehr so ganz einverstanden.

Mein MBP (i5, 8GB ram, 256Gb SSD) habe ich 2014 für 1149 Euro gekauft 
wenn ich mich recht erinnere.
Heute geht das MBP bei 1499 Euro los und hat mehr oder weniger immer 
noch die gleichen Specs wie mein MBP damals (8GB ram und 256GB ssd)... 
Ok um fair zu bleiben, es gibt inzwischen einen quad-core im Basismodell 
statt eines dual-cores.
Will ich zumindest etwas 2020-mäßiges haben, also 16GB ram + 1TB ssd, 
ist man gleich > 2000 euro los.


Jetzt nochmal einen Mac mit Intel kaufen? Ich weiß es nicht. Damals beim 
PPC auf Intel Umstieg hat Apple den OS Support bereits 3 Jahre nach der 
Übergangsphase eingestellt.
Wenn Apple jetzt mit der Transition anfängt und man gutmütig die 
Übergangszeit rausrechnet, wäre also 2025 Supportende.

Werde ich mich wohl oder übel wirklich mal wieder nach normalen Laptops 
umschauen müssen.

von Gustl B. (-gb-)


Lesenswert?

A. K. schrieb:
> Damit ist nämlich auch eine Optimierung  für die konkrete Version des
> Prozessors möglich. Und - heute nicht unwichtig - das Umschiffen von
> später erkannten Prozessorproblemen auch für bestehende Anwendungen.

Exakt das ist ein großer Vorteil und wenn man sowieso nurnoch Appstores 
hat dann ist das ein bequemer Weg.

Hubert schrieb:
> Ich war relativ am Anfang dabei als
> Apple auf Intel rübergegangen ist.

Da war ich auch dabei. 2006 mit einem Hackintosh auf AMD Venice CPU und 
mit Nvidia 5200 iirc. Und dann 2007 mit einem MBP. Aber da ist dann 
leider zuerst DVD Laufwerk, dann Akku und am Ende auch noch die Nvidia 
GPU gestorben. Danach hab ich mir einen Mac Mini 2011 geholt.

Hubert schrieb:
> Werde ich mich wohl oder übel wirklich mal wieder nach normalen Laptops
> umschauen müssen.

Ich bin nie komplett von Windows weg, eben weil ich das für manche 
Software brauche. Bootcamp hatte ich probiert, aber eigentlich finde ich 
zwei Geräte sehr fein. Ich habe hier den alten Mac Mini und ein Thinkpad 
auf dem Schreibtisch mit zwei Monitoren. Jeder Monitor ist sowohl mit 
dem Thikpad als auch mit dem Mac verbunden, ich kann also ganz einfach 
am Monitor einstellen welche Quelle ich haben will. Meist habe ich 
rechts Mac für Mail, Browser, iTunes, Skype und links Windows. Aber 
manchmal auch zweimal Mac oder zweimal Windows.
An einem kleinen Notebookdisplay würde ich nicht lange arbeiten wollen.

Edit:
Rechne mal damit, dass wenn du dir jetzt einen Intel Mac kaufst der noch 
einige Zeit unterstützt werden wird.
Aber du kannst auch den Umstieg von Apple abwarten und angucken wie der 
läuft und vor allem auch welche Software dann tatsächlich als Universal 
Binary angeboten werden wird und ob die dann neu kostet. Ich habe hier 
noch eine ältere Creative Suite von Adobe, wenn ich sowas auf Apple 
Silicon haben möchte dann muss ich das entweder emulieren lassen oder 
neu kaufen. Adobe wird das garantiert nicht kostenfrei anbieten. 
Nichtmal bei der neusten CS6 die jetzt auch schon alt ist, die wollen 
ihr Creative Cloud Abo verkaufen. Genauso auch bei Microsoft Office. Da 
kann man entweder eine neue Version kaufen oder eine alte mit Rosetta 2 
nutzen.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Lesenswert?

Rolf M. schrieb:
> Soweit ich weiß, kann x86 im Bezug auf die Energiesparfunktionen nicht
> mit ARM mithalten, dafür kann ARM bei der maximalen Leistung nicht
> mithalten. Mein letzter Stand war, dass die schnellsten ARM-Prozessoren
> gerade so an die Einsteiger-CPUs von Intel ran reichen.

So ungefähr. Ich habe vor 2 Jahren mal einen (damals) state-of-the-art 
ARM Server von Qualcomm mit einem schon etwas abgehangenen Xeon E5 
Server verglichen. Der Testfall war ein RDBMS und der ARM Server 
lieferte im Schnitt 20% mehr Durchsatz als der Intel Server. Allerdings 
hatte der ARM Server 48 echte Kerne (davon 46 nutzbar) und der Intel 
Server 16 echte Kerne, aber 32 Threads dank Hyperthreading.

Besonders bemerkenswert fand ich das Skalierungsverhalten. Intel 
lieferte dank Turbo Boost sehr beachtliche Leistungen in single-thread 
Benchmarks. Aber wenn mehrere Threads aktiv waren, dann sackte der 
Durchsatz per Core (respektive Hyperthread) schnell ab. Von 1 bis 256 
Threads ging der Durchsatz pro genutzem Core für das Intel System bis 
auf 53% des single-thread Durchsatzes zurück. Das ARM System hingegen 
lieferte bis 23 Threads einen Skalierungsfaktor von ca. 95%, der bis 256 
Threads nicht unter 83% abfiel [1]

Dieser Benchmark hat im wesentlichen die Integer Funktionen der CPU 
genutzt (weder FP noch gar Vectoring). Allerdings war der Stromverbrauch 
der ARM Büchse auch unter Vollast weniger als halb so groß.

Insofern kann ich das Fazit bestätigen: ARM liefert mehr MIPS pro Watt, 
aber weniger Spitzenleistung. Auf einem einzelnen Kern sogar noch 
weniger.

> Das kann sich
> inzwischen etwas geändert haben, aber dass sie flotter sein sollen als
> ein i5 oder gar i7, will ich erst sehen

Davon gehe ich nicht aus. Aber wenn man sieht, welche Klimmzüge Intel 
dafür machen muß, dann will man das gar nicht.


[1] zur Verdeutlichung: das Intel System liefert single-threaded den 
Durchsatz X. Bis 32 Threads steigt der Durchsatz an und stagniert dann, 
der Spitzenwert ist 32·X·53%. Arm liefert single-threaded Y, das steigt 
bis auf 46·Y·83%.

von Gustl B. (-gb-)


Lesenswert?

Hier ein aktuellerer Vergleich mit dem ARM Prozessor/SoC von Amazon 
https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd

Also ich sehe da auch recht gute Chancen für ARM oder das was Apple 
daraus gemacht hat für einen Mac Pro.

https://de.wikipedia.org/wiki/Apple_A12_Bionic
Also das ist zwar ARM von der Architektur her, wurde aber von Apple 
entwickelt. Und was auffällt ist, dass die im Vergleich zu anderen 
Herstellern wie Qualcom eher wenige Kerne haben. Der Apple A10 hatte 4 
Kerne. Zwei schnelle und zwei langsame. Und das als andere Hersteller in 
Handys schon 8 Kerne verbaut haben. Apple war trotzdem schneller. Die 
haben da vermutlich Vorsprung und trauen sich jetzt das auf den Desktop 
auszurollen.

: Bearbeitet durch User
von Jan V. (erdgeist)


Lesenswert?

Christoph Z. schrieb:

> Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht
> gibts dann sogar noch RiscOS ;-)

hast Du dafür eine Quelle? Was ich bis jetzt gelesen habe wird nur noch 
die Ausführung von (legacy) macOS erlaubt.

von Christoph Z. (christophz)


Lesenswert?

Jan V. schrieb:
> Christoph Z. schrieb:
>
>> Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht
>> gibts dann sogar noch RiscOS ;-)
>
> hast Du dafür eine Quelle? Was ich bis jetzt gelesen habe wird nur noch
> die Ausführung von (legacy) macOS erlaubt.

Nein, war ja mehr gedacht als Anregung, was sich wirklich ändert, wenn 
Apple auf ARM wechselt. Kenne doch noch relativ viele MacBook Besitzer 
die das Ding nur mit Windows benutzen.

Das Linux darauf nativ Bootet würde ich nicht so schnell erwarten. Würde 
mich nicht wundern, wenn Apple da gleich alle alten Zöpfe abschneidet 
und auch der Bootloader eine eigene Entwicklung ist. Vielleicht brauchts 
dann auch auf den MacBooks einen Jailbrake. Wir werdens sehen.

von bmoe (Gast)


Lesenswert?

Rolf M. schrieb:
> Also wenn das noch RISC sein soll, dann weiß ich auch nicht…

Der Unterschied zwischen RISC und CISC liegt nicht darin, dass bei RISC 
keine behämmerten Befehle vorkommen können, sondern darin das bei RISC 
jeder Befehl die gleiche Anzahl an Bytes verwendet. Dadurch ist 
natürlich die Menge der möglichen Befehle unter RISC begrenzt.

Bei CISC kann jeder Befehl unterschiedlich lang sein, und es muss erst 
mit einem sogenannten "microkernel" herausgefunden werden um welchen 
Befehl es sich handelt und wo die Parameter des Befehls anfangen. Das 
kostet natürlich Zeit und Energie.

Daher ist es egal ob im RISC Befehlssatz Herstellerspezifische 
Nischenbefehle existieren. Wenn der Bus groß genug ist, warum nicht?

von Rolf M. (rmagnus)


Lesenswert?

bmoe schrieb:
> Rolf M. schrieb:
>> Also wenn das noch RISC sein soll, dann weiß ich auch nicht…
>
> Der Unterschied zwischen RISC und CISC liegt nicht darin, dass bei RISC
> keine behämmerten Befehle vorkommen können, sondern darin das bei RISC
> jeder Befehl die gleiche Anzahl an Bytes verwendet.

Ich würde sie nicht "behämmert", sondern "komplex" nennen, aber die zu 
vermeiden, ist eigentlich die Design-Idee von RISC. Vor allem trennt man 
arithmetische Instruktionen von welchen, die Speicherzugriffe machen. 
Dadurch lässt sich zwar auch ein Befehlssatz leichter umsetzen, bei dem 
alle Befehle gleich lang sind, aber das ist eher ein indirekter Effekt.

> Daher ist es egal ob im RISC Befehlssatz Herstellerspezifische
> Nischenbefehle existieren.

Wie bei vielen anderen Dingen ist die klassische Aufteilung in RISC und 
CISC heute nicht mehr so ganz eindeutig, weil es sich heute meist in 
gewissem Rahmen um Mischformen handelt.

> Wenn der Bus groß genug ist, warum nicht?

Was hat die Größe vom Bus damit zu tun?

von Nop (Gast)


Lesenswert?

Rolf M. schrieb:

> Wie bei vielen anderen Dingen ist die klassische Aufteilung in RISC und
> CISC heute nicht mehr so ganz eindeutig, weil es sich heute meist in
> gewissem Rahmen um Mischformen handelt.

Schönes Beispiel: Cortex-M. Der klassische reine 32bit-Befehlssatz bei 
ARM hatte das Problem zu großen Platzbedarfes der Programme. 16bit-Thumb 
hingegen mußte zuviele Befehle in zwei Instruktionen aufspalten, so daß 
die Performance litt.

Deswegen kann Cortex-M nur noch Thumb2, was ein gemischter Befehlssatz 
von 16bit- und 32bit-Befehlen ist. Damit bekommt man sowohl den 
Platzbedarf als auch die Performance unter einen Hut, bricht aber mit 
der reinen RISC-Lehre.

Auf der Gegenseite sind x86-CPUs heute intern auch RISC-CPUs, weil die 
komplexen externen Befehle in µOps zerlegt und dann erst ausgeführt 
werden.

von S. R. (svenska)


Lesenswert?

Nop schrieb:
> Deswegen kann Cortex-M nur noch Thumb2, was ein gemischter Befehlssatz
> von 16bit- und 32bit-Befehlen ist. Damit bekommt man sowohl den
> Platzbedarf als auch die Performance unter einen Hut, bricht aber mit
> der reinen RISC-Lehre.

Vor allem sind die 16-bittigen und 32-bittigen Befehle nicht durchgängig 
äquivalent, was die Decodierung erschwert. RISC-V hat das besser gelöst.

von bmoe (Gast)


Lesenswert?

Ihr wisst wahrscheinlich mehr zu dem Thema als ich.
Ich dachte halt, das der Performance Gewinn durch eine einfachere 
Zuordnung entsteht.
Wie bei einem LUT.

von uwe (Gast)


Lesenswert?


von S. R. (svenska)


Lesenswert?

bmoe schrieb:
> Ich dachte halt, das der Performance Gewinn durch
> eine einfachere Zuordnung entsteht.

Nö, intern werden (in der Regel) die 16-bittigen Befehle zu vollen 
32-bittigen Befehlen ausdecodiert. Der Performancegewinn entsteht, weil 
bei mangelnder Speicherbandbreite "weniger Daten übertragen" einfach 
schneller geht.

von Andreas (Gast)


Lesenswert?

Es sieht echt so aus als wäre die ARM-Architektur jetzt auch außerhalb 
von Embedded kurz vor dem Durchbruch. Bei AWS ist Graviton 2 jetzt schon 
günstiger als entsprechende x64-Maschinen (nachdem der Graviton 1 eher 
"proof of concept" war). Auf Desktopseite hat Apple mit dem M1 den 
ersten überzeugenden x64-Ersatz am Start. Interessant wird, wer als 
nächstes auf den Markt kommt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.