[HaBo]

enkore

Anzeige

Sing# für Singularity ist Managed Code, d.h. Bytecode, wird per VM interpretiert. Und der Kernel ist im Wesentlichen in Sing# geschrieben

Pyrit, aktuell effizientester WPA/WPA2-Cracker... geschrieben in Python. Okay, cheatet, nutzt OpenCL

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++

Hackse

Danke für den Link, mime.
Auch an diesem Beispiel sieht man sehr schön, dass skriptbasierte Webserver wie Tornado zurecht intern auf Binärcode (in diesem Falle von epoll) zugreifen um simultane Verbindungen möglichst performant zu verwalten (bei BSD ist es kqueue).

CDW

Bitte kein Geflame über "real man" Programmiersprachen. Ihr könnt dazu gerne einen eigenen Thread aufmachen

OT:
Aber bitte => Programmieraufgaben Unterforum wartet auf Dich

Wobei man bedenken sollte, dass es in den "realen" Anwendungen oft genug nicht nur um reine Berechnungen geht (sondern auch Verarbeitung/Speicherung und "Zurverfügungstellung" von Input/Daten) und viele "Scriptsprachenbibliotheken" in C implementiert sind, so dass primitve Operationen auf diesen Datentypen (Hashmaps, Listen, Stringsuche usw) nur gewrapte Aufrufe der C-Bibliothek sind.
Reine Numbercruncher sind daher sowas wie "Microbenchmarks". Es wäre also schön, wenn es nicht nur einseitige "berechne Pi/Primzahl &Co" Aufgaben wären, sondern auch vielleicht "parse Datei X und gebe dazu irgendwelche Statistiken aus"

Ich würde im übrigen behaupten, dass ANSI-C auch bei weitem nicht so schnell ist. Wer real exisitierende MD5/SHA1 Bruteforcer anschaut:
Distracted: SHAbr update, I passed 60 Mhashes/s
sieht, dass der Code dank Macros quasi "Meta-Assembly" entspricht, bei dem der Compiler nur noch die jeweiligen XMM Register "frei" vergeben darf . Hierzu reicht es also bei weitem nicht aus, reines C/C++ "perfekt" zu beherrschen - man muss auch die jeweilige Hardwareplattform kennen (wieviele Register stehen zur Verfügung, wie lässt man den Compiler das am besten Parallelisieren usw.)

Allgemeines imho:
Man sollte immer zwischen "prinzipiell/theoretisch" und "praktisch/wie es tatsächlich ausschaut" unterscheiden . Um tatsächlich performante Programme zu schreiben, braucht man ein solides, abstraktes Hintergrundwissen über Algorithmen und Datenstrukturen sowie über die jeweilige Plattform (was bietet OS an Features, was bietet die Hardware und wie sage ich dem Compiler, dass er diese nutzen soll?).
In der Praxis sind Teile der "0815" C Anwendungen nicht selten langsamer als "0815" Pythonanumsetzung, einfach weil der C "Programmierer" meint, das Rad neu erfinden zu müssen und/oder unpassende Umsetzungen wählt (weil z.B die Datenstrukturen nicht in der Standardbibliothek vorhanden sind) und der Scriptsprachler einfach auf bestehende Bibliotheken zurückgreift ("Batteries included" - sei es HTTP Reader, XML-Parser oder Dictionaries/Sets, die auf einer soliden, getesteten usw. C Bibliothek basieren).
Speicherverwaltung ist ein Thema für sich - nur weil man den Speicher selber manuell alloziert und freigibt, wird das Programm dadurch nicht effizienter oder schneller (wie z.B ein while-Loop, der mittels recv Daten empfägt und dabei jedesmal den Buffer mittels realloc um 1 Byte erweitert )

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

Hackse

Mit "Kernelmodule" meinte ich Unix/Linux. Und dennoch ist der unterste Layer von Singularity teils in Assembler geschrieben. Bytecode wird zwar durch die VM interpretiert, ich gebe Dir Recht, ist jedoch bereits binär. Mit reinen Skriptsprachen meine ich also keine Mischformen (Java & co), sondern beziehe mich auf die Interpretation des textuellen Sourcecodes durch den Interpreter. Ich sehe schon, Du versuchst zu schummeln. Aber selbst wenn Singularity und Konsorten man richtig ausgereift sind, warten wir mal die Performance ab und schauen uns die Benchmarks an.
Pyrit verwendet nicht nur Binärcode zur Beschleunigung, sondern macht (z.B. via CUDA) auch Gebrauch von GPU um einen massiv-parallelen Algorithmus zu simulieren. Kannst ja mal versuchen so was in einem Shellskript mit der selben Performance abzubilden.

Hackse

Gerade in C hapert es an Funktionalitäten, z.B. verglichen mit Java oder Perl's CPAN. Da bleibt einem manchmal nix anderes übrig das Rad neu zu erfinden.

Der Performance-Vergleich zweier Sprachen sollte sich grundsätzlich auf identische Algorithmen beziehen. Wenig Sinn macht das Ganze z.B. wenn man in zwei Sprachen Algorithmen abbildet, die verschiedenen Komplexitätsklassen genügen und dann die Performance vergleicht. Es lassen sich also entweder identische Algorithmen in verschiedenen Sprachen vergleichen oder verschiedene Algorithmen in der selben Sprache (einfach um zwei Algos zu vergleichen, z.B. Heapsort vs. Quicksort). Eine Mischform aus beidem macht IMHO wenig Sinn.

Genug OT von mir für heute.