Das ist jetzt nicht unbedingt mein Gebiet aber ich würde vermuten, dass es an mehreren Gründen liegt.
MATLAB ist auch eine Interpretersprache und läuft in Grundzügen sehr schnell. Ich spreche jetzt nicht von Funktionen, die intern FORTRAN und C Calls durchführen, sondern reinen nicht vektorisierten MATLAB Code. MMn ist es also nicht zwingend notwendig, dass Python 5 mal langsamer läuft. Overhead durch JIT, VM oder Ähnliches wird es aber wie schon bei Java zwar immer geben. Bloß ist dieser meiner Erfahrung nach bei weitem nicht so hoch. Dieser Umstand wird dank Etablierung von Clang, LLVM und co. in den letzten Jahren deutlich besser.
Einige Interpreter sind intern mit C realisiert. So wie es meistens bei Java und Python ist. Das heißt per Definition, dass es nie schneller als C gehen wird. Allerdings wird es noch komplizierter, da die Standard Libraries, also alle zusätzlichen Funktionen, wiederrum in der eigenen Sprache sind. Also Python bzw. Java.
Ein Performance-Fresser ist definitiv die Typlosigkeit. In C++ sind viele Fälle durch den Datentyp auto und Template-Metaprogrammierung abgefangen worden, die nicht wirklich typenlos sind. Der Typ wird da nur zur Compilierzeit bestimmt und bleibt fest. Ich spare mir mal hier den QVariant oder Boost.Variant.
Dann wäre da der Overhead durch "Alles ist eine Klasse/Objekt/Liste/JSON" usw... Dadurch schleppen die Variablen jede Menge Informationen mit sich, ob sie gebraucht werden oder nicht. Polymorphie ist ohnehin ein Performance Fresser.
Ich würde daher auf einen Mix aus Low-Level Optimierung, schlecht implementierter Funktionen und Extras für bequemere Programmierung tippen.
Von Roadrunner123 am Sa, 7. Oktober 2017 um 13:38 #
"MATLAB ist auch eine Interpretersprache und läuft in Grundzügen sehr schnell."
Danke, ich hab gelacht.
Mathlab ist doch nur dazu da, Wissenschaftlern einfache mathematische Aufgaben Abzunehmen, welche C/C++ von Haus aus nicht zur Verfügung stellen - für die es inzwischen Bibliotheken gibt. Aber mehr ist es ebend nicht und schon gar nicht schnell.
Ohne der automatischen Verwendung von CUDA/OpenCL im Hintergrund (seit 2015) wären die einfachen Matrizenoperationen schnarsch-langsam. Und auch hierbei mussten wir feststellen, dass dies zum Teil langsamer läuft als direkt auf der CPU, nur dass man keinen Einfluss darauf hat.
Ich weiß wovon ich rede, ich als C/C++-Entwickler stehe jedem Tag rund 50 Mathlabliebhaber gegenüber.
Das ist jetzt nicht unbedingt mein Gebiet aber ich würde vermuten, dass es an mehreren Gründen liegt.
MATLAB ist auch eine Interpretersprache und läuft in Grundzügen sehr schnell. Ich spreche jetzt nicht von Funktionen, die intern FORTRAN und C Calls durchführen, sondern reinen nicht vektorisierten MATLAB Code. MMn ist es also nicht zwingend notwendig, dass Python 5 mal langsamer läuft. Overhead durch JIT, VM oder Ähnliches wird es aber wie schon bei Java zwar immer geben. Bloß ist dieser meiner Erfahrung nach bei weitem nicht so hoch. Dieser Umstand wird dank Etablierung von Clang, LLVM und co. in den letzten Jahren deutlich besser.
Einige Interpreter sind intern mit C realisiert. So wie es meistens bei Java und Python ist. Das heißt per Definition, dass es nie schneller als C gehen wird. Allerdings wird es noch komplizierter, da die Standard Libraries, also alle zusätzlichen Funktionen, wiederrum in der eigenen Sprache sind. Also Python bzw. Java.
Ein Performance-Fresser ist definitiv die Typlosigkeit. In C++ sind viele Fälle durch den Datentyp auto und Template-Metaprogrammierung abgefangen worden, die nicht wirklich typenlos sind. Der Typ wird da nur zur Compilierzeit bestimmt und bleibt fest. Ich spare mir mal hier den QVariant oder Boost.Variant.
Dann wäre da der Overhead durch "Alles ist eine Klasse/Objekt/Liste/JSON" usw... Dadurch schleppen die Variablen jede Menge Informationen mit sich, ob sie gebraucht werden oder nicht. Polymorphie ist ohnehin ein Performance Fresser.
Ich würde daher auf einen Mix aus Low-Level Optimierung, schlecht implementierter Funktionen und Extras für bequemere Programmierung tippen.
"MATLAB ist auch eine Interpretersprache und läuft in Grundzügen sehr schnell."
Danke, ich hab gelacht.
Mathlab ist doch nur dazu da, Wissenschaftlern einfache mathematische Aufgaben Abzunehmen, welche C/C++ von Haus aus nicht zur Verfügung stellen - für die es inzwischen Bibliotheken gibt.
Aber mehr ist es ebend nicht und schon gar nicht schnell.
Ohne der automatischen Verwendung von CUDA/OpenCL im Hintergrund (seit 2015) wären die einfachen Matrizenoperationen schnarsch-langsam.
Und auch hierbei mussten wir feststellen, dass dies zum Teil langsamer läuft als direkt auf der CPU, nur dass man keinen Einfluss darauf hat.
Ich weiß wovon ich rede, ich als C/C++-Entwickler stehe jedem Tag rund 50 Mathlabliebhaber gegenüber.