Hallo, Mit entsetzen musste ich leider feststellen, dass ein Cortex A8 mit 1.2 GHz eine richtig lahme Möhre ist. Ich habe daraufhin einmal den erzeugten Assemblercode von Codesourcery mit dem Assemblercode vom Code Composer verglichen. Der Unterschied ist gewaltig. Nun zu meiner Frage. Ist es möglich mit dem Code Composer eine Lib zu erstellen, die der Linker vom Codesourcery versteht? Meine Versuche dahingehend waren leider bisher nicht erfolgreich. Evtl. hat jemand von Euch dieses Problem schon beantwortet. Viele Grüße
CortexA8 schrieb: > Mit entsetzen musste ich leider feststellen, dass ein Cortex A8 mit 1.2 > GHz eine richtig lahme Möhre ist. Im Vergleich zu was? > Ich habe daraufhin einmal den erzeugten Assemblercode von > Codesourcery mit dem Assemblercode vom Code Composer verglichen. Der > Unterschied ist gewaltig. Von Ausnahmen abgesehen, sollte ein anderer Compiler bestenfalls einen Unterschied im einstelligen Prozentbereich zur Folge haben. Ich gehe davon aus, dass Du die Compileroptionen sorgfältig ausgewählt hast. > Nun zu meiner Frage. Ist es möglich mit dem Code Composer eine Lib > zu erstellen, die der Linker vom Codesourcery versteht? Meine > Versuche dahingehend waren leider bisher nicht erfolgreich. Es müsste zumindest Versionen geben (Linux ABI?), die das unterstützen. Anderenfalls hätte der Compiler Shootout (http://hardwarebug.org/2009/08/20/arm-compiler-shoot-out-round-2/) von Måns Rullgård nicht funktioniert. Gruß Marcus
Hallo Marcus, vielen Dank für Deine Antwort. Marcus Harnisch schrieb: > Im Vergleich zu was? Der ARM soll einen VIA C7 1GHz ersetzen. Marcus Harnisch schrieb: > Von Ausnahmen abgesehen, sollte ein anderer Compiler bestenfalls einen > Unterschied im einstelligen Prozentbereich zur Folge haben. Ich gehe > davon aus, dass Du die Compileroptionen sorgfältig ausgewählt hast. Ich gehe davon aus, die Compileroptionen richtig gesetzt zu haben. Zumindest habe ich mich an die Vorgaben von Mentor gehalten (-mfloat-abi=softfp -mfpu=neon -ftree-vectorize). Das Dumme an diesen Optionen war im Falle von Codesourcery, daß ich leider nicht um Compiler Intrinsics herumgekommen bin. d = a1[0]*b2[0]+ a1[1]*b2[1]+ a1[2]*b2[2]+ a1[3]*b2[3]; Ich glaube, dass man es einem Compiler nicht einfacher machen kann. Der gcc für den VIA hat jedenfalls Gebrauch von der SIMD Einheit gemacht...Codesourcery nicht. Marcus Harnisch schrieb: > Es müsste zumindest Versionen geben (Linux ABI?), die das > unterstützen. Anderenfalls hätte der Compiler Shootout > (http://hardwarebug.org/2009/08/20/arm-compiler-sho...) > von Måns Rullgård nicht funktioniert. Danke für den Link. Viele Grüße
Random schrieb: > Marcus Harnisch schrieb: >> Es müsste zumindest Versionen geben (Linux ABI?), die das >> unterstützen. Anderenfalls hätte der Compiler Shootout >> (http://hardwarebug.org/2009/08/20/arm-compiler-sho...) >> von Måns Rullgård nicht funktioniert. > > Danke für den Link. Der Vergleich hat doch auf einer Baremetal-Platfrom stattgefunden. Ich würde aber gerne den TMS470-Code in einer Lib dem Codesourcery, mit dem Ziel ein ARM GNU/LINUX Programm zu erstellen, zu Verfügung stellen.
Random schrieb: > Das Dumme an diesen Optionen war im Falle von Codesourcery, daß ich > leider nicht um Compiler Intrinsics herumgekommen bin. > d = a1[0]*b2[0]+ > a1[1]*b2[1]+ > a1[2]*b2[2]+ > a1[3]*b2[3]; > Ich glaube, dass man es einem Compiler nicht einfacher machen kann. Der > gcc für den VIA hat jedenfalls Gebrauch von der SIMD Einheit > gemacht...Codesourcery nicht. Und der TI Compiler? Mir ist nicht ganz klar, was Du jetzt eigentlich vergleichst. VIA/ARM, GCC/CCS? Es geht Dir also offenbar darum, NEON effizient einzusetzen. Der auto-vectorizer des GCC unterstützt die ARM Architektur noch nicht so lange und kann daher möglicherweise nicht mit kommerziellen Compilern mithalten. Evtl gibt -ftree-vectorizer-verbose Dir ein paar hilfreiche Informationen, wie man den Code umstellen könnte. Insbesondere handelt es sich beim obigen Ausdruck anscheinend um eine manuell abgerollte Schleife. Das könnte den Optimizer verwirren. Kannst Du mehr Code zeigen? Um was für Datentypen handelt es sich dabei überhaupt? Auch hilfreich: http://infocenter.arm.com/help/topic/com.arm.doc.dht0004a/index.html Random schrieb: > Der Vergleich hat doch auf einer Baremetal-Platfrom stattgefunden. Woher weißt Du das? Gruß Marcus
Marcus Harnisch schrieb: > Und der TI Compiler? Mir ist nicht ganz klar, was Du jetzt eigentlich > vergleichst. VIA/ARM, GCC/CCS? > > Es geht Dir also offenbar darum, NEON effizient einzusetzen. Der > auto-vectorizer des GCC unterstützt die ARM Architektur noch nicht so > lange und kann daher möglicherweise nicht mit kommerziellen Compilern > mithalten. Evtl gibt -ftree-vectorizer-verbose Dir ein paar hilfreiche > Informationen, wie man den Code umstellen könnte. Insbesondere handelt > es sich beim obigen Ausdruck anscheinend um eine manuell abgerollte > Schleife. Das könnte den Optimizer verwirren. Kannst Du mehr Code > zeigen? Um was für Datentypen handelt es sich dabei überhaupt? Hallo, ich bin mittlerweile weiter gekommen. So ein ARM ist wohl leider eine Performance-Gurke. Da hilft auch ein anderer Compiler leider nichts. Ich habe heute einige Funktionen in Assembler geschrieben um die SIMD-Einheit (alias NEON) zu verwenden. Der Performance-Gewinn bewegt sich um den Faktor 5. Allerdings wird trotzdem nicht die Geschwindigkeit erreicht, den ein VIA C7, den der ARM ersetzen soll, erzielt. TI hat beim AM389x ein wirklich tolles Paket um den Cortex geschnürt, nur leider bleibt der ARM der Flaschenhals. Schade eigentlich. Viele Grüße
Random schrieb: > So ein ARM ist wohl leider eine Performance-Gurke. Ich glaube, dass uns Deine wiederholte Polemik nicht viel weiter bringt. > Da hilft auch ein anderer Compiler leider nichts. Sag' ich ja. > Ich habe heute einige Funktionen in Assembler geschrieben um die > SIMD-Einheit (alias NEON) zu verwenden. Der Performance-Gewinn > bewegt sich um den Faktor 5. Prima. Vielleicht ist da sogar noch mehr drin. Und dann kann man u.U. noch Speicherzugriffe optimieren. Ich habe in der Vergangenheit recht erfolgreich Codeoptimierungen auf ARM Prozessoren vorgenommen. > Allerdings wird trotzdem nicht die Geschwindigkeit erreicht, den ein > VIA C7, den der ARM ersetzen soll, erzielt. Ist das Kriterium "so schnell wie C7", oder "schnell genug, die Aufgabe in einer bestimmten Zeit zu bewältigen"? Bei ersterem sehe ich in der Tat ein Problem. Ohne die Implementierung des C7 zu kennen würde ich bei gleicher Taktfrequenz den Vorteil auf Seite des C7 gegenüber Cortex-A8 sehen. Ist eben an eine andere Zielgruppe gerichtet. Viele Grüße Marcus
Hallo Markus, Marcus Harnisch schrieb: > Ich glaube, dass uns Deine wiederholte Polemik nicht viel weiter > bringt. Ich wollte lediglich meiner Enttäuschung Ausdruck geben. Marcus Harnisch schrieb: > Ist das Kriterium "so schnell wie C7", oder "schnell genug, die > Aufgabe in einer bestimmten Zeit zu bewältigen"? Bei ersterem sehe ich > in der Tat ein Problem. Ohne die Implementierung des C7 zu kennen > würde ich bei gleicher Taktfrequenz den Vorteil auf Seite des C7 > gegenüber Cortex-A8 sehen. Der Arm soll den C7 ersetzen. Allerdings wird er voraussichtlich nicht von mir programmiert. Deshalb wird hardwarenahe Programmierung wohl zum K.O.- Kriterium werden. Was ich erstaunlich finde: Der ARM soll bezogen auf MIPS/MHz deutlich schneller als der VIA sein (ARM 2.0 MIPS/MHz Via 1.4 MIPS/MHz. Quelle: http://en.wikipedia.org/wiki/Million_instructions_per_second#Million_instructions_per_second). Ich weiss, dass MIPS so eine Sache sind, bin aber doch überrascht, dass der VIA deutlich schneller ist. Zur Zeit habe ich die Speicherzugriffe in Verdacht. Viele Grüße
DMIPS Zahlen sind relativ aussagelos. Allerdings soll sich Cortex-A8 auch beim 7-Zip Benchmark ganz gut schlagen: http://www.7-cpu.com/ Random schrieb: > Zur Zeit habe ich die Speicherzugriffe in Verdacht. Bei modernen CPUs ist das meistens der Fall. Mit Kenntnis des Speicheraufbaus des SoC, und der Cachearchitektur lässt sich hier viel rausholen. Allerdings gibt es beim Cortex-A8 und NEON Code auch einige Dinge zu beachten. Bei diesem Prozessor (im Gegensatz zum Cortex-A9) ist NEON hinten an die Pipeline rangeflanscht. Sowohl das Alignment der NEON Speicherzugriffe, als auch der Datenfluss zwischen NEON und Core Registern haben Einfluss auf die Arbeitsgeschwindigkeit. Wenn es sich, wie es scheint, um ein kommerzielles Produkt handelt, können wir uns gerne per PN weiter unterhalten. Gruß Marcus
Marcus Harnisch schrieb: > Random schrieb: >> Da hilft auch ein anderer Compiler leider nichts. > > Sag' ich ja. Für weitere Anregungen siehe auch: http://www.doulos.com/knowhow/arm/using_your_c_compiler_to_exploit_neon -- Marcus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.