C Hassen...



  • .filmor schrieb:

    1310-Logik schrieb:

    Gerade wenn man lange Zeichenketten durchsuchen, bearbeiten, teilen und umkehren will. Da schlägt Python C und C++ auch in Punkto Effizienz.

    Das wage ich zu bezweifeln. Mir ist schon bewusst, dass die Stringangelegenheiten in Python stark optimiert werden, dennoch glaube ich nicht, dass Python schneller ist. Mit sowas wie Psyco oder IronPython kann es ja von mir aus auf Augenhöhe sein, aber effizienter kann ich mir nicht vorstellen.
    Vielleicht meintest du ja etwas anderes, dann führe doch bitte "Effizienz" näher aus.

    Muss ja nicht gleich "Laufzeiteffizienz" (1310-Logik hat ja nicht von "Schnelligkeit" geredet) sein. Es ist einfach ein Unterschied ob ich einfach so Regex, Unicode, umfangreiche String-Bibliothek (mit Slicing etc.) direkt bei der Sprache dabei hab, oder ob ich dazu erstmal 2-3 verschiedene Bibliotheken suchen muss, die evtl. auch noch andere Code-Styles verwenden und vielleicht nicht mal auf allen Plattformen zur Verfuegung stehen 😉



  • Naja, ich denke das Thema, dass du Standardbibliothek da zu schmal ist haben wir bereits durch ...
    Python verfolgt dahingehend auch eine andere Philosophie.



  • Doch Laufzeiteffizienz --> weniger CPU time meinte ich
    aber auch Entwicklungszeit --> weniger Code Zeilen
    Regex-DNA Benchmark

    diff program output for this 100KB input file (generated with the fasta program N = 10000) with this output file to check your program is correct before contributing.

    We use FASTA files generated by the fasta benchmark as input for this benchmark. Note: the file may include both lowercase and uppercase codes.

    Each program should

    * read all of a redirected FASTA format file from stdin, and record the sequence length
    * use the same simple regex pattern match-replace to remove FASTA sequence descriptions and all linefeed characters, and record the sequence length
    * use the same simple regex patterns, representing DNA 8-mers and their reverse complement (with a wildcard in one position), and (one pattern at a time) count matches in the redirected file
    * write the regex pattern and count
    * use the same simple regex patterns to make IUB code alternatives explicit, and (one pattern at a time) match-replace the pattern in the redirect file, and record the sequence length
    * write the 3 recorded sequence lengths

    Revised BSD license

    C++ mag mithalten, C auf gcc hat ein Timeout bekommen, tja..

    edit: ja es ist ein gesuchtes Beispiel, da das einzige. Aber ist nunmal mein Hauptanwendungsbereich gewesen, mit den BLAST FASTA etc. rumzuwerkeln



  • Stringmanipulationen sind im ISO-C++ 2003 dürftig, stimmt. Aber bzgl. Regex hat ISO-C++ seit April 2006 kein Defizit mehr, siehe TR1.

    Wer noch mehr Stringmanipultionen benötigt, muß vorerst auf Boost zurück greifen. Halte das aber nicht für schlimm, da Boost einfach auf jede Festplatte eines C++-Entwicklers gehört.
    http://www.boost.org/libs/libraries.htm#String



  • #include <string> 
    #include <iostream> 
    
    class ganz_unsicher { 
    
        public: 
    
            ganz_unsicher( ) : passwort( "geheim" ) { } 
    
        private: 
            int dummy;
            std::string passwort; 
    }; 
    
    int main() 
    { 
        ganz_unsicher gleich_passierts; 
        std::string *boesewicht = reinterpret_cast< std::string* >( &gleich_passierts ); 
        std::cout << boesewicht->c_str( ) << std::endl; 
    }
    

    Schon gehts nicht mehr bzw. seh ich nur noch quatsch zur Laufzeit!

    Also, wenn ich will, kann ich in C++ sowieso vieles machen. Aber wenn das Passwort sooo geheim wäre, würde ich es auch nur verschlüsselt ablegen. 😉 Was sollen diese Beispiele? Wir wissen hier doch alle, das man mit böswilliger Absicht schlimme Dinge erreichen kann. Ich denke nicht, das wir hier jetzt ein "Oh oh!" Erlebnis hatten, oder?



  • 1310-Logik schrieb:

    C++ mag mithalten, C auf gcc hat ein Timeout bekommen, tja..

    und der gewinner ist eine skriptsprache. aber wir wussten's ja schon immer: compilersprachen taugen einfach nix 😃



  • Artchi schrieb:

    Schon gehts nicht mehr bzw. seh ich nur noch quatsch zur Laufzeit!

    #include <string> 
    #include <iostream> 
    
    class ganz_unsicher { 
        public:
            ganz_unsicher() : dummy(2006), passwort("geheim") {}
        private: 
            int dummy; 
            std::string passwort; 
    }; 
    
    int main() {
    	ganz_unsicher gleich_passierts; 
    	int *boesewicht1 = (int*)&gleich_passierts;
    	std::string *boesewicht2 = reinterpret_cast<std::string*>(&gleich_passierts) + 1;
    	std::cout << *boesewicht1 << " und " << *boesewicht2 << std::endl; 
    }
    

    So viel dazu. Diesmal auch ohne hässlichem c_str() 😉



  • Und was machst du, wenn dir noch jemand eine vtable davor pflanzt?

    #include <string> 
    #include <iostream> 
    
    class ganz_unsicher { 
        public:
            ganz_unsicher() : dummy(2006), passwort("geheim") {}
            virtual ganz_unsicher () {}
        private: 
            int dummy; 
            std::string passwort; 
    };
    

    Übrigens klappt deine Methode nur, falls sizeof (int) == sizeof (std::string) ist!

    int main ()
    {
        ganz_unsicher gleich_passierts;
        int* boesewicht1 = reinterpret_cast<int*> (&gleich_passierts);
        std::string* boesewicht2 = reinterpret_cast<std::string*> (boesewicht1 + 1);
        std::cout << *boesewicht1 << " und " << *boesewicht2 << std::endl;
    }
    

    So ists portabler 😉



  • .filmor schrieb:

    Übrigens klappt deine Methode nur, falls sizeof (int) == sizeof (std::string) ist!

    Nein, leider falsch geraten. 😉
    Versuch es mal bei einem 64-Bit-System. Da siehst du sehr schnell, dass (zumindest beim GCC) int nach wie vor 32 Bit hat, während Zeiger 64 Bit haben. Damit ist sizeof(std::string) 8, während sizeof(int) 4 bleibt.
    Die Methode funktioniert dennoch (ich hab hier schließlich ein 64-Bit-System). Und sie klappt, weil Zeiger immer die selbe Größe haben. Und das ist hier, worauf es ankommt!
    Deswegen ist dein "Verbesserungsversuch" auch kein deut portabler. boesewicht1 ist schließlich ein Zeiger und kein int. Und wie gesagt, sizeof(int*) == sizeof(std::string) == sizeof(std::string*) == (bei dir) 4 == (bei mir) 8.
    Deine Variante ist also im Grunde die selbe wie meine - nur dass boesewicht2 bei mir auch direkt abgefragt werden kann, während du es von boesewicht1 abhängig machst.



  • 1310-Logik schrieb:

    C++ mag mithalten, C auf gcc hat ein Timeout bekommen, tja..

    edit: ja es ist ein gesuchtes Beispiel, da das einzige. Aber ist nunmal mein Hauptanwendungsbereich gewesen, mit den BLAST FASTA etc. rumzuwerkeln

    Also das Python für textmanipulationen sehr beliebt ist, ist mir bekannt. Hört und liest man ja immer wieder.

    Die Frage ist nur: welcher Compiler wurde eingesetzt? Steht nur gcc, aber nicht welche Version. Dann noch: hat jemand schon mal einen Versuch mit dem Intel C++ Compiler für Linux ausprobiert? Würde mich interessieren.



  • Nein, für Intel C++ ists fehlerhaft. Aber du kannst ja einen schreiben, die Bedingungen sind ja gegeben 😉
    http://shootout.alioth.debian.org/debian/benchmark.php?test=regexdna&lang=icpp

    btw: g++ (GCC) 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)



  • Hem, fragt sich jetzt nur, wer schuld ist? Der Intel Compiler oder der Implementierer des Tests?

    Würde gerne einen Test mit Boost Regex und Intel C++ Compiler sehen. Naja... falls jemand sowas hat, einfach melden. 😉



  • Dürfte es nicht schwierig sein Intel C++ auf ner AMD CPU zu testen?
    Hier die Fehlermeldung, entscheide selbst, wer schuld hat:

    /opt/intel/cc/9.0/bin/icpc -c -O3 -ip -static -unroll regexdna.c++ -o regexdna.c++.o && \
    /opt/intel/cc/9.0/bin/icpc regexdna.c++.o -o regexdna.icpp_run -O3 -ip -static -unroll
    Command-line error: invalid GNU version number: 412

    compilation aborted for regexdna.c++ (code 4)
    make[3]: [regexdna.icpp_run] Error 4 (ignored)
    rm: cannot remove regexdna.c++.o': No such file or directory rm: cannot removeregexdna.o': No such file or directory
    make[3]: [regexdna.icpp_run] Error 1 (ignored)



  • Nein, warum sollte es ein Prob sein? Der AMD ist ja kompatibel zum Intel-Prozessor, oder nicht? Wäre ja witzlos, wenn Intel Compiler nur für Intel CPU funktionierenden Code erzeugen würden, weil dann müssten viele Spielefirmen zwei Versionen ihrer Spiele ausliefern. Außerdem geht das offiziell auch für AMD CPUs. Egal... zur Fehlermeldung:

    Command-line error: invalid GNU version number: 412

    Soll heißen er stört sich daran, das es kein GNU Compiler ist?

    Hab erst gedacht es wäre ein Laufzeitfehler. Wenn natürlich nicht mal das Kompilieren klappt...



  • Keine Ahnung, versteh nicht soviel von Linux-Compilern.
    Das ganze lief unter Debian. Aber bei keinem der Benchmarks funktionierte der Intel C++.
    Weis jetzt auch ned, ob der dann wirklich schneller wär, is ja der selbe Code, und ob der so viel besser optimieren kann?



  • Der Intel kann auf jeden Fall mit am besten optimieren, das zeigen viele Vergleichstests in entsprechenden Magazinen. Der VC++ ist schon sehr gut (hat damals immer den GCC 3.x ausgestochen), aber Intel legt ne Schippe nach. Also denke ich mal, macht er das auch mit einem GCC 4.x, sonst kann Intel seinen Compiler streichen.

    Es gibt ja noch schnellere, wie Pathscale, kosten aber viel mehr Geld.

    Gut, also es besteht noch die Möglichkeit das C++ mit einem anderen (besseren) Compiler den Python-Benchmark überholt. Nichts gegen GCC, weiß auch nicht wie gut der aktuelle ist, weiß nur das der GCC 3.x gegen VC++6 immer verloren hat. Und VC++ gegen den Intel.


Anmelden zum Antworten