Bericht auf golem.de

[Dragoon]

Wie funktioniert denn der Standby eigentlich standardmäßig im Auslieferungszustand? Beim Zuklappen? "Weiß" die Pandora überhaupt, wann se zu ist und wann nicht?

Ich glaube auf der Platine ist ein Sensor, der auf den Magneten des Lautsprechers im Displayteil reagiert, wenn man die Pandora zuklappt.

 

[hede]

Re:

<r><QUOTE author="mick"><s>

</s>... ist nach 2-3 Jahren, wie jeder Li-Io-Akku, sowieso runter. <e>

</e></QUOTE>
Mit dieser Aussage bin ich mittlerweile vorsichtig. Ich dachte mal genauso, weil es viele so sagen und es vielerorts im Netz auch so steht. Das stimmt aber so generell nicht, das kann ich mittlerweile sagen.<br/>
<br/>
Auch interpretieren viele die Aussage "es gibt keinen Memoryeffekt wie bei Nickelzellen" so, als könne man mit Lithionzellen umgehen, wie man wolle. Also jederzeit Laden oder Entladen, ohne auf den Zustand zu achten, oder beliebig lange in der Steckdose lassen (also NiCd, aber NiMH ebenso, einerseits gegenüber LiIon und LiPo andererseits). In der Theorie mag das sogar stimmen, perfekte Ladesteuerung vorausgesetzt. Aber es stimmt in der Praxis eben nicht wirklich. <br/>
<br/>
Ich habe mehrere Geräte mit LiIon-Akku. Die habe ich behandelt, als hätten sie einen empfindlichen Akku mit schlechter Ladesteuerung. Sprich: Ich habe diese Geräte mit LiIon-Akku immer schön entladen vor der nächsten Ladung und dann auch immer schön voll geladen und natürlich nach dem Ladeende vom Netz getrennt und bei Lagerung den Akku rausgenommen (natürlich bei min. 3/4 Ladestand).<br/>
Die Akkus sind zum Teil weit über 3 Jahre alt und noch immer Top. (Den ältesten habe ich vor 1/2 Jahr ausgemustert; ein Handy, das im Alter von (AFAIK) 7 Jahren noch die originalen über 1 Woche Standby (einige Gespräche inkl.) hatte). Dahingegen ist der Akku des Laptops meines Vaters, der eigentlich nur einen Standrechner braucht und das Ding daher _immer_ am Strom hängt, nicht einmal 2 Jahre alt geworden und hat jetzt noch 3 Minuten Laufzeit. Man könnte sagen "nie benutzt und dennoch kaputt", aber eigentlich heißt es: "nie benutzt und daher gerade deswegen kaputt". An den ca. 1000 möglichen Ladezyklen liegt es sicher nicht. Die sind generell eh schwierig in 2-3 Jahren zu erreichen.<br/>
<br/>
Ergo: Auch ein Li-Akku will gepflegt werden und kann dann lange halten. Allerdings wohl wirklich nicht so lange wie Ni-Akkus, die ja auch mal 20 Jahre alt werden können und dann noch immer >50% der Leistung haben. (Bei LiIon-Akkus ist es übrigens auch gerade die entladene Lagerung, die besonders schädlich ist. Ich hab kürzlich ein altes Laptop mit NiMH-Akku unter die Finger gekriegt. Das hat 3-5 Jahre nutzlos und ungeladen rumgelegen. Nach einem Refresh (2x vollständig geladen und wieder entladen) hat das Gerät wieder sage und schreibe >1h Laufzeit. Das kann ich mir mit einem LiIon beim besten Willen nicht vorstellen <E>;-)</E><br/>
<br/>
Sorry für den langen Text. Zugfahrten sind ja soooo langweilig. (Im übrigen hier mit einem Bj.2000 Thinkpad, das noch >4h Laufzeit hat. Nene... hehe... der Akku ist gerade mal ~drei Jahre alt <E></E>)<br/>
<br/>
Und noch mehr Sorrys, muss nämlich noch einen Kommentar zu der Golem-Diskussion abgeben: Im unoptimierten FPU-Bereich, also Gleitkommaberechnungen, die beim Omap nicht auf eine der Spezialeinheiten verteilt wurden, ist der x86er AFAIK mehr als nur um den Faktor 2 pro Takt schneller. Ist das nicht mehr so Faktor 10 oder so? Und bei Integer siegt der P3 wohl auch gar nicht mal so knapp. Ich meine ich könnte mich an einen Vergleich zwischen Cortex A8 und Atom erinnern, bei dem beide etwa gleiche Pro-Takt-Leistung hätten (wohlgemerkt: nur Integer) bzw. der Atom nur einen Hauch schneller ist und der Atom ist pro Takt so einiges langsamer als ein P3. (1-1,2Ghz P3 ~= 1,6GHz Atom). Aber das ist es ja, was den Omap so interessant macht. Die wirklich rechenintensiven Sachen, wie Videodekodierung, überlässt man einfach anderen Einheiten als der CPU alleine und für's reine GUI-Rendering reicht die Leistung eben.</r>

 

[xoquox]

Ist der Pandora Akku nicht Li-Polymer?
mfg
xoquox

 

[Gurumeditation]

Das ist richtig

 

[Anonymous]

Re: Re:

<r><QUOTE author="hede"><s>

</s>Im unoptimierten FPU-Bereich, also Gleitkommaberechnungen, die beim Omap nicht auf eine der Spezialeinheiten verteilt wurden, ist der x86er AFAIK mehr als nur um den Faktor 2 pro Takt schneller. Ist das nicht mehr so Faktor 10 oder so?<e>

</e></QUOTE>

Eher ein Faktor 1000. Kein Witz. Denn entweder werden die Programme gleich mit soft-fpu compiliert, d.h. jeder Floating-Point-Befehl wird durch ein kleines Integer-Programm ersetzt, der dieselbe Berechnung in der Integereinheit durchführt und unendlich viel langsamer ist, oder aber (noch schlimmer) es gibt eine unknown-operation exception für jeden FPU-Befehl, so dass dann in einer Kerneltrap die Integeremulation der FPU durchgeführt werden muss, was noch mehr Overhead bedeutet.<br/>
<br/>
Ich habe mal auf einem 150 MHz ARM9 einen mp3-Konverter laufen lassen, der dummerweise auf FP-Instruktionen setzte. Der hätte für eine volle Audio-CD eher Tage als Stunden gebraucht. Andererseits können die DSPs der OMAPs mal eben Video in Echtzeit mp4-encoden. Wozu also eine FPU im ARM? Die ungewöhnliche Aufgabenverteilung bedeutet aber, dass Programmierer bei vielen Programmen Extraarbeit leisten müssen, statt einfach nur Code, der für einen x86 konzipiert wurde, für ARM zu kompilieren.<br/>
<br/>

<QUOTE><s>

</s>Und bei Integer siegt der P3 wohl auch gar nicht mal so knapp.<e>

</e></QUOTE>

Wejp hatte dazu ein paar Tests mit realen Geräten gemacht. Meiner Erinnerung nach kam heraus, dass ein 300 MHz P3 etwas schneller als ein 600 MHz Cortex A8 ist. Allerdings verbraucht der P3 auch ungefähr 100mal soviel Strom.<br/>
<br/>

<QUOTE><s>

</s>Ich meine ich könnte mich an einen Vergleich zwischen Cortex A8 und Atom erinnern, bei dem beide etwa gleiche Pro-Takt-Leistung hätten<e>

</e></QUOTE>

Den Test habe ich gelesen und er ging für den Cortex A8 nicht so besonders toll aus. Der Atom war fast überall schneller, obwohl er auf die 800 MHz des getesteten Cortex verlangsamt wurde. Allerdings hatte der Atom halt ein typisches PC/Netbook-Umfeld, während der Cortex eben in einem embedded-Umfeld lief. Erst wenn man das und den großen Unterschied bei der Leistungsaufnahme berücksichtigt, kommt der Cortex gut weg.<br/>
<br/>
Der Cortex A9 wird noch einmal eine andere Kategorie: zwei Kerne, die jeweils schon Takt für Takt schneller sind als ein A8, dazu 1 GHz Taktfrequenz. Da ist Musik drin.</r>

 

[hede]

Eher ein Faktor 1000. Kein Witz. Denn entweder werden die Programme gleich mit soft-fpu compiliert, d.h. jeder Floating-Point-Befehl wird durch ein kleines Integer-Programm ersetzt, der dieselbe Berechnung in der Integereinheit durchführt und unendlich viel langsamer ist, oder aber (noch schlimmer) es gibt eine unknown-operation exception für jeden FPU-Befehl, so dass dann in einer Kerneltrap die Integeremulation der FPU durchgeführt werden muss, was noch mehr Overhead bedeutet.

Ja, bei einem ARM ohne FPU. Aber der Omap hat ja immerhin eine FPU, die die gängigen Befehle kennt. Also sofern man ein C-Programm für diese Architektur kompiliert, dürfte diese doch automatisch genutzt werden, oder? Nur eben wenn man vorhandenen, älteren ARM-Code nutzt, der für eine CPU ohne FPU kompiliert wurde, dann siehts düster aus. (oder eben für eine andere FPU, die dann jede Menge Exceptions wirft, klar)

Ich habe mal auf einem 150 MHz ARM9 einen mp3-Konverter laufen lassen, der dummerweise auf FP-Instruktionen setzte. Der hätte für eine volle Audio-CD eher Tage als Stunden gebraucht. Andererseits können die DSPs der OMAPs mal eben Video in Echtzeit mp4-encoden. Wozu also eine FPU im ARM? Die ungewöhnliche Aufgabenverteilung bedeutet aber, dass Programmierer bei vielen Programmen Extraarbeit leisten müssen, statt einfach nur Code, der für einen x86 konzipiert wurde, für ARM zu kompilieren.

Ja, durch die vielen Spezialeinheiten (NEON,dsp), die die jeweilige Aufgabe (wie z.B. Multimedia) viel besser können als die FPU, wird an eben dieser wohl auch so wenig getan. Es hat sicher einen Grund, dass diese im Vergleich zur Integereinheit nicht so viel schneller als bei den Vorgängern ist. Dumerweise muss man da dann aber Code anpassen. Aber wenn, ja wenn man das getan hat, dann gibt es einen mp3-Encoder, der 10 Ströme parallel in Echtzeit transcodieren kann...
Wenn das Wörtchen wenn nicht wäre... ja dann wäre ich Millionär :-D

Den Test habe ich gelesen und er ging für den Cortex A8 nicht so besonders toll aus. Der Atom war fast überall schneller, obwohl er auf die 800 MHz des getesteten Cortex verlangsamt wurde.

Ja, aber immerhin ist es bei diesen beiden schon knapper als bei früheren Vergleichen. Und bis die Atom-Plattform als SoC auf das Verlustleistungsniveau eines Omap abfällt... da vergeht sicher auch noch etwas Zeit.

Allerdings hatte der Atom halt ein typisches PC/Netbook-Umfeld, während der Cortex eben in einem embedded-Umfeld lief. Erst wenn man das und den großen Unterschied bei der Leistungsaufnahme berücksichtigt, kommt der Cortex gut weg.

Ja. Wobei ich nicht verstehe, dass die RAM-Anbindung des Omap so vergleichsweise schlecht ist. Dieses Stacked Ram, oder Package-on-Package müsste doch eigentlich optimal sein. Aber dennoch wenig Takt bei wenig Busbreite und hohen Delays, wenn ich mich recht erinnere...

Der Cortex A9 wird noch einmal eine andere Kategorie: zwei Kerne, die jeweils schon Takt für Takt schneller sind als ein A8, dazu 1 GHz Taktfrequenz. Da ist Musik drin.

Ja, ein Netbook mit solch einem Kern würde mich schon locken. Dann noch mit NVidia Grafik ala Tegra... mal abwarten. Wie sind da eigentlich die Linuxtreiber? Binärer Blob ist der PowerVR ja AFAIK auch. Gibts da Unterschiede was die Qualität angeht und besonders die Verwendbarkeit bei verschiedenen Kernelversionen? Öhm... sorry, will den Thread nicht klauen. Auf die Fragen erwarte ich keine Antwort. Wenn mal Tegra-Tablets/Smartbooks/Netbooks erscheinen ist es noch früh genug, sich darüber zu erkundigen.

So und weils so schön ist, einfach nochmal ein "ja". Einfach so. "Ja". Als wenn es derer da oben nicht schon genug gäbe. :-D

 

[Anonymous]

Ja, bei einem ARM ohne FPU. Aber der Omap hat ja immerhin eine FPU, die die gängigen Befehle kennt.

Das wäre mir neu. Es gibt da diese Vektorengine, die man dafür "missbrauchen" kann, aber die normalen FPU-Befehle dürften m.W. nicht direkt unterstützt werden. Ich gebe aber zu, dass ich mich noch nicht allzu genau mit den Details der Cortex-Architektur befasst habe.

Ja, durch die vielen Spezialeinheiten (NEON,dsp), die die jeweilige Aufgabe (wie z.B. Multimedia) viel besser können als die FPU, wird an eben dieser wohl auch so wenig getan.

Öhm, ich kenne ehrlich gesagt keinen ARM, von dem ich sicher wüsste, dass er eine FPU hat. Die FPU-Befehle sind seit Urzeiten definiert, aber eine reale Umsetzung der FPU ist jedenfalls alles andere als populär. Das erspart aber wenigstens so Gefrickel wie bei der Umstellung der x86-FPU vom Stackmodell auf ein registerbasiertes und ähnliche Probleme mit Dingen, die in der Vergangenheit mal schlau erschienen...

Nachdem die Bedeutung einer klassischen FPU gegenüber Vektorengines rapide abnimmt, wird man wohl bei ARM auch in Zukunft eher keine klassische FPU mehr sehen. Bleibt nur zu hoffen, dass der arm-gcc das auch weiß...

Ja. Wobei ich nicht verstehe, dass die RAM-Anbindung des Omap so vergleichsweise schlecht ist. Dieses Stacked Ram, oder Package-on-Package müsste doch eigentlich optimal sein. Aber dennoch wenig Takt bei wenig Busbreite und hohen Delays, wenn ich mich recht erinnere...

Alles keine Frage des Könnens, sondern lediglich des Wollens (mit Blick auf die Leistungsaufnahme und den Preis). Ein PC-Prozessor kostet mehr als ein komplettes Multimedia-Handy, da kann dann auch der Prozessor mal eben mehr als 1000 Pins haben. Die Pins bestimmen in nicht unerheblichem Maße die Herstellungskosten.

Ja, ein Netbook mit solch einem Kern würde mich schon locken. Dann noch mit NVidia Grafik ala Tegra...

Das würde ich mir auch wünschen. Die Pandora ist eigentlich nur das, was in der Aktualität am nächsten da rankommt...

Treibersituation weiß ich nicht, aber wenigstens TI hat wohl Besserung geschworen. Teilweise war das sehr arm, was da kernelmäßig kam. Und ohne Kernelunterstützung bringt die tollste Hardware nichts.

 

[Christoph.Krn]

Der Cortex A9 wird noch einmal eine andere Kategorie: zwei Kerne, die jeweils schon Takt für Takt schneller sind als ein A8, dazu 1 GHz Taktfrequenz. Da ist Musik drin.

Ja, ein Netbook mit solch einem Kern würde mich schon locken. Dann noch mit NVidia Grafik ala Tegra... mal abwarten.

Guck dir mal das NotionInk Adam an, ein seeeehr interessantes Gerät. Erscheint wohl irgendwann gegen Ende des Jahres.

 

[hede]

Ja, bei einem ARM ohne FPU. Aber der Omap hat ja immerhin eine FPU, die die gängigen Befehle kennt.

Das wäre mir neu. Es gibt da diese Vektorengine, die man dafür "missbrauchen" kann, aber die normalen FPU-Befehle dürften m.W. nicht direkt unterstützt werden. Ich gebe aber zu, dass ich mich noch nicht allzu genau mit den Details der Cortex-Architektur befasst habe.

Oh, sorry. Die meinte ich. Also die nicht-NEON-FPU-Einheit. Die ist laut engl. Wikipedia vollständig ANSI/IEEE Std 754-1985 kompatibel, was ja auch die x86er FPU, der x87er Befehlssatz, ist. Man kann da also mit "normalen FPU-Befehlen" arbeiten. Ich dachte somit, die wäre generell unterstützt und im ARM-Kern integriert. Aber scheinbar ist die Compilerunterstützung auch bei dieser Einheit noch nicht so üblich wie bei einer x87er FPU... Insbesondere hat diese wohl ihren eigenen Registersatz und Datentransfer zwischen VFP- und ARM-Registern ist wohl auch nicht ganz ohne (>20 Takte Pause für beide Einheiten). Naja, du siehst, ich hab von der Materie noch weniger Ahnung als du. Daher meine Aussagen ja auch eher als Fragen... (nutzt der x87er, öhm also die Gleitkommabefehle im x86er, die ganz normalen x86er Register? Dann hätte ich jetzt eine nähere Vorstellung, worin hier beim ARM das Problem liegt...)

(Naja, und das "oder eine andere FPU" von meinem letzten Beitrag deutet ja auch irgendwie darauf hin, dass mir unbewusst klar war, dass es keine Standard-FPU bei ARM gibt, sondern nur einen Haufen verschiedener Möglichkeiten, Floating-Point-Berechnungen effizient zu gestalten, die aber alle irgendwie inkompatibel sind bzw. noch nicht gängig. Obiger Satz war also sehr unglücklich formuliert: "Aber der Omap hat ja immerhin eine FPU...". Dabei wusste ich das ja offensichtlich gar nicht so genau, wie es da den Anschein macht.)

(edit, PS: Folgender Artikel ist da ganz aufschlussreich: http://pandorawiki.org/Floating_Point_Optimization)

 

[Anonymous]

Oh, sorry. Die meinte ich. Also die nicht-NEON-FPU-Einheit. Die ist laut engl. Wikipedia vollständig ANSI/IEEE Std 754-1985 kompatibel, was ja auch die x86er FPU, der x87er Befehlssatz, ist. Man kann da also mit "normalen FPU-Befehlen" arbeiten. Ich dachte somit, die wäre generell unterstützt und im ARM-Kern integriert. Aber scheinbar ist die Compilerunterstützung auch bei dieser Einheit noch nicht so üblich wie bei einer x87er FPU...

Die Compiler können FPU-Code für ARM problemlos erzeugen, nur der ARM-Kern hat schlicht keine FPU eingebaut. Das ist so wie mit dem 386, der erst einmal keine FPU hatte, die musste man als 387 dazukaufen und in einen hoffentlich vorhandenen Steckplatz stecken. Genauso war es z.B. mit dem 68030, der eine 68881/2 zur Seite gestellt bekommen konnte. In der jeweils nächsten Prozessorgeneration gab es dann erstmalig die FPU direkt in den Prozessor integriert (486/68040). Heute ist die FPU standardmäßig bei "ernstzunehmenden" Prozessoren direkt auf dem Chip. Nicht so bei ARM, weil Waschmaschinen und Motorsteuerungen gut ohne FPU leben können. Im Multimediabereich kann man wegen der Spezialeinheiten inzwischen auch gut auf eine FPU verzichten. Deshalb wird es die ARM-FPU wohl auch in Zukunft eher nicht mehr in der Realität geben.

Insbesondere hat diese wohl ihren eigenen Registersatz und Datentransfer zwischen VFP- und ARM-Registern ist wohl auch nicht ganz ohne (>20 Takte Pause für beide Einheiten).

Ich sag ja, manche Idee, die vor 20 Jahren gut erschien, ist heute ein riesiges Hindernis. Beim PowerPC/POWER hat man keinen register-register-transfer zwischen Integereinheit und FPU, der Datenaustausch ist nur übers RAM möglich. Der Grund dafür ist genau der, dass man keine der Einheiten auf die jeweils andere warten lassen wollte. Eigentlich ist ein PowerPC zwei CPUs in einer, die fast vollkommen unabhängig laufen (Instruction Fetch und Verzweigungen sind natürlich noch gemeinsam).

nutzt der x87er, öhm also die Gleitkommabefehle im x86er, die ganz normalen x86er Register? Dann hätte ich jetzt eine nähere Vorstellung, worin hier beim ARM das Problem liegt...

Die x87 ist sehr speziell und stack-orientiert. Falls Du HP-Taschenrechner mit umgekehrt-polnischer Notation kennst: genau so funktioniert die x87. Ein Beispiel: x+87*y wird in einer normalen FPU (z.B. ARM, PowerPC) ungefähr so berechnet:

@ Register mit Werten laden
mov fp0, #87
ldr fp1, x
ldr fp2, y
@ Register mit Rechenoperationen verknüpfen
mul fp1, fp1, fp2
add fp0, fp0, fp1

Umgekehrt polnisch:

@ Operanden auf den Stack schieben
push x
push 87
push y
@ Operanden verknüpfen
mul
add

Es werden also erst alle Parameter in der richtigen Reihenfolge auf den Stack geschoben, anschließend werden nur noch die Operationen gestartet, um die Parameter zu verknüpfen. Das hat sex appeal, ist aber letztlich ein gigantisches Hindernis geworden, weil eine Parallelisierung quasi unmöglich ist.

Naja, und das "oder eine andere FPU" von meinem letzten Beitrag deutet ja auch irgendwie darauf hin, dass mir unbewusst klar war, dass es keine Standard-FPU bei ARM gibt, sondern nur einen Haufen verschiedener Möglichkeiten, Floating-Point-Berechnungen effizient zu gestalten,

Nein, es gibt eine Standard-FPU, aber eben nur auf dem Papier, niemand mag die bauen, weil sie meist nicht benötigt wird. Und inzwischen sieht man die Notwendigkeit einer klassischen FPU eh etwas anders.

 

[wejp]

Oh, sorry. Die meinte ich. Also die nicht-NEON-FPU-Einheit. Die ist laut engl. Wikipedia vollständig ANSI/IEEE Std 754-1985 kompatibel, was ja auch die x86er FPU, der x87er Befehlssatz, ist. Man kann da also mit "normalen FPU-Befehlen" arbeiten. Ich dachte somit, die wäre generell unterstützt und im ARM-Kern integriert. Aber scheinbar ist die Compilerunterstützung auch bei dieser Einheit noch nicht so üblich wie bei einer x87er FPU...

Die Compiler können FPU-Code für ARM problemlos erzeugen, nur der ARM-Kern hat schlicht keine FPU eingebaut.

Der Cortex-A8 hat sehr wohl die besagte Floating Point Unit eingebaut und da TI den Cortex-A8-Core im OMAP3 unverändert übernommen hat, ist diese Einheit auch im OMAP3 enthalten. Es gibt ohnehin nur sehr wenige Firmen, die eine ARM-Lizenz haben, die ihnen Änderungen am jeweiligen CPU-Design erlaubt (die XScale-CPU war so eine von den sehr wenigen Ausnahmen), daher haben fast alle jeweils die Standard-Features der jeweils genutzten Cores in ihren SoCs. Die VFP-Einheit ist deutlich langsamer als die NEON-Einheit, aber natürlich deutlich schneller, als Floating Point in Software zu emulieren und sie ist, wie hede schon angemerkt hat, featuremäßig mit einer Standard-FPU vergleichbar, so dass ein Compiler einfacher dafür Code erzeugen kann. gcc kann zwar sowohl für die VFP, als auch für NEON Code erzeugen, das Ergebnis für NEON ist aber in den meisten Fällen alles andere als ideal.
Übrigens gibt es die VFP nicht erst seit dem Cortex-A8, sondern war sie z.B. auch schon Teil des ARM1136JF-S.

 

[Anonymous]

Übrigens gibt es die VFP nicht erst seit dem Cortex-A8, sondern war sie z.B. auch schon Teil des ARM1136JF-S.

Hehe, es ist sicherlich kein Zufall, dass der letzte ARM, mit dem ich mich intensiv beschäftigt und für den ich in Assembler programmiert habe, ein ARM9 war. Bis dahin gab es jedenfalls keine FPU. Dass im Cortex überhaupt eine FPU vorhanden ist, ist in jedem Fall schon einmal eine gute Nachricht. Die Codequalität des arm-gcc ist aber nicht nur bei NEON eher mäßig, auch bei normalem Integer-Code habe ich genügend gruselige Konstruktionen gesehen. Allerdings habe ich seit dem 680x0 auch nicht wirklich viel in anderem Compiler-produzierten Code gegraben, so dass ich nicht weiß, wie schlechter Code eigentlich üblich ist. Der Assemblerprogrammierer hat da ja andere Erwartungen.

 

[PandoraSuechtig]

Danke für die Ausführungen, sehr interessant. Ich hatte einst nach Jazelle auf ARM Infos gesucht und konnte (ist aber schon ein Jahr her, daher basiert das stark auf woran ich mich noch erinnere), da die Jazelle Dokumentation wieder mal NDA anhängig ist, nur einen Kommentar auf einer Seite finden, dass es von der Performance ernüchternd sei (Java auf Jazelle). Hier scheinen die JIT-Compiler der JRE Jazelle überflüssig gemacht zu haben. Daher auch mehr eine Altlast in der Cortex?

Hab vor einem halben Jahr angefangen mir den ARM Assembler zu studieren (vor 20 Jahren ein wenig 68k ASM genutzt, dazwischen, nunja ein jeder weiss, dass x86 ASM nicht interessant ist...) und kanns kaum erwarten die Pandora für erste Experimente zu nutzen. Schätze der Geschwindigkeitsschub wenn man die DSPs oder NEON nutzt wird mehr als Faktor 10 zu reinem ARM code sein? Wieviel bringt aber eurer Erfahrung nach alleine schon das Optimieren vom ARM code? Insbesondere den angeblich schwachen Output vom ARM-GCC?

 

[fusion_power]

Gibt es eigentlich einen Grund, warum bisher noch keiner NEON oder den DSP auf der Pandora nutzen wollte/konnte?
Zumindest kommt immer wieder durch, dass das wohl doch nicht so einfach ist wie man es gern hätte, bzw einige Flaschenhälse im Weg sind.
Wird das in Zukunft anders oder werden diese Einheiten im OMAP weitestgehend ungenutzt bleiben?

 

[wejp]

Übrigens gibt es die VFP nicht erst seit dem Cortex-A8, sondern war sie z.B. auch schon Teil des ARM1136JF-S.

Hehe, es ist sicherlich kein Zufall, dass der letzte ARM, mit dem ich mich intensiv beschäftigt und für den ich in Assembler programmiert habe, ein ARM9 war.

Ja, das ist richtig, der ARM9 hatte keine FPU.

Die Codequalität des arm-gcc ist aber nicht nur bei NEON eher mäßig, auch bei normalem Integer-Code habe ich genügend gruselige Konstruktionen gesehen.

Das Problem mit NEON ist viel mehr, dass der gcc viele Code-Konstrukte gar nicht erst in NEON-Code umsetzt, er also nicht bloß schlechten NEON-Code fabriziert, sondern für viele Dinge auf NEON verzichtet, obwohl es sich grundsätzlich mit NEON realisieren ließe.

 

[Anonymous]

nur einen Kommentar auf einer Seite finden, dass es von der Performance ernüchternd sei (Java auf Jazelle). Hier scheinen die JIT-Compiler der JRE Jazelle überflüssig gemacht zu haben. Daher auch mehr eine Altlast in der Cortex?

Die Jazelle-Geschichte ist noch relativ neu, vielleicht mit dem ARM11 aufgekommen, insofern kann man nicht von Altlast reden. Ich habe aber auch gehört, dass das nicht so der Bringer sein soll.

Schätze der Geschwindigkeitsschub wenn man die DSPs oder NEON nutzt wird mehr als Faktor 10 zu reinem ARM code sein?

Tja, kommt darauf an, was man macht. Der DSP wird sicherlich teilweise mehr als einen Faktor 10 ausmachen, allein schon, weil er wohl lokales dual-ported RAM hat (Werte zero waitstates lesen und im selben Takt auch noch aufs RAM schreiben, ist schon nett), dafür muss der Code aber einen speziellen Umgang mit den Daten haben, weil das lokale RAM normalerweise nur so 256K groß ist. Dann kann der DSP Operationen wie einen multiply-accumulate in einem Takt (der aktuelle ARM-Befehlssatz hat aber auch ein paar DSP-typische Instruktionen) und ist vermutlich auch noch mehrfach superskalar (habe die TI-DSPs nicht verfolgt, aber schon vor über zehn Jahren gab es die achtfach superskalar). Für richtige Signalverarbeitung, wo mal eben eine DCT hermuss, wird der Faktor weit über 10 liegen. Dafür kann man den DSP wohl kaum ohne Klimmzüge für gewöhnlichen Code hernehmen. NEON wird ungefähr so wie MMx sein. Wenn man Code speziell dafür schreibt und viele gleichartige Werte parallel verarbeitet, wird das sicherlich einen ordentlichen Schub bringen. Paradebeispiel wären pixelbasierte Operationen.

Wieviel bringt aber eurer Erfahrung nach alleine schon das Optimieren vom ARM code? Insbesondere den angeblich schwachen Output vom ARM-GCC?

Ich habe in meinen Coder-Zeiten immer gesagt, dass ich jeden vom Compiler produzierten Code noch einmal um den Faktor 2 beschleunigen kann. In Assembler kann man einfach optimiert programmieren, in einer Hochsprache hat man zu wenig Kontrolle über das Ergebnis. Z.B. habe ich auf dem 68020/030 mal eine komplette Texturemappingroutine geschrieben, die exakt in die 256 Bytes (ja, Bytes!) Instruction Cache des Prozessors passte. Das hat natürlich ungemein viel ausgemacht. Wir haben damals auf einem 50 MHz 68030 gut 25.000 Polygone pro Sekunde gezeichnet.

Oft gehen also viel größere Beschleunigungsfaktoren als 10, dann sind aber meist auch algorithmische Änderungen dabei. Z.B. habe ich mal einen Code beschleunigt, der im YUV-Format abgelegte Pixel umorganisieren sollte (der mplayer-Codec hat Y, U und V jeweils in getrennten Speicherbereichen abgelegt, der Grafikpuffer wollte aber immer jeweils einen Y-Wert gefolgt von einem U oder V-Wert). Meine erste Änderung an dem Code war, immer gleich acht Pixel gleichzeitig zu bearbeiten, während im C-Code jeweils nur ein Pixel auf einmal benutzt wurde. Das bringt eine Menge, macht den Code aber weniger allgemein, weil nur noch Pixelzahlen mit einem Vielfachen von 8 verarbeitet werden können, was aber in der Praxis immer der Fall war.

Dann sollte der Code auch monochrome Bilddaten verarbeiten können. Im C-Code wurde daher in der Schleife jeweils ein Test gemacht, ob gerade monochrome Daten verarbeitet werden oder nicht. Da diese Frage für einen kompletten Durchlauf immer identisch beantwortet wird, habe ich den Code umgestellt:

for (Pixel) {
bla;
if(monochrome) {
blub; } else {
blib; }
}

wurde einfach zu:

if(monochrome) {
for (Pixel) {
bla;
blub;
}
} else {
for (Pixel) {
bla;
blib;
}
}

(C-ähnlicher Pseudocode...)

Solche Optimierungen kann man auch in einer Hochsprache machen, ein Compiler bekommt das normalerweise nicht hin, weil er nicht das notwendige Wissen über die Randbedingungen hat. Wichtig ist vor allem, dass man beim Programmieren immer im Kopf behält, wie der Code nachher in Assembler aussieht, dann kann man auch gleich in der Hochsprache schlauer programmieren. Aber gerade gute Parallelisierung ist dennoch in einer Hochsprache recht schwierig zu machen.


EDIT: ach so, wenn es ein interessantes Projekt gibt, an dem jemand arbeitet, und derjenige beim Profiling feststellt, dass an irgendwelchen kleineren Stellen zuviel Geschwindigkeit verloren geht, kann er sich ja mal an mich wenden. Vielleicht habe ich dann gerade mal ein bisschen Zeit (und eine Pandora zum Testen (vielleicht geht der Code aber auch auf meiner Archos 5, die auch einen OMAP hat)), den Code in Assembler neu zu fassen und zu optimieren. Prinzipiell macht mir so etwas Spaß. Die genannte YUV-Geschichte kam auch auf diese Weise zu mir...

 

[fusion_power]

klingt so als könntest du der Pandora richtig Beine machen, grond. Nur zu.

 

[Anonymous]

klingt so als könntest du der Pandora richtig Beine machen, grond. Nur zu.

Naja, ich habe halt nur extrem wenig Zeit, weshalb ich garantiert kein Projekt wie "ich optimieren den XYZ-Emulator" machen würde. Aber jemanden unterstützen, der so etwas macht, ohne dass man sich zu 100% auf mich verlässt - warum nicht?

 

[Nupfi]

Haha, könntest ja Rolf unterstützen...
Kleiner Scherz am Rande.

 

[Anonymous]

Haha, könntest ja Rolf unterstützen...

Wer ist Rolf?