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

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!