D Programming Language ist 2-3 mal schneller als C++ beim Parsen von XML. Benchmarkergebnisse inside!

[D ist schneller!]

Artchi schrieb:

Aber warum sollte der D-XML-Parser nicht so schnell sein? Es ist schließlich auch nativer Code, und wenn der D-Compiler und Tango gut sind, muß halt C++ nachlegen. Das gute ist, C++ kann das wieder einholen, da D und C++ im selben Revier wildern.

C++ kann bei Strings prinzipbedingt nie so gut sein wie D.
Warum das so ist steht hier:

Strings in D sind wohl um einiges einfacher als in C oder C++. Es wird nicht nur Sicherheit sondern auch Geschwindigkeit durch das Konzept in D gefördert. Wärend in C Pufferüberläufe mal schnell geschehen und schwere Folgen haben, kann das in D nicht passieren, solange man nicht die selben Mittel wie in C verwendet. Zwar gibt es in C++ extra Klassen, aber das sind keine schlanken eleganten Lösungen. Wie performant das ganze am Ende auch ist, sieht man am Tango XML Benchmark. Das liegt auch daran, dass man in D Objekte auch auf dem Stack ablegen kann und nicht aufwendig Speicher auf dem Heap allozieren muss.

http://www.softchecker.net/upload/viewtopic.php?p=2260#p2260

[C++Fan 2010]

D ist schneller! schrieb:

C++ kann bei Strings prinzipbedingt nie so gut sein wie D.
Warum das so ist steht hier:

Das ist Unfug. Du hast in beiden Sprachen alle Möglichkeiten.

[knivil]

Das liegt auch daran, dass man in D Objekte auch auf dem Stack ablegen kann und nicht aufwendig Speicher auf dem Heap allozieren muss.

Nee, das geht wirklich nicht in C++. Ich frage mich staendig, warum meine Programme trotzdem kompilieren.

Why is D/Tango so fast at parsing XML?
* Array slicing
* Native code
* Avoid heap allocation as much as possible
* Design choices

Von den Gruenden scheint nur einer direkt D zu betreffen.

[Zeus]

Fütter blos nicht die fanatischen D Anhänger!

[dasher]

hustbaer schrieb:

BTW: std::string ist IMO wirklich eine scheiss Implementierung.

Kannst du das mal ein bischen begründen. Wenn sie so funktionieren wie ich denke, würde mir fast kein besserer Weg einfallen.

Gruß

[Michael E.]

D ist schneller! schrieb:

C++ kann bei Strings prinzipbedingt nie so gut sein wie D.
Warum das so ist steht hier:

Strings in D sind wohl um einiges einfacher als in C oder C++. Es wird nicht nur Sicherheit sondern auch Geschwindigkeit durch das Konzept in D gefördert. Wärend in C Pufferüberläufe mal schnell geschehen und schwere Folgen haben, kann das in D nicht passieren, solange man nicht die selben Mittel wie in C verwendet. Zwar gibt es in C++ extra Klassen, aber das sind keine schlanken eleganten Lösungen. Wie performant das ganze am Ende auch ist, sieht man am Tango XML Benchmark. Das liegt auch daran, dass man in D Objekte auch auf dem Stack ablegen kann und nicht aufwendig Speicher auf dem Heap allozieren muss.

Hier versucht wohl jemand ganz schnell, frickys Erbe anzutreten, nur noch viel, viel schlechter.

[hustbaer]

Er.
Sorry.
Ich meine natürlich das Interface. Dummer Fehler

Die Implementierung ist ja jedem Hersteller selbst überlassen. Und im Rahmen des vorgeschriebenen Interface sind die bestehenden Implementierungen gar nicht so schlecht.

@rapso:
Je mehr ich darüber nachdenke, desto mehr komme ich zu dem Schluss: man kann in C++ auch ohne GC einen sehr sehr flotten XML Parser schreiben, auch mit nullterminierten Strings.

Wenn man z.B. nur mit char/wchar_t Zeigern arbeitet (bzw. begin/end Zeigerpaaren), und die Gültigkeit/Lebenszeit dieser Zeiger mit der des "Dokuments" verknüpft.

[Icematix]

Michael E. schrieb:

Hier versucht wohl jemand ganz schnell, frickys Erbe anzutreten, nur noch viel, viel schlechter.

Och, bis auf seine Abneigung gegen C++ ist fricky doch ein netter Kerl, was man von dem D-Fanat nicht behaupten kann

[Michael E.]

Icematix schrieb:

Och, bis auf seine Abneigung gegen C++ ist fricky doch ein netter Kerl, was man von dem D-Fanat nicht behaupten kann

Stimmt auch wieder. Auch zeigt das Zitat größte Ahnungslosigkeit. Deswegen war der Vergleich wohl nicht gerechtfertigt.

[hustbaer]

dasher schrieb:

hustbaer schrieb:

BTW: std::string ist IMO wirklich eine scheiss Implementierung.

Kannst du das mal ein bischen begründen. Wenn sie so funktionieren wie ich denke, würde mir fast kein besserer Weg einfallen.

Gruß

Siehe mein Posting gerade eben: ich meinte die Definition des std::string Interface, nicht eine spezielle Implementierung. Mein Fehler.

Da du mich aber vermutlich eh richtig verstanden hast...

Das grösste Problem an std::string ist, dass std::string "mutable" ist. Speziell: dass die Iteratoren von std::string keine "const iterator" sind, und dass der Indexing-Operator ("operator []") eine mutable Referenz (!) zurückgibt.
(Würde eine Kopie des Characters von [] zurückgegeben wäre alles viel besser)

Zwar gibt es auch "const" Overloads von begin/end/[], nur muss man leider explizit casten, wenn man diese auf ein non-const Objekt aufrufen will:

void foo::bar()
{
    m_str = ...;
    for (size_t i = 0; i < s.size(); i++)
    {
        char c = m_str[i]; // ruft die non-const version auf
//      char c = static_cast<std::string const&>(m_str)[i]; // bäh, tut sich kein mensch an das so zu schreiben
        ...
    }
}

Das bedeutet, dass man zwar eine COW (Copy-On-Write) Implementierung von std::string machen kann, dass diese aber an vielen Stellen kopieren muss, wo gar keine Kopie nötig wäre.

Im oben gezeigten Code ist für jeden klar ersichtlich, dass m_str nur gelesen, aber nicht modifiziert wird. Leider müsste eine COW Implementierung aber trotzdem bereits eine Kopie erstellen, da der Code oben die non-const Version des operator [] aufruft, die leider eine mutable Referenz zurückgibt, über die wir den Inhalt des Strings modifizieren könnten.

Eine Trennung in einen String-Builder und eine "dumme" String-Klasse, wobei man die "dumme" String-Klasse nur zuweisen/kopieren, aber nicht "in-place" modifizieren kann, wäre da günstiger. Die "dumme" String-Klasse könnte dann nämlich überall problemlos COW verwenden. Und die String-Builder Klasse käme an den meisten Stellen wo jetzt std::string eingesetzt wird nicht mehr zum Einsatz.

Weiters fehlt in C++, sobald Multi-Threading ins Spiel kommt, ein Werkzeug, mit dem man COW überhaupt performant umsetzen kann. Zumindest wenn man nicht stark Plattform abhängigen Code schreiben will, der noch dazu einiges an Kenntnissen erfordert um ihn korrekt hinzubekommen.
Gut, letzteres hat jetzt nichts mit dem Interface von std::string zu tun, spielt aber auch allgemein mit rein, wenns um C++ und (performante) Strings geht.

[hustbaer]

Icematix schrieb:

Och, bis auf seine Abneigung gegen C++ ist fricky doch ein netter Kerl, was man von dem D-Fanat nicht behaupten kann

sein ewiges rumgetrolle, ignorieren von guten argumenten + logischen schlussfolgerungen + sich über leute lustig machen die bloss etwas beschreiben was er nicht kennt und daher nicht auch nicht beurteilen kann (nämlich C++, was er auch selbst zugibt). frei nach dem motto "ich hab zwar keine ahnung von dem was du da schreibst, sag dir aber trotzdem dass alles was du schreibst unsinn ist".
ja, klar. netter kerl beschreibt das sehr gut.

[Aha!]

D ist schneller! schrieb:

Das liegt auch daran, dass man in D Objekte auch auf dem Stack ablegen kann und nicht aufwendig Speicher auf dem Heap allozieren muss.

Also das klingt interessant!

[D ist schneller!]

knivil schrieb:

Das liegt auch daran, dass man in D Objekte auch auf dem Stack ablegen kann und nicht aufwendig Speicher auf dem Heap allozieren muss.

Nee, das geht wirklich nicht in C++. Ich frage mich staendig, warum meine Programme trotzdem kompilieren.

Why is D/Tango so fast at parsing XML?
* Array slicing
* Native code
* Avoid heap allocation as much as possible
* Design choices

Von den Gruenden scheint nur einer direkt D zu betreffen.

Nein, es sind im Bezug auf C++ genaugenommen zwei Gründe.

1. Array slicing
Das kann C++ nicht, zumindest nicht mit Bordmitteln, man müßte schon darum herumprogrammieren und was eigenes bauen.

2. Avoid heap allocation as much as possible

Die anderen Dinge beziehen sich auf die anderen XML Parser.
Manche benutzen z.B. Java und das ist wiederum kein native Code.

Aber im Prinzip ist es doch auch egal, denn die Benchmarks sind hier eindeutig.
RapidXML ist für C++ schon einer der besten, schnellsten und effizientesten Parser den es gibt, aber Tango schlägt ihn dank D trotzdem.

[D ist schneller!]

Zeus schrieb:

Fütter blos nicht die fanatischen D Anhänger!

FUD

Ich denke so mancher alter C++ Hase hat einfach nur Angst vor D, weil er dann umlernen müßte, aber dafür schon zu alt ist.

D wird seinen Weg schon bahnen.
Jetzt muß erstmal D 2.0 fertig werden und dann kommen auch die guten Compiler.
Python hat 15 Jahre gebraucht um in der Industrie anzukommen, diese Zeit sollte man auch D geben, das ja mit Version 1.0 erst seit ca. 3 Jahre als fertige stabile Version auf dem Markt ist.

Fakt ist aber nunmal, daß man mit D deutlich effizienter und schneller programmieren kann als mit C oder C++.
Man braucht weniger Zeit um zum Ziel zu kommen.

D bietet hier die Vorteile, wie sie auch Java und C# bieten, aber im Gegensatz zu diesen beiden eignet sich D für die Systemprogrammierung.
D ist native Code und braucht keine VM.

Für Projekte in denen Performance, leichte Wartbarkeit, guter Workflow und schnell zum Ziel kommen wichtig sind, ist D ideal geeignet.
Für ein Computerspiel in der Zeit so knapp und kostbar bzw. teuer ist, wäre D absolut super geeignet.
Wenn die Entwickler damit 3-4 Monate Arbeitszeit einsparen, dann ist hier schon sehr viel gewonnen.

[D ist schneller!]

Michael E. schrieb:

Icematix schrieb:

Och, bis auf seine Abneigung gegen C++ ist fricky doch ein netter Kerl, was man von dem D-Fanat nicht behaupten kann

Stimmt auch wieder. Auch zeigt das Zitat größte Ahnungslosigkeit. Deswegen war der Vergleich wohl nicht gerechtfertigt.

Na dann beweis mal anhand von Code!

[otze]

D ist schneller! schrieb:

Nein, es sind im Bezug auf C++ genaugenommen zwei Gründe.

1. Array slicing
Das kann C++ nicht, zumindest nicht mit Bordmitteln, man müßte schon darum herumprogrammieren und was eigenes bauen.

Ja, das ist Schade, dass es das nicht gibt. Für die trivialen Fälle gibt es aber immernoch die Iteratoren. Solange du also nicht Sachen machst, wie "nimm jedes zweites Element", kommst du damit exakt genausogut um die Ecke. Die Syntax ist halt nur ein wenig ätzender.

2. Avoid heap allocation as much as possible

DAS sollte eigentlich auch das Ziel jedes C++ Programmierers sein.

Nebenbei halte ich diesen Test nicht für Aussagekräftig. Wnen du dir die langsamen C-libs anschaust, dann sind das auch die, die komplett Standardkonform sind. Es scheint also auch eine Korrelation zwischen Konformität und Geschwindigkeit zu geben. Das wurde leider im Test nicht berücksichtigt.

[Michael E.]

D ist schneller! schrieb:

Na dann beweis mal anhand von Code!

Was soll ich beweisen? Dass ich schon wieder mit Trollen rede?

[hustbaer]

D ist schneller! schrieb:

Zeus schrieb:

Fütter blos nicht die fanatischen D Anhänger!

FUD

Ich denke so mancher alter C++ Hase hat einfach nur Angst vor D, weil er dann umlernen müßte, aber dafür schon zu alt ist.

D wird seinen Weg schon bahnen.
Jetzt muß erstmal D 2.0 fertig werden und dann kommen auch die guten Compiler.
Python hat 15 Jahre gebraucht um in der Industrie anzukommen, diese Zeit sollte man auch D geben, das ja mit Version 1.0 erst seit ca. 3 Jahre als fertige stabile Version auf dem Markt ist.

Dann komm bitte in 12 Jahren wieder, und hör bis dahin auf zu nerven.
Immer diese Fanboys...

[Ichhasseleutediemittenim]

D ist schneller! schrieb:

Zeus schrieb:

Fütter blos nicht die fanatischen D Anhänger!

Ich denke so mancher alter C++ Hase hat einfach nur Angst vor D, weil er dann umlernen müßte, aber dafür schon zu alt ist.

Wieso umlernen? - Wenn dann dazu lernen (-;