3. Programmlaufzeitfrage

Programmlaufzeitfrage

  • V

    Plotzenhotz schrieb:

    Genauso nervt es mich aber auch wenn dann jmd. hergeht und behauptet es gäbe garkeinen Grund dass A langsamer als B ist.

    ich sage aber weiterhin: es gibt gar keine notwendigkeit, daß iostream lahmer als stdio ist.
    darüberhinaus möchte ich behaupten, daß da anscheinend auf breiter front gepfuscht wird. bei MS kann ich mir ja noch denken, daß es nur drum geht, VB unbd C# schneller aussehen zu lassen. bei gcc weiß ich's nicht. vielleicht sind die vorgaben im standard ja schon so, daß es dafür keine schnelle implementierung geben kann, ohne daß die exe-datei noch 200k größer wird.

    0
  • ?

    Ja vielleicht hab ich mich in diesem Thread auch nicht richtig ausgedrückt. Mir ging es alleine um die Feststellung dass die derzeitigen iostreams Implementierungen die ich kenne, und von denen ich diverse Benchmarks im Netz gelesen habe, alle langsamer sind als stdio.
    Zu behaupten dass es immer so sein muss war ein Fehler - das kann ich nicht beurteilen ohne den Standard wesentlich besser zu kennen als ich es tue.

    0
  • V

    Plotzenhotz schrieb:

    Mir ging es alleine um die Feststellung dass die derzeitigen iostreams Implementierungen die ich kenne, und von denen ich diverse Benchmarks im Netz gelesen habe, alle langsamer sind als stdio.

    ok.
    mir war bekannt, daß cout derzeit überall lahmer ist als printf, obwohl es technische gründe gibt, weshalb cout schneller sein sollte.
    jetzt ist mir dank dieses threads zusätzlich bekannt, daß zeilenlesen mit ifstream deutlich lahmer ist als mit FILE*, obwohl es dafür gar keinen technischen grund gibt.
    vermutlich hat gar nicht bjarne s. diese sprache erfunden. das war noch mitten im kalten krieg. die russen haben sie erfunden, um die westliche entwicklung der computerwissenschaften lahmzulegen. also sie ist schonmal so kompliziert, daß man selbst als vollprofi libs schreibt, die lahm sind und 10 jahr später noch keiner schnelle libs gebaut hat (im gegenteil, so lahm wie bei ms heute waren sie nie, vermute ich). vielleicht ist nichtmal c++ allein dfas problem, sondern die ganze objektorientierung. java ist ja auch nicht berühmt für schnelle dateifilteroperationen. ich werde das mal beobachten und bei gelegenheit kaufe ich mir in ebay einen 64-er. kann ja sein, daß die entwicklung so weitergeht und ich dann mit dem 64-er schneller bin.

    0
  • S

    Plotzenhotz schrieb:

    Ja vielleicht hab ich mich in diesem Thread auch nicht richtig ausgedrückt. Mir ging es alleine um die Feststellung dass die derzeitigen iostreams Implementierungen die ich kenne, und von denen ich diverse Benchmarks im Netz gelesen habe, alle langsamer sind als stdio.
    Zu behaupten dass es immer so sein muss war ein Fehler - das kann ich nicht beurteilen ohne den Standard wesentlich besser zu kennen als ich es tue.

    Wenn du da nen halbwegs fairen Vergleich machen willst musst du direkt mit dem streambuf der Streamklassen arbeiten.
    So ist z.B. das gleichwertige C++ Gegenstück zu getc nicht istream::get sondern streambuf::sbumpc.
    Die Streamklassen kapseln den Streambuffer und sind vollgestopft mit Status und Fehlercode.Das ist imho zusätzlicher Overhead den die mit sich rum schleppen.

    Gruß Spacelord

    0
  • ?

    @Spacelord: neh, will ich garnicht. Wenn ich irgendwo Speed brauche dann gehe ich "Byte klauben" wie ich das nenne.

    @volkard: Ich weiss nicht wie ich deinen Sarkasmus auffassen soll. Hilfreich ist er auf jeden Fall nicht.

    0
  • V

    Plotzenhotz schrieb:

    @Spacelord: neh, will ich garnicht. Wenn ich irgendwo Speed brauche dann gehe ich "Byte klauben" wie ich das nenne.

    meinste damit ne eigene stream-klasse? so mache ich das auch.

    Plotzenhotz schrieb:

    @volkard: Ich weiss nicht wie ich deinen Sarkasmus auffassen soll. Hilfreich ist er auf jeden Fall nicht.

    nee. hilfreich nicht.
    ich denke, die c++-gemeinde muss auch immer wieder aufs neue darüber aufgeklärt werden, daß das standardisierungskomitee keine besseren entscheidungen trifft, als es drei bekiffte gute fachhochschüler in der gleichen zeit täten.
    wem hilft dies wissen? niemandem. also nicht hilfreich, wie gesagt. aber ich muß gleichermaßen äußern, daß ich hier ein problem sehe, wie die wahlcomputerfeiglinge dort ein problem sehen.

    0
  • ?

    meinste damit ne eigene stream-klasse? so mache ich das auch.

    Nö, eine eigene Stream-Klasse hab' ich nu grad nicht, bei mir endet es meist mit spezialisierten Lösungen in denen nicht selten die native API vorkommt (WIN32 halt in meinem Fall). Ich muss ja gottseidank keinen plattformunabhängigen Code schreiben, obwohl ich auch zusehe dass ich die plattformabhängigen Teile irgendwo schön kapseln kann. Mit "Byte klauben" meine ich einfach auf unterster Ebene Code schreiben, selbst "Bytes durch die gegend schieben" etc. Und hätte ich viel mit Textdaten zu tun dann hätte ich wahrscheinlich auch ne eigene Stream-Klasse 🙂

    ich denke, die c++-gemeinde muss auch immer wieder aufs neue darüber aufgeklärt werden, daß das standardisierungskomitee keine besseren entscheidungen trifft, als es drei bekiffte gute fachhochschüler in der gleichen zeit täten.
    wem hilft dies wissen? niemandem. also nicht hilfreich, wie gesagt. aber ich muß gleichermaßen äußern, daß ich hier ein problem sehe, wie die wahlcomputerfeiglinge dort ein problem sehen.

    Gut. Ich meinte das "weiss nicht wie ich deinen Sarkasmus auffassen soll" nämlich durchaus ernst, hätte ja auch sein können dass du dich über mich oder über das Thema oder sonstwas lustig machst. Mir war also wirklich nicht klar wie ich es auffassen sollte.

    Damit dass du dir Luft machen wolltest hab ich kein Problem, das geht mit bei C++ oft genug selbst so. Und über den ollen VC6 könnte ich den ganzen Tag lang schimpfen, ich muss den in der Arbeit noch oft verwenden, und der Grossteil der Libs an denen ich arbeite muss unter VC6 noch laufen 😡

    0
  • H

    @volkard
    Ich denke man sollte von Einzelfällen nicht immer gleich auf das Ganze schließen. Nur weil std::string, std::iostreams und export in die Hose gegangen sind, heißt das nicht, dass der ganze C++ Standard von bekifften Fachhochschülern gleichwertig hätte entwickelt werden können.

    Es gibt genügend Beispiele, wo Lib und Sprache von den Experten profitiert haben. Und dies scheint auch so zu bleiben.
    Beispiel: http://www.artima.com/cppsource/threads_meeting.html

    Nicht mehr nur @volkard:

    Bw: wenn ich mir das ganze gewurschtel mit den loclaes und facetts anschaue, bezweifle ich auch, dass die iostreams wirklich so superschnell implementiert werden können. locales und facetts sind pro Stream dynamisch austauschbar, können deshalb wohl kaum sinnvoll über statischen Polymorphismus implementiert werden (im Gegensatz zu den Type-Traits). D.h. am Ende bleibt ne Menge Indirektion und viele virtuelle Aufrufe. Dafür bekomme ich halt auch viel Flexibilität.

    Auf der anderen Seite: wenn wirklich die Ein-/Ausgabe der performance-kritische Teil meines Programms ist, dann erscheint es mir nur logisch, dass ich in diesem Bereich selbst optimieren muss und die "general-purpose"-Lösung nicht das non-plus-ultra ist. Das ist doch immer so. Wichtiger ist doch, dass die iostreams für Standardaufgaben ausreichen und das tun sie allemal. Zumindest ist das meine Erfahrung.

    Diese ganze Performance-Geschichte hat natürlich auch mal wieder nichts mit C vs. C++ zu tun. Vielmehr ist sie ein Beispiel dafür, dass konkret, klein und einfach meistens zügiger läuft als abstrakt, groß und flexibel. Würde man die iostreams in C nachbauen, käme man auf eine ähnliche Performance wie in C++.

    0
  • S

    @Plotzenhotz:
    Änder dein Testprogramm mal etwas ab.
    Ich hab hier mal nen kleines Minimal-getline geschrieben:

    std::streamsize my_getline(std::istream& is,char* buf,std::streamsize size,char delim='\n')
{
	std::streambuf::int_type int_delim = std::char_traits<char>::to_int_type(delim);
	std::streambuf::int_type in;
	std::streamsize s=0;
	std::streambuf* sb = is.rdbuf();

	in = sb->sgetc();
	if(std::char_traits<char>::not_eof(in))
	{
		while((!std::char_traits<char>::eq_int_type(in,int_delim )) && std::char_traits<char>::not_eof(in)&& s<size)
		{
			in = sb->sbumpc();
			buf[s] = std::char_traits<char>::to_char_type(in);
			++s;
		}
	}
	buf[s]='\0'; 

	return s;
}

    Und die neue TestIostream3:

    size_t TestIostream3()
{
    std::ifstream in(gc_inputFileName);
    std::ofstream out(gc_outputFileName);

    char buffer[1024];
    size_t outLines = 0;
	std::streamsize ss=0;

    while(1)
    {
        if(!(ss = my_getline(in,buffer, sizeof(buffer))))
            break;
        if(!(ss = my_getline(in,buffer, sizeof(buffer))))
            break;

        out.rdbuf()->sputn(buffer,ss);
        ++outLines;
    }
    return outLines;
}

    Mit VS8 im "Standard" Releasemode:

    TestStdio: Lines: 80000, time: 140 msec
    TestStdio: Lines: 80000, time: 120 msec
    TestStdio: Lines: 80000, time: 122 msec
    TestStdio: Lines: 80000, time: 121 msec
    TestStdio: Lines: 80000, time: 121 msec
    TestIostream3: Lines: 80000, time: 98 msec
    TestIostream3: Lines: 80000, time: 101 msec
    TestIostream3: Lines: 80000, time: 96 msec
    TestIostream3: Lines: 80000, time: 112 msec
    TestIostream3: Lines: 80000, time: 114 msec

    Sieht schon etwas anders aus,oder?
    Die Frage die bleibt......wer möchte so arbeiten?
    Ist wie bei nem Auto,je mehr Sonderausstattung und Extras du da rein packst desto teurer und langsamer wird es.Und trotzdem ist es irgendwie doch das bessere Auto.

    PS:Was ist eigentlich mit dem Forum los?War ja schon wieder stundenlang nicht erreichbar 😞 .

    Gruß Spacelord

    0
  • ?

    @Spacelord:
    Jo, sieht etwas anders aus 🙂
    Du kommst aber nochmal auf ca. 50% von der Zeit wenn du einfach 2 grosse Buffer nimmst und dann selbst von einem zum anderen Bytes schippst. Ist aber ein Haufen Code wenn man alle Randbedingungen 100% einhalten und das ganze auch halbwegs schnell hinbekommen will... 🙂

    @HumeSikkins:
    Das "threads meeting" Beispiel finde ich unglücklich gewählt. Ich für meinen Teil finde es ziemlich peinlich (und ärgerlich) dass der C++ Standard über Threads bis heute nichts zu sagen hat. Ich meine multi CPU Systeme sind ja nicht gerade was neues, und preemtives Multitasking gibts auch schon seit Jahrzehnten. Weiters ist so ziemlich alles was da diskutiert wurde ein alter Hut. Gut dass mal konkret drüber gesprochen wird das in C++ zu standardisieren, aber guck dir mal das Proposal von Kevlin Henney (der ja auch zitiert wurde) und die C extension "Cilk" an.

    0
Anmelden zum Antworten