Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache: Rust…

Wird wirklich noch mit Performance argumentiert..?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Wird wirklich noch mit Performance argumentiert..?

    Autor: kim3000 16.05.15 - 16:29

    Warum wird eigentlich immer noch mit Performance argumentiert wo doch die Performancewerte vieler Programmiersprachen sich annaehern und allerhoechstens noch die dynamischen Sprachen weit abgeschlagen sind.

    Im Vergleich zu C/C++ gibt es einige im Artikel genannte High-Level Sprachen deren Performancewerte gleichauf bzw. im einstelligen Prozentbereich kleiner sind. Ich glaube Rust kommt da noch nicht mal ran.

    Der Grund warum man immer noch C/C++ nutzt ist vor allem historischer Natur und dass man nunmal ein gewachsenes Oekosystem hat, dass man nicht einfach komplett neu entwickeln will. Und sind auch alle Experten auf dem Gebiet auf C/C++ eingeschossen und ein alter Gaul lernt keine neuen Tricks mehr.
    Darueberhinaus gibt es auch noch technische Gruende warum man C/C++ braucht/nutzt. Und mit nutzt meine ich fuer Endkundensoftware nutzt. Dass NUR das OS und Core libraries C/C++ nutzen waere ein moeglicher Schritt. Und Endkundensoftware wie Firefox wuerde dann auf diese Core-OS Funktionen zugreifen - allerdings nicht mehr mit C/C++. Das waere schon alles moeglich und ohne messbare Performanceverluste.

    (fuer die ganz Schlauen: mir ist auch bewusst, dass alles was ich sage sehr generell ist und es Ausnahmen dazu gibt)

  2. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: stefanreich 16.05.15 - 17:35

    Ja, komplett richtig. Performance ist immer machbar - wichtig ist die Produktivität der Entwickler!

    Man sollte auch generell auf 'safe' languages übergehen, also alles, was konsequent Exceptions wirft und einfach nicht segfaultet. Java erlaubt das schon durchaus alles, mal abgesehen von dem etwas ekligen OutOfMemory-Handling. Aber auch da gibt's ne Exception und keinen Crash!

  3. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: pythoneer 16.05.15 - 17:54

    Schön, wie verschieden da die Meinungen sind. Ich bin persönlich begeistert von dem Trend Exceptions wieder aus Sprachen zu entfernen. Die Sprachen mit denen ich mich zuletzt beschäftigt habe (Go, Swift, Rust) machen da glücklicherweise einen weiten Bogen rum. Ich stehe schon lange mit Exceptions auf dem Kriegsfuß und bin froh, dass einige Sprachen mit denen ich mich anfreunden kann dieses Konzept mal ablegen.

    Für mich macht eine Sprache eben nicht "safe" wenn sie zur runtime irgendwann ne Exception schmeißen kann. Viel besser ist es, wie bei Rust, das sich ein Programm erst gar nicht kompilieren lässt, das ist für mich "safe". Also alles was konsequent keine Exceptions wirft, sonder sich gar erst kompilieren lässt, wenn es "safe" ist. Und da ist Java ne ganze Ecke von entfernt, gerade was concurrency (und runtime exceptions) anbelangt.



    5 mal bearbeitet, zuletzt am 16.05.15 18:01 durch pythoneer.

  4. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: Geistesgegenwart 16.05.15 - 19:34

    pythoneer schrieb:
    --------------------------------------------------------------------------------

    > Für mich macht eine Sprache eben nicht "safe" wenn sie zur runtime
    > irgendwann ne Exception schmeißen kann. Viel besser ist es, wie bei Rust,
    > das sich ein Programm erst gar nicht kompilieren lässt, das ist für mich
    > "safe".

    Das lässt sich aber nicht so umsetzen. Fehler können durchaus "safe" in einem Programm auftreten. Beispiel Socketprogrammierung: Die Gegenstelle kann jederzeit den Socket schliessen, währrend du im "read_from_socket()" steckst. Das hat nichts mit Sicherheit zu tun, sondern es sind erwartete Fehler die man behandeln kann. Es würde dann Sinn machen das read_from_socket eine Exception wirft, die korrekt gefangen und behandelt wird (freigeben von resourcen, reconnect, etc.):


    try {
    data = read_from_socket(sock, *data);
    process(data);
    } catch (Exception e) {
    handle_exception(e);
    }

    In Sprachen ohne Exceptions sieht das dann meist eher so aus, dass der Rückgabewerte != 0 ist um ein Fehlercode zu übertragen:

    int err = read_from_socket(sock);
    if (err == 0) process(data);
    else handle_error(err);

    Natürlich geht beides, ich finde ersteres aber dahingehend schöner weil es "klarer" ist. Der Rückgabewerte von read_from_socket sollte semantisch Sinnvoll sein, z.B. ein Datenpaket. In C bzw. Sprachen ohne Exceptions artet das meistens so aus das Funktionen prinzipiell entweder immer int zurückgeben (für den Fehlerstatus), oder das erste argument jeder funktion immer ein Pointer auf ein Error objekt ist, das im Fehlerfall gesetzt ist (z.B. bei GLib so). Finde ich nicht intuitiv. Letztenendes ist es aber eine Geschmacksfrage.

  5. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: LadyDie 16.05.15 - 19:59

    Geistesgegenwart schrieb:

    > try {
    > data = read_from_socket(sock, *data);
    > process(data);
    > } catch (Exception e) {
    > handle_exception(e);
    > }

    Und was ist wenn process(data) die Exception wirft, Du aber glaubst wie kommt von read_from_socket() ?

  6. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: pythoneer 16.05.15 - 20:02

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > Das hat nichts mit Sicherheit zu tun, sondern es sind erwartete
    > Fehler die man behandeln kann.

    Danke, du hast gerade genau einen Hauptkritikpunkt von mir gegenüber Exceptions sehr deutlich gemacht. "Erwartete Fehler" – so degenerieren Exceptions immer mehr zu einen ifelse Konstrukt und dafür ist es VIEL zu aufwendig. Ich habe es oft genug erleben müssen, dass Exceptions bei jeder Kleinigkeit geschmissen werden, wo das erwartete Ergebnis oder die Exception gleich wahrscheinlich sind. Für so eine Semantik sind Exceptions viel zu kostspielig!

    > Es würde dann Sinn machen das
    > read_from_socket eine Exception wirft, die korrekt gefangen und behandelt
    > wird (freigeben von resourcen, reconnect, etc.):

    Hier würde ich sehr widersprechen.

    >
    >
    > try {
    > data = read_from_socket(sock, *data);
    > process(data);
    > } catch (Exception e) {
    > handle_exception(e);
    > }

    Das sieht schon nicht schön aus und wenn ich mir dann noch den finally Block dazu denke, wird das ganze noch unübersichtlicher. Ganz davon zu schweigen wie kostspielig Exceptions sind.

    > In Sprachen ohne Exceptions sieht das dann meist eher so aus, dass der
    > Rückgabewerte != 0 ist um ein Fehlercode zu übertragen:

    In Rust und Swift wird das ja gerade nicht gemacht.

    > int err = read_from_socket(sock);
    > if (err == 0) process(data);
    > else handle_error(err);
    >
    > Natürlich geht beides, ich finde ersteres aber dahingehend schöner weil es
    > "klarer" ist.

    Geschmackssache, das gebe ich zu, jedoch sind Exceptions in meinen Augen aufwendige GOTOS.

    > Der Rückgabewerte von read_from_socket sollte semantisch
    > Sinnvoll sein, z.B. ein Datenpaket. In C bzw. Sprachen ohne Exceptions
    > artet das meistens so aus das Funktionen prinzipiell entweder immer int
    > zurückgeben (für den Fehlerstatus), oder das erste argument jeder funktion
    > immer ein Pointer auf ein Error objekt ist, das im Fehlerfall gesetzt ist
    > (z.B. bei GLib so). Finde ich nicht intuitiv. Letztenendes ist es aber eine
    > Geschmacksfrage.

    In Rust gibt es das Konzept der algebraischen Datentypen die dazu verwendet werden um z.B. das Konzept der Optionals (bekannt zum Beispiel aus Swift) oder eben auch ResultTypes einzuführen. Da Rust wie Swift eine NULLfree Sprache ist (nie wieder NullPointerExceptions) werden alle Werte die NULL sein könnten per Optionals gewrappt oder Werte dessen Ergebnis ein Fehler sein könnte mit Results gewrappt. Möchte man an diesen Wert heran, so muss man diesen Auspacken und hat damit automatisch seine Fehlerprüfung, ohne das Kostpielige Exceptions geworfen werden müssen, die den Stack unwinden und seltsame Finally blöcke.

    in Rust könnte dein Beispiel dann so aussehen

    let result = read_from_socket(&socket);
    match result {
      Ok(data) => process(&data)
      Err(_) => handle_error()
    }

    Der Finally Block, der bei deinem Beispiel vielleicht noch fehlt, ist bei Rust durch das ownership Konzept bereits enthalten.

    https://doc.rust-lang.org/std/result/



    4 mal bearbeitet, zuletzt am 16.05.15 20:21 durch pythoneer.

  7. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: thomas001le 16.05.15 - 20:10

    LadyDie schrieb:
    --------------------------------------------------------------------------------
    > Geistesgegenwart schrieb:
    >
    > > try {
    > > data = read_from_socket(sock, *data);
    > > process(data);
    > > } catch (Exception e) {
    > > handle_exception(e);
    > > }
    >
    > Und was ist wenn process(data) die Exception wirft, Du aber glaubst wie
    > kommt von read_from_socket() ?

    Wenn die Exception den gleichen typ hat, dann sollte doch egal sein wo sie herkommt...

    ihr vergesst irgendwie dass es STRUCTURED exception handling ist...also dein bsp wäre eher

    try {
    read_from_socket(data);
    process(data);
    } catch(IOException& e) { .. }

    PS: was soll eigentlich data = ... ( ... *data); sein?

  8. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: RipClaw 16.05.15 - 20:12

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------

    > Das lässt sich aber nicht so umsetzen. Fehler können durchaus "safe" in
    > einem Programm auftreten. Beispiel Socketprogrammierung: Die Gegenstelle
    > kann jederzeit den Socket schliessen, währrend du im "read_from_socket()"
    > steckst. Das hat nichts mit Sicherheit zu tun, sondern es sind erwartete
    > Fehler die man behandeln kann. Es würde dann Sinn machen das
    > read_from_socket eine Exception wirft, die korrekt gefangen und behandelt
    > wird (freigeben von resourcen, reconnect, etc.):
    >
    > try {
    > data = read_from_socket(sock, *data);
    > process(data);
    > } catch (Exception e) {
    > handle_exception(e);
    > }

    Hier sieht man sehr schön wie nachlässig das Entwickeln mit Exceptions wohl macht.

    Man verlässt sich nur noch darauf das in einem Fehlerfall schon eine Exception geworfen wird und prüft selber nichts mehr.

    Exceptions sollten nur den Fall abfangen den man nicht vorhersehen konnte und nicht als Spürhund für Eingabefehler herhalten.

  9. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: pythoneer 16.05.15 - 20:16

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > Hier sieht man sehr schön wie nachlässig das Entwickeln mit Exceptions wohl
    > macht.
    >
    > Man verlässt sich nur noch darauf das in einem Fehlerfall schon eine
    > Exception geworfen wird und prüft selber nichts mehr.
    >
    > Exceptions sollten nur den Fall abfangen den man nicht vorhersehen konnte
    > und nicht als Spürhund für Eingabefehler herhalten.

    Exakt meine Meinung. Exceptions waren vielleicht mal eine schöne Idee, jedoch sehe ich leider zu oft, wie damit Schindluder getrieben und das Konzept an sich völlig ad absurdum geführt wird.

  10. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: thomas001le 16.05.15 - 20:18

    pythoneer schrieb:
    -
    >
    > let result = read_from_socket(&socket);
    > match result {
    >   Ok(data) => process(&data)
    >   Err(_) => handle_error()
    > }

    if let OK(data) = read_from_socket()
    process(data);
    else
    handle_error();

  11. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: thomas001le 16.05.15 - 20:19

    Wenn man den Fehler nicht selbst behandeln kann muss man ihn auch nicht fangen, sondern das macht dann eben jemand weiter oben im call stack...
    wieso sollte eine low level daten routine einen socket fehler fahren, wenn sie gar nichts damit anzufangen weiss, damit sie dann eine neue eigene exception wirft? na prima...

  12. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: pythoneer 16.05.15 - 20:27

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > if let OK(data) = read_from_socket()
    > process(data);
    > else
    > handle_error();

    match ist in diesem Fall aber Ausdrucksstärker.

  13. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: lestard 16.05.15 - 21:01

    Monaden für Fehlerbehandlung sind cool. So siehts wesentlich schicker aus als Exception-Handling und Integer-Rückgabewerte prüfen. Das würde ich mir als Java-Entwickler auch wünschen.
    Im übrigen Teile ich die Ansicht bezüglich der Ähnlichkeit von Exceptions mit GOTO.

  14. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: pythoneer 16.05.15 - 22:10

    Es ist natürlich oft möglich Monaden selber – zumindest für seine eigenen Programme und Libs – zu erstellen und das habe ich bei zwei Java-Projekten auch versucht, nur scheitert das zum einen daran, dass es dann letzten Endes dann doch nicht so einfach ist (das macht man nicht mal nebenbei) und zum anderen ist es nur mit sich selber kompatibel und da wo man es eigentlich bräuchte, in der Standardbibliothek, ist es nicht vorhanden und der Compiler weiß davon auch nichts. Willst du die Libs dann in anderen Projekten wiederverwenden merkt man auch schnell, dass das zu Reibung führt, weil es halt nicht "nativ" in der Sprache verankert ist und Kollegen die das verwenden sollen auch so ihre Probleme haben. So musste ich den Versuch für Java auch leider wieder einstellen, der Aufwand war dann für mich doch zu hoch.

  15. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: teenriot* 16.05.15 - 23:11

    Ja, weil es einen direkten Zusammenhang zwischen Performance und Energieverbrauch gibt. 20% Energieeinsparung kann bei Handys entscheidet für den Kauf sein.

  16. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: Moe479 17.05.15 - 00:49

    das setzt jetzt aber schon planung vorraus, bzw. dass man zumindest etwas ähnliches schoneinmal verbrochen hat, ich finde eine exeption ersteimal besser als garnichts, sinn von trys und exepts ist es ja unerwartes verhalten zumindest als dieses kennzeichnen zu können ohne das programm selber dafür abstürzen zu lassen, es ist also auch ein instrument überhaupt erst zu erfahren woran man noch arbeiten sollte! das ist vorallem einer einer stark ergebnisoriterten softwareentwickling wichtiger als unbedingt alle hürden schon vorher zu wissen/zu kennen (der idealfall).



    1 mal bearbeitet, zuletzt am 17.05.15 00:58 durch Moe479.

  17. Re: Wird wirklich noch mit Performance argumentiert..?

    Autor: Moe479 17.05.15 - 00:51

    solange es für einen selbst günstiger ist einen größeren/besseren aku zu verwenden ... ist dieses begehren offensichtlich für die katz!

  18. Ja, weil es relevant ist.

    Autor: Hello_World 17.05.15 - 03:50

    kim3000 schrieb:
    --------------------------------------------------------------------------------
    > Warum wird eigentlich immer noch mit Performance argumentiert wo doch die
    > Performancewerte vieler Programmiersprachen sich annaehern und
    > allerhoechstens noch die dynamischen Sprachen weit abgeschlagen sind.
    Das stimmt schlichtweg nicht. Die Benchmarks beispielsweise für Java (http://benchmarksgame.alioth.debian.org/u64q/java.html) zeigen nach wie vor, dass beispielsweise Java nach wie vor um einen Faktor 2-4 langsamer ist als C. Ganz zu schweigen davon, dass ein GC erstens den Speicherverbrauch explodieren lässt und zweitens die Umsetzung von Echtzeit-Anwendungen zumindest erschwert.
    Und die Auswirkungen sind erheblich, und zwar am unteren wie am oberen Ende der Skala. Mobile Systeme sind auf niedrigen Energieverbrauch angewiesen, da sie mit Batterien betrieben werden. Bei großen Rechenzentren ist der Stromverbrauch ein wesentlicher Kostenfaktor, hinzu kommen erhebliche Kosten für die Kühlung, die natürlich ebenfalls mit dem Stromverbrauch ansteigt. Und bei kleinsten embedded-Devices mit großen Stückzahlen will man jedes MB RAM einsparen, weil das auch wieder einen Kostenfaktor darstellt.

    > Im Vergleich zu C/C++ gibt es einige im Artikel genannte High-Level
    > Sprachen deren Performancewerte gleichauf bzw. im einstelligen
    > Prozentbereich kleiner sind. Ich glaube Rust kommt da noch nicht mal ran.
    Die derzeitigen Benchmark-Werte sagen nicht viel aus, da noch nicht allzu viel in die Optimierung des Compilers investiert wurde. Das entscheidende ist, dass man die richtigen Grundlagen legt, damit die Sprache später gut optimiert werden kann, und das ist geschehen: kein Boxing, Stack-allokierte Closures, Generics per Monomorphisierung etc. pp..

    > Der Grund warum man immer noch C/C++ nutzt ist vor allem historischer Natur
    > und dass man nunmal ein gewachsenes Oekosystem hat, dass man nicht einfach
    > komplett neu entwickeln will. Und sind auch alle Experten auf dem Gebiet
    > auf C/C++ eingeschossen und ein alter Gaul lernt keine neuen Tricks mehr.
    > Darueberhinaus gibt es auch noch technische Gruende warum man C/C++
    > braucht/nutzt. Und mit nutzt meine ich fuer Endkundensoftware nutzt. Dass
    > NUR das OS und Core libraries C/C++ nutzen waere ein moeglicher Schritt.
    > Und Endkundensoftware wie Firefox wuerde dann auf diese Core-OS Funktionen
    > zugreifen - allerdings nicht mehr mit C/C++. Das waere schon alles moeglich
    > und ohne messbare Performanceverluste.
    Quark, der Browser ist heute nicht mehr irgendeine generische Endkundensoftware, sondern eine Laufzeitumgebung für komplexe Webanwendungen. Was die Performance angeht ist da das beste gerade gut genug. Nur gilt das gleiche eben auch für die Sicherheit, und deswegen braucht es eine Sprache wie Rust, die beides unter einen Hut bringt. Zumal Rust durch seinen Fokus auf Parallelisierung das Potential birgt, C++ in Sachen Performance noch deutlich zu übertreffen.

  19. Re: Ja, weil es relevant ist.

    Autor: kim3000 17.05.15 - 08:53

    1. den Benchmark den du zitierst ist ziemlich bedeutungslos. Auch gings mir nicht um Java.

    2. Sowohl mit dem Stromverbrauch als auch mit der Performance hat es bei Android ausgereicht. Und das mit der Hard- und Software von 2007 als es rauskam. Und die neue ART uebersetzt jetzt unabhaengig von der Sprache in nativen Code anstatt JIT zu nutzen.

    3. Wie du selbst im letzten Abschnitt in Bezug auf Rust zugibst, spielt Parallelisierung eine immer wichtigere Rolle. Cleveres Programmieren ist oft wichtiger als die Sprache selbst beim Thema Performance.
    Genauso wie du richtig feststellst, dass ein Browser irrsinnig komplex ist. Nur ziehst du daraus die falschen Schluesse. Die Sprache in der man den Browser schreibt ist fuer die Performance nicht zwangslaeufig bestimmend, selbst wenn zwischen Sprache A und Sprache B der Performanceunterschied bei aussagelosen Mini-Benchmarks bei 100% liegt.
    Die Frage ist, wie gut ist der Code paralellisiert. Wie ist die UI programmiert und werden da Engstellen bspw. Warten auf die Antwort der Website elegant vom User "versteckt". Friert der Browser bei einem Engpass komplett UI-technisch ein, oder kann man zu einem anderen Tab springen und dort weiterlesen bis der aktuelle Tab mit dem fertig ist was er gerade macht. Usw.

    Deswegen verstehe ich immer noch nicht warum weiterhin mit synthetischen Benchmarks fuer Sprache X oder Y geworben wird. Allein beim Thema Browser sieht man, dass ich echt nicht beeindruckt bin vom Endprodukt...ob Firefox, Chrome oder was auch immer.

  20. Re: Ja, weil es relevant ist.

    Autor: pythoneer 17.05.15 - 10:07

    kim3000 schrieb:
    --------------------------------------------------------------------------------
    > 1. den Benchmark den du zitierst ist ziemlich bedeutungslos. Auch gings mir
    > nicht um Java.

    Du darfst uns dümmliche Idioten gerne darüber aufklären, warum das so ist, danke für deine Erleuchtung.


    > 2. Sowohl mit dem Stromverbrauch als auch mit der Performance hat es bei
    > Android ausgereicht.

    Richtig formuliert: "ausgereicht" und Google hat eine Menge Aufwand treiben müssen, damit sie es schaffen, dass es ausreicht. Ich bin selber Android Nutzer und Entwickler und die großen Knackpunkte bei Android sind nun mal leider Stromverbrauch und Performance womit Android schon seit Anbeginn zu kämpfen hat.

    > Und das mit der Hard- und Software von 2007 als es
    > rauskam. Und die neue ART uebersetzt jetzt unabhaengig von der Sprache in
    > nativen Code anstatt JIT zu nutzen.

    Ja, genau wie du sagst, Google treibt einen ungeheurer Aufwand um konkurrenzfähig zu bleiben.


    > 3. Wie du selbst im letzten Abschnitt in Bezug auf Rust zugibst, spielt
    > Parallelisierung eine immer wichtigere Rolle. Cleveres Programmieren ist
    > oft wichtiger als die Sprache selbst beim Thema Performance.

    Hast du dir Rust zum Thema Parallelisierung angesehen? Dort wird eigentlich sehr schön deutlich wie man das clever in eine Sprache integrieren kann, damit man keine cleveren Programmierer mehr braucht, damit man nicht völligen Unsinn fabriziert – nie wider Data-Races, danke Rust. Und da braucht man sich gar nicht als Elite-Hacker hinstellen und sagen "ich brauch sowas ja eh nicht" oder "Entwickler die gut programmieren können brauchen sowas nicht" das ist Unsinn. Sowas spart einfach Zeit, Kraft und Energie die man in andere Aspekte investieren kann. Wenn mir der Compiler sagen kann:"Hey, so nicht, hier kann es zu data races in deinem parallelen code kommen" dann spart mir das einfach nen Haufen Arbeit ... allein schon das später nicht debuggen zu müssen.

    > Genauso wie du richtig feststellst, dass ein Browser irrsinnig komplex ist.
    > Nur ziehst du daraus die falschen Schluesse. Die Sprache in der man den
    > Browser schreibt ist fuer die Performance nicht zwangslaeufig bestimmend,
    > selbst wenn zwischen Sprache A und Sprache B der Performanceunterschied bei
    > aussagelosen Mini-Benchmarks bei 100% liegt.
    > Die Frage ist, wie gut ist der Code paralellisiert.

    Dann schau dir mal die Servo-Beispiele an (mit Rust erstellt) das was Servo heute vollführt (verschiedene Teile eine Website auf unterschiedlichen Cores Layouten) ist schon immens beeindruckend und das liegt genau daran, dass es mit Rust so unheimlich einfach ist, sicheren parallelen Code zu schreiben und das liegt eben genau an Rust selber. Und genau hier kann es zu einem von dir zitierten Performanceunterschied kommen der primär nichts mit der Ausführungsgeschwindigkeit des Codes zu tun hat. Es kann nämlich passieren, dass man in Sprache A sagt: "Wow, das zu parallelisieren ist viel zu aufwendig, das lassen wir lieber sequenziell, das lohnt den Aufwand nicht" oder man sagt in Sprache B: "Ja klar können wir das machen, ist zwar Aufwand, allerdings bewahrt uns der Compiler davor da Unsinn zu machen, also kein großen Problem". Somit hast du in Sprache B dann einen parallelen Kontrollfluss und in Sprache A nicht, was dein Programm in Sprache B dann schneller macht, weil es dort einfacher ist es schnell zu bekommen.

    > Deswegen verstehe ich immer noch nicht warum weiterhin mit synthetischen
    > Benchmarks fuer Sprache X oder Y geworben wird. Allein beim Thema Browser
    > sieht man, dass ich echt nicht beeindruckt bin vom Endprodukt...ob Firefox,
    > Chrome oder was auch immer.

    Benchmarks sind ein Argument aber kein Grund für oder gegen eine Sprache. Sie dienen als Entscheidungsgrundlage um abschätzen zu können ob sich eine Sprache für den Einsatzbereich der Anwendung eignet. Das musst du irgendwie missverstanden haben – hier hat keiner behauptet:"Hey guck die Sprache ist 'schneller' also generell für alles besser". Wenn das dein einziger Kritikpunkt ist, dann sei er hiermit aus der Welt geschafft.



    2 mal bearbeitet, zuletzt am 17.05.15 10:16 durch pythoneer.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ManpowerGroup Deutschland GmbH & Co. KG, Kiel
  2. Proximity Technology GmbH, Hamburg
  3. Adecco Personaldienstleistungen GmbH, Erfurt
  4. spectrumK GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. ab 369€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Super Mario Maker 2 & Co.: Vom Spieler zum Gamedesigner
Super Mario Maker 2 & Co.
Vom Spieler zum Gamedesigner

Dreams, Overwatch Workshop und Super Mario Maker 2: Editoren für Computerspiele werden immer mächtiger, inzwischen können auch Einsteiger komplexe Welten bauen. Ein Überblick.
Von Achim Fehrenbach

  1. Nintendo Switch Wenn die Analogsticks wandern
  2. Nintendo Akku von überarbeiteter Switch schafft bis zu 9 Stunden
  3. Hybridkonsole Nintendo überarbeitet offenbar Komponenten der Switch

Mobilfunktarife fürs IoT: Die Dinge ins Internet bringen
Mobilfunktarife fürs IoT
Die Dinge ins Internet bringen

Kabellos per Mobilfunk bringt man smarte Geräte am leichtesten ins Internet der Dinge. Dafür haben deutsche Netzanbieter Angebote für Unternehmen wie auch für Privatkunden.
Von Jan Raehm

  1. Smart Lock Forscher hacken Türschlösser mit einfachen Mitteln
  2. Brickerbot 2.0 Neue Schadsoftware möchte IoT-Geräte zerstören
  3. Abus-Alarmanlage RFID-Schlüssel lassen sich klonen

Erasure Coding: Das Ende von Raid kommt durch Mathematik
Erasure Coding
Das Ende von Raid kommt durch Mathematik

In vielen Anwendungsszenarien sind Raid-Systeme mittlerweile nicht mehr die optimale Lösung. Zu langsam und starr sind sie. Abhilfe schaffen können mathematische Verfahren wie Erasure Coding. Noch existieren für beide Techniken Anwendungsgebiete. Am Ende wird Raid aber wohl verschwinden.
Eine Analyse von Oliver Nickel

  1. Agentur für Cybersicherheit Cyberwaffen-Entwicklung zieht in den Osten Deutschlands
  2. Yahoo Richterin lässt Vergleich zu Datenleck platzen

  1. Festnetz: Deutsche Telekom hat mehr FTTH als Deutsche Glasfaser
    Festnetz
    Deutsche Telekom hat mehr FTTH als Deutsche Glasfaser

    Die Deutsche Telekom hat überraschend den Spitzenplatz bei der Versorgung mit FTTH für sich beansprucht. Zugleich gibt die Telekom zu, dass deutlich weniger als die Hälfte der versorgten Haushalte FTTH auch buchen.

  2. Arbeitsspeicher: Ryzen 3000 rechnet mit DDR4-3733-CL16 am schnellsten
    Arbeitsspeicher
    Ryzen 3000 rechnet mit DDR4-3733-CL16 am schnellsten

    AMDs Zen-2-CPUs unterstützen offiziell DDR4-3200, können aber auch mit deutlich höher getaktetem Speicher umgehen. Ein umfangreicher Test zeigt, dass DDR4-3733 mit relativ straffen Latenzen derzeit das Optimum für die Ryzen 3000 darstellt, weil so auch die interne Fabric-Geschwindigkeit steigt.

  3. UL 3DMark: Feature Test prüft variable Shading-Rate
    UL 3DMark
    Feature Test prüft variable Shading-Rate

    Nvidia unterstützt es bereits, AMD und Intel in den nächsten Monaten: Per Variable Rate Shading werden in PC-Spielen bestimmte Bereiche mit weniger Aufwand gerendert, idealerweise solche, die nicht ins Auge fallen. Der 3DMark zeigt bald, wie unter Direct3D 12 die Bildrate ohne größere Qualitätsverluste steigen soll.


  1. 19:25

  2. 18:00

  3. 17:31

  4. 10:00

  5. 13:00

  6. 12:30

  7. 11:57

  8. 17:52