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

[D ist schnell!]

Hier hat sich mal einer die Mühe gemacht D mit C++ beim Stringhandling zu vergleichen und D liegt Meilenweit vorne, was auch seine Gründe in der Sprache hat, siehe weiter unten.

Hier eine Übersicht der verwendeten XML Parser:
http://dotnot.org/blog/archives/2008/03/09/xml-benchmarks-pros-and-cons-of-each-library/

Und hier die Ergebnisse:
(RapidXml ist der C++ Parser, lib2xml der C Parser und Tango der D Parser)
http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/

Und hier die Begründung warum D so weit vorne liegt:
http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

Und auf folgender Seite hat man die obigen Artikel alle auf einer Seite, aber man muß nach unten Scrollen:
http://dotnot.org/blog/index.php

[D ist schnell!]

BTW wenn es interessiert, hier ist ein Interview des Erfinders von

http://www.computerworld.com.au/article/253741/a-z_programming_languages_d/?fp=4194304&fpid=1

Da kann man nachlesen warum er D erfunden hat.

[hustbaer]

äh.
und nu?

[Gast]

hustbaer schrieb:

äh.
und nu?

Jetzt ist D halt eine 2-3 mal schnellere Totgeburt als C++

[IPH]

Tim schrieb:

hustbaer schrieb:

äh.
und nu?

Jetzt ist D halt eine 2-3 mal schnellere Totgeburt als C++

Aber nur beim Parsen von xml. Oder sind Sprachen inzwischen schnell weil mal jemand darin eine schnelle Library baut?

[hustbaer]

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

Ändert aber nichts daran dass D im Vergleich zu C++ einfach "keiner" verwendet. Und es daher auch ziemlich egal ist, wie schnell eine Implementierung von Problem/Algorithmus X in D ist.

Zumindest so lange D nicht gleich 10 mal oder mehr schneller ist. (Ab einer bestimmten Grössenordnung würde es sich natürlich auch auszahlen "unübliche" Sprachen für ein bestimmtes Problem zu verwenden.)

p.S.: mir ist durchaus auch bewusst dass eine wirklich performante String-Implementierung in C++ sehr schwer zu machen ist, bzw. nahezu unmöglich, da a) Garbage Collection fehlt und b) jeder nullterminierte Strings haben will - damit man "direkt" C APIs damit aufrufen kann.

[rapso]

hustbaer schrieb:

da a) Garbage Collection fehlt

wenn man einen eigenen allokator schreibt ist man weit schneller.

b) jeder nullterminierte Strings haben will - damit man "direkt" C APIs damit aufrufen kann.

das ist nicht zwingend wenn man einen xml parser schreibt.

gibt es die zwei xml files irgendwo zum download? ich wuerde die gerne bei meinem parser durch den unittest jagen.

[Artchi]

Kommt doch auch sicherlich darauf an, mit welchem Compiler und welche StdLib-Impl man benutzt hat. Sicherlich auch welcher Allokator. Und dann auch welche XmlLib... wobei ich einfach mal blind vertraue, das RapidXML die schnellste von allen C++-XML-Parsern ist.

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.

[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!