Performancevergleich von C, C++, MS VC++, VB6 und noch einige Fragen!

Possessed

Tellerrand schrieb:

Ja du arbeitest halt mit Funktionen, ich habe da eher Streamklassen im Auge

Ich glaube wird reden aneinander vorbei. Konkret weiß ich jetzt nicht was du mit dem Verwenden von Streamklassen anstelle von Funktionen meinst.

Tellerrand schrieb:

Also bei den ersten 4 Punkten frag ich mich schon warum man KB einlesen muss und nciht byteweise einlesen kann.
Z.B. Nr.4 läuft ja darauf hinaus, dass du derzeit pro Codewort den ganzen String durchläufst und jedes Vorkommen ersetzt. Wenn man byteweise einfach immer das erste Zeichen umwandelt und direkt rausschreibt läuft das auf ähnlich viele Vergleiche hinaus, aber man verzichtet auf komplexeres entfernen von Elementen.

VB behandelt Strings afaik auch als Array (kurz gegoogelt).
Und da ist Einfügen/Entfernen besonderst teuer.

Falls VB die intern doch nicht als Arrays behandelt würde ich einen Wechsel auf Arrays nicht vornehmen, dann doch lieber etwas schönes mit Pointern, oder ähnlichem basteln

Prinzipiell ist das richtig. Bei Punkt 1 bis 4 könnte ich genausogut byteweise arbeiten, erst bei Schritt 5 brauche ich den ganzen String. Der Nachteil an deinem Vorschlag ist, dass ich dann jedes Byte einzeln an die Funktion übergeben müsste, die Funktion sich jedoch vereinfachen würde, da ich nicht den ganzen String durchgehen müsste sonder immer nur ein Zeichen behandel. Vorteil an meiner Herangehensweise ist, dass ich die Funktion nur einmal aufrufen muss, jedoch in der Funktion dann den gesamte String durchgehen muss. Müsste man probieren was schneller ist (ob jetzt bei einem String von z.B. 1000 Zeichen das durchgehen des gesamten Strings länger dauert oder ob das 1000 mal aufrufen der Funktion mehr Zeit frisst. Ist prinzipiell aber eine gute Vorschlag den ich noch testen werde.

Wow, sind sie echt Arrays??? Jetzt bin ich schwer beeindruckt. War mir eigentlich sicher das die in irgendeiner Form Listen sind.

Pointer! Ich hasse die Dinger. (Ist noch eine kleine Altlast von mir. Als in der 2. Klasse meiner schulischen Laufbahn der Umstieg vom einsteigerfreundlichen, einfachen VB auf C mit seinen Pointer, Pointern auf Pointern, Adressoperatoren, und, und, und kam, da war ich erstmal a bissl geschockt. Mittlerweile habe ich zwar kein Problem mehr damit, aber jedesmal bei dem Wort muss ich mich daran erinnern.)

Außerdem weis ich noch immer nicht was du damit meinst einen Teil des Strings während der Funktion "raus zu schreiben". Wenn ich den während der Funktion den String / das Byte in eine Datei schreibe, um ihn gleich danach wieder einzulesen und der nächsten Funktion zu übergeben, würde das 1000 mal länger dauern, als wenn ich den String gleich im Speicher behalte. Aber wie ich oben bereits gesagt habe glaube ich, dass wir da aneinander vorbei reden. Könntest du das vielleicht nocheinmal etwas genauer erklären wie du das meintest?

mfg

Zur Erklärung:

http://www.galileocomputing.de/openbook/visual_basic/Kapitel_12-004.htm

2.Pass-Through-Streams ergänzen einen Base-Stream um spezielle Funktionalitäten. So können manche Streams verschlüsselt oder im Hauptspeicher gepuffert werden. Pass-Through-Streams lassen sich hintereinander in Reihe schalten, um so die Fähigkeiten eines Base-Streams zu erweitern. Auf diese Weise lassen sich sogar individuelle Streams konstruieren.

Das ist halt sowas womit ich basteln würde.
Dort existiert sogar ein GZipStream.
Fehlen noch deine Klassen wie WhitespaceEliminatorStream

Aber das nun komplett neu zu schreiben wäre viel Arbeit und ich glaube, es liegt wirklich nur an den String Funktionen die du nutzt.
Wenn es nämlich Arrays sind kann die Rechenleistung duch Einfügen/Entfernen da schnell verloren gehen.

Mein Vorschlag ist also einfach mal Funktion Nr.4 zu ersetzen.
In einer Schleife Zeichen für Zeichen analysieren und in einen neuen String die komprimierten Werte reinschreiben. Den neuen String dann weiterreichen. Ist halt die Frage wie man vorher die Größe des neuen Strings abschätzen kann, bzw. was das vergrößern des Strings an Performance kostet.

hustbaer

VB ist auch so langsam, ob man nun String Funktionen nutzt oder nicht.
Wer's ausprobieren will soll einfach mal nen einfachens Apfelmännchen oder sowas in VB und dann in C bzw. C++ programmieren, und dann gucken was schneller ist, und vor allem wieviel.

Bei VB .NET sieht die Sache wieder etwas besser aus, trotzdem würde ich für sowas (komprimieren) immer C bzw. C++ nehmen und nicht VB - mit oder ohne .NET.

kenne mich mit vb nicht aus, kann deshalb nix zur geschwindigkeitsverbesserung sagen. aber der kompressionsgrad könnte vermutlich noch gesteigert werden, wenn vor der rle (schritt 3) noch eine burrows-wheeler-transformation durchgeführt würde.
zlib sollte außerdem doch auch für vb verfügbar sein und bietet bessere komprimierung als lzw.

Blue-Tiger

Possessed schrieb:

Kleiner Ausblick auf die Zukunft:
Prinzipiell habe ich vor noch die Huffman-Kodierung einzusetzen, jedoch habe ich bis jetzt im Internet noch nichts Brauchbares gefunden (Naja, ich habe auch noch nicht wirklich intensiv gesucht). Falls ihr eine Bibliothek oder ähnliches kennt in der dieses Verfahren implementiert ist, schreibt mir bitte.

Wenn du bereits ZIP-Komprimierst, wird dir Huffman nichts mehr bringen: die Bytes, die ZIP ausgibt, sind voellig zufaellig (und in etwa gleichverteilt), aber die Huffman-Kodierung ist nur dann sinnvoll, wenn gewisse Zeichen oefter vorkommen als andere.

Possessed

Blue-Tiger schrieb:

Possessed schrieb:

Kleiner Ausblick auf die Zukunft:
Prinzipiell habe ich vor noch die Huffman-Kodierung einzusetzen, jedoch habe ich bis jetzt im Internet noch nichts Brauchbares gefunden (Naja, ich habe auch noch nicht wirklich intensiv gesucht). Falls ihr eine Bibliothek oder ähnliches kennt in der dieses Verfahren implementiert ist, schreibt mir bitte.

Wenn du bereits ZIP-Komprimierst, wird dir Huffman nichts mehr bringen: die Bytes, die ZIP ausgibt, sind voellig zufaellig (und in etwa gleichverteilt), aber die Huffman-Kodierung ist nur dann sinnvoll, wenn gewisse Zeichen oefter vorkommen als andere.

Mir ist schon klar, dass eine LZW-Komprimierung und eine darauffolgende Huffman-Codierung (fast) nichts bringen wirde, da nach dem LZW (wahrscheinlich) nur mehr wenige Häufigkeiten vorhanden sind. Ich habe mich da wohl ein bißchen blöd ausgedrückt. Gemeint habe ich, dass ich prinzipiell beide implementieren möchte um zu prüfen welche der Beiden für meine Zwecke besser geeignet ist.

@Tellerrand: Danke für deinen Link, war sehr interessant. Bisher habe ich von Streams immer nur im Zusammenhang mit Datein auf der Platte bzw. mit Netzwerk gehört. Das man Streams auch direkt in Hauptspeicher schreiben kann habe ich nicht gewusst.

@squeeze it!: Ich danke auch dir für deinen Tip! Allerdings, wegen deiner Aussage das es die zlib auch für vb gibt. Ich brauch sie nicht für VB, da es heute jetzt endgültig beschlossen wurde, dass mit einer DLL in C++ zu machen.

Aber das führt mich gleich zu meiner nächsten Frage:
Gibt es für die zlib auch irgendwo eine Doku? Der Ersteller schreibt zwar, dass er kein geschrieben hat und empfiehlt den Blick in die Header-Datein, aber ich wollte trotzdem fragen ob vielleicht irgendjemand ein paar Tutorials dazu kennt oder ob jemand anderer vielleicht da einige Sacher überblicksmäßig zusammen geschrieben hat.

Außerdem hat sich heute wieder ein kleine Änderung ergeben:
Und zwar wird jetzt die Kompressionsfunktion, die in der DLL ist, immer mit einer Datensatzreihe (d.h. maximal 32.000 Zeichen) aufgerufen. Allerdings, da diese Funktion damit auch ein paar 100.000 Mal aufgerufen wird, wollte ich nocheinmal fragen ob das ein drastischer Performance-Verlust ist, wenn eine Funktion in einer sooft aufgerufen wird?

Meine letzte Frage:
Gibt es beim Compiler / Optimieren unterschiede zwischen der Standard und der Express Edition. Besitzte zwar keine Express, würde mich aber trotzdem interessieren. (Ich weiß, dass diese Frage nicht unbedingt hier her gehört, aber ich will nur desswegen keinen eigenen Thread aufmachen!)

mfg

hustbaer

Ich kann dir nur sagen dass die Crypto++ einen fertigen ZLIB und Huffman Encoder/Decoder hat.
GZIP Encoder/Decoder is auch mit dabei.

Die Crypto++ ist zwar nicht wahnsinnig gut dokumentiert, dafür baut fast alles auf deren BufferedTransformation Klasse auf. Wenn man das System mal verstanden hat kann man diverse Encoder/Decoder sehr schnell verwenden und auch gegeneinander austauschen.

Hm will jetzt nicht deinen ganzen algo über den haufen schmeissen, aber wäre es nicht geschickter (falls die änderungen zwischen den werten in einem gewissen rahmen bleiben) diese direkt als binärzahlen (festkomma) zu kodieren. Wenn du dir am anfang den maximalen größenunterschied anschaust weisst du auch sofort wieviel bytes du maximal für das abspeichern differenzen brauchst und sparst dir so die trennzeichen.
Danach das ganze (jetzt als string interpretiert) nochmal lzw (evtl burrows wheeler vorher) bzw huffman kodieren.
Damit sollten einige prozent mehr drin sein.

bsp 307.22; 309.33 -> 307.22 2.11 -> 01111000 00000010 00000000 11010011 ...

jeweils 8 Bit bei ASCII oder auch 16 bit bei anderer zeichenkodierung als ein zeichen auffassen. Ergo ohne nachfolgende textkompression hast du aus 14 zeichen 4 gemacht.

gruss InfoStudKa

btw was meinst du mit einer kompressionsrate von 90%?

Possessed

Ja, sowas in der Richtung hab ich mir auch schon gedacht. Allerdings müsste ich in den meisten Fällen 2 oder 3 Vorkommazahlen und sicher 2 Nachkommazahlen nehmen, da aber oft Folgen wie 0;0;0;0;0; vorkommen müsste ich das dann in der Festkommadarstellung 00.00 00.00 00.00 00.00 00.00 so speichern (außer den Punkten (Komma), die habe ich nur der Lesbarkeit und dem Verständnis halber gemacht) und dann würde es wieder länger werden.

Kompressionsrate: Das der String nach der Kompression nur mehr 10% der Länge hat die er vor der Kompression hatte.

mfg

[quote="Possessed"]Hallo!

Ich schreibe zurzeit ein Komprimierungstool in VB 6.0. Leider ist die Performance von VB, speziell bei großen Dateien (für die das Programm hauptsächlich eingesetzt wird), relativ schlecht.
Nun habe ich mir gedacht das Tool, zumindest zum Teil, auf C bzw. C++ zu portieren und die Kompressionsfunktion als DLL zu exportieren und in VB zu verwenden, da eine 50MB Datei ca. 20 Tage zum Komprimieren brauchen würde (dafür ist der Kompressionsfaktor hölle ). Nun meine Fragen:

Wie stark unterscheidet sich C bzw. C++ im Vergleich zu VB6 performancemäßig? Ich will nur einen ungefähren Faktor wissen (z.B.: 2x, 5x, 10x, ... 100000x)!
Wie stark unterscheidet sich C von C++ performancemäßig (da ich relativ laufzeiteffizient arbeiten muss)?
Ist Visual C++ langsamer als "normaler" C/C++ Code der von anderen Compilern kompiliert wurde? Da Visual C++ auf die .NET-Architektur aufsetzt und die meiner Meinung nach relativ überladen und langsam ist?
Wie groß ist der Performanceverlust beim Aufruf einer Funktion in einer DLL? Ich will nämlich (wie oben beschrieben) die Kompressionsalgorithmen in C/C++ schreiben und diese als DLL exportieren und sie dann in VB aufrufen? Das Problem ist, dass ich immer nur 8KB komprimieren kann (d.h. Bei einer 50MB Datei müsste ich die Komprimierungsfunktion (aus der DLL) tausendemale aufrufen. Würde das meinen Geschwindigkeitsvorteil wieder zunichte machen oder ist der Aufruf einer Funktion die in einer DLL ist (laufzeitmäßig) eher unproblematisch?
test

Wutz

Possessed schrieb:

Gibt es beim Compiler / Optimieren unterschiede zwischen der Standard und der Express Edition.

Meines Wissens nicht. VCExpress besitzt die gleiche Compilerversion (cl.exe) wie die reguläre, die Expressversion ist anderweitig eingeschränkt (keine MFC, eine IDE Funktionen fehlen).
Hier mal Beispiele zum Vergleich:
VC6SP6

Optimierender Microsoft (R) 32-Bit C/C++-Compiler, Version 12.00.8804, fuer x86
Copyright (C) Microsoft Corp 1984-1998. Alle Rechte vorbehalten.

VCEE2008

Microsoft (R) 32-Bit C/C++-Optimierungscompiler Version 15.00.30729.01 für 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

VC2010Prof

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Michael E.

Bitte keine Leichenschändung betreiben.

hustbaer schrieb:

std::string verwendet i.A. dynamische Speicheranforderungen (new), um Speicher für den String zu bekommen. MSVC hat AFAIK einen 16 Byte Puffer in std::string eingebaut, d.h. Strings die kleiner als 16 Byte sind sind "schnell". Für alles grössere wird der Speicher vom Heap geholt.

Finde dazu im Internet nichts, hast du vielleicht eine Quelle?

Danke.

*Q* 1

Hab gerade mal gesucht und in xstring.h (MSVC 2010) das hier gefunden:

enum
		{	// length of internal buffer, [1, 16]
		_BUF_SIZE = 16 / sizeof (_Elem) < 1 ? 1
			: 16 / sizeof (_Elem)};

union _Bxty
		{	// storage for small buffer or pointer to larger one
		_Elem _Buf[_BUF_SIZE];
		_Elem *_Ptr;
		char _Alias[_BUF_SIZE];	// to permit aliasing
		} _Bx;

Das sollte das eigentlich belegen.

Schreiben die den Code eigentlich mit absicht so unverständlich?
Edit: Die Stellen da gehen vll noch, aber wenn man sich mal etwas mehr anguckt - ich finde es absolut scheusslich.
Edit2: Ich hoffe mal, dass ich das überhaupt veröffentlichen darf...

SeppJ

Leute, guckt mal auf den Kalender! Der Thread ist seit 4 Jahren tot und wurde bloß von einem Spammer wieder hoch geholt!