Benchmark für Raspberry Pi

[HaWe]

ich würde gern die Benchmarks sehen, insb. den Vergleich RPi mit Python und mit ANSI-C und ggf. Java.
Punkt.

[HaWe]

@manf: vielen Dank

übrigens wofür der RPi mit Python gedacht war:
spezielle Rechentests weil ich solche Art von Berechnungen ständig für viel Arithmetik und Algebra benutze (Anwendungsprogramme: inverse Kinematik, Navigation, FFT, Kalman-Filter, Monte-Carlo-Filter, Astar, Neuronale Netze), als schnelleren und leistungsfähigeren Ersatz für meine NXTs und Arduino Dues, auf denen diese Anwendungsprogramme nur teilw. oder gar nicht laufen wegen viel zu geringer Geschwindigkeit und viel zuwenig RAM und/oder Flash.

[Technipion]

Hallo Leute,
ich finde es auch nicht gut wenn respektlos miteinander umgegangen wird, das möchte ich nur beiden Seiten gesagt haben. Mich stört es nicht einmal, dass die "bösen" Beiträge wieder entfernt wurden
Aber nun zurück zu HaWes Frage:
Das hier ist genau der Satz, auf den wir alle gewartet hatten:

übrigens wofür der RPi mit Python gedacht war:
spezielle Rechentests weil ich solche Art von Berechnungen ständig für viel Arithmetik und Algebra benutze (Anwendungsprogramme: inverse Kinematik, Navigation, FFT, Kalman-Filter, Monte-Carlo-Filter, Astar, Neuronale Netze), als schnelleren und leistungsfähigeren Ersatz

Jetzt können wir dir präzise Antworten, ganz ohne Benchmark
In der Regel (das trifft auch auf den RPI zu) ist Python etwa um einen Faktor 1,5 bis 10 langsamer als C. Das kommt einfach daher wie der Python-Interpreter funktioniert. Bei reinen Anwendungsprogrammen ist das allerdings kein Problem, die Performance ist hier meist zweitrangig (so stört es z.B. niemanden, dass die Youtube-Server fast komplett mit Python gescriptet sind). Google setzt übrigens Python ein, weil es durchaus seine Stärken hat (@HaWe: Falls du Python lernst, und dir hierfür ein gutes Buch zulegst, werden die Vorteile von Python sicherlich deutlich).
Eine dieser Stärken ist die hohe Modularität, und genau hier kommen wir zum Thema:
Schreibst du rechenintensive Anwendungen, bei denen es um Performance geht, dann skriptest du diese nicht in Python, sondern lässt die Rechnungen von einem Modul (C-like: Bibliothek) ausführen. Bei dir wäre wohl numpy/scipy (http://www.scipy.org/) angebracht. Diese Module sind selbst in C/C++ geschrieben, Python ruft lediglich die bereits compilierten Funktionen auf. Dadurch erreichst du - zumindest bei den Berechnungen - C-Geschwindigkeit. Normalerweise ist Python mit externem C-Modul bereits schnell genug für Game-Engines (siehe http://www.panda3d.org/). Die richtigen Hardcore-Bastler könnten die Performance mit PyPy (http://pypy.org/) bzw. RPython allerdings noch weiter steigern. Bei stackoverflow hatten sie da mal einen schönen Vergleich gezogen (http://stackoverflow.com/questions/6...ang-vs-haskell).
Dein Benchmark hätte dir auf dem RPI mit Sicherheit die gleichen relativen Laufzeiten ausgegeben.
Falls du dich entscheiden solltest dein Programm in Python zu Schreiben, und es dann nicht schnell genug laufen sollte, dann kannst du dich immernoch an ein Programmierforum wenden und den Code optimieren. Grundsätzlich kann man jedes Programm in jeder Sprache realisieren...

Grüße Technipion

[HaWe]

dankeschön für die Klarstellung, aber ich möchte nicht vorwiegend auf externe libs zurückgreifen müssen, das ist mir zu umständlich und damit kenne ich mich erst recht nicht aus. Außerdem muss man da sicher wieder auf Linux-Shell-Ebene rummanipulieren oder sich sogar selber mit C-Compilern, Eclipse unf Makefile rumquälen:
Bei einfachen Array-Sortieralgorithmen wie qsort geht das ja gerade noch, wen man sie schon auf dem Flash oder der SD drauf hat und sie nur noch includen muss, aber alles andere müsste "nativ" funktionieren...

Schließlich schreibe ich ja meine eigenen Routinen je nach Bedarf mal so, mal so, und ich muss im Quellcode die Möglichkeit haben, einfach mal eben die einen oder anderen Berechnungen runterschreiben zu können.

Daher wäre zur Beurteilung der einzelnen RPi-Fähigkeiten und Schwachstellen eben doch der Benchmark (C / Python / Java) interessant gewesen, ganz unabhängig von späteren konkreten Projekten.