panthema / 2008
Funny Drawing with 'C++' 'FLEX' and a Bison

Published Flex Bison C++ Example 0.1.3

Posted on 2008-10-23 11:25 by Timo Bingmann at Permlink with 0 Comments. Tags: flex-bison-cpp-example c++ code-example

Released yet another updated source code package for Flex Bison C++ Example. The example source code is released into the public domain or, at your option, under the Do What The Fuck You Want To Public License (WTFPL).

This bugfix release solves a subtle, severe bug, which rendered the template code useless. Even the example exprtext program segfaulted with any expression.

Corrected a very subtle bug with the newly introduced virtual yywrap() function in the FlexLexer class. Depending on how the header was included, the class contained the virtual yywrap() function or not. These differing class declarations lead to very strange NULL pointer exceptions, because the different compiled objects assume different class memory layouts. Ultimately the exprtest program always segfaulted.

For more information and the download package see the Flex Bison C++ Example web page.


Small drawing of a B+ tree

Update Release of STX B+ Tree 0.8.3

Posted on 2008-09-07 18:31 by Timo Bingmann at Permlink with 0 Comments. Tags: c++ stx-btree

Released another updated version 0.8.3 of the STX B+ Tree C++ Template Classes package. The updated release fixes up issues with the root node == NULL when the tree is initially empty.

Fixed crash when running verify() on an empty btree object. Now the root node is freed when the last item is removed. Also fixed crash when attempting to copy an empty btree or when trying to remove a non-existing item from an empty btree.

Also enhancing the speedtest to test the hash table container implementation from __gnu_cxx. Extending tests by another set of runs measuring only the find/lookup functions. See the speed results web page for more information.

The updated source code package is available for download from this webpage.

Some compiled binaries of wxBTreeDemo for Win32 and Linux are available on the demo download page.

As before, the updated main B+ tree implementation can be found in doxygen stx/btree.h or with plain text comments stx/btree.h.


Instacode coloring of stacktrace

C++ Code Snippet - Print Stack Backtrace Programmatically with Demangled Function Names

Posted on 2008-09-01 22:30 by Timo Bingmann at Permlink with 15 Comments. Tags: c++ code-snippet coding tricks frontpage

Yesterday I was tasked to analyzed an inner function of a reasonably complex software package. The inner function was called thousands of times from many different parts of the program, a simple counter print-out showed that. However I was interested in which execution paths reach this inner function and how often the different parts access the function.

My straight-forward idea was to dump a stack backtrace each time the inner function is called, similar to the one printed by a debugger. However I needed some code snippet to dump the stack backtrace programmatically, without using gdb to halt the program each time.

Stack backtraces can be saved with backtrace(3), resolved into symbolic names using backtrace_symbols(3) and printed using backtrace_symbols_fd(3). These functions are well documented and fairly easy to use.

However I was debugging a C++ program, which made heavy use of templates and classes. C++ symbols names (including namespace, class and parameters) are mangled by the compiler into plain text symbols: e.g. the function N::A<int>::B::func(int) becomes the symbol _ZN1N1AIiE1B4funcEi. This makes the standard backtrace output very unreadable for C++ programs.

To demangle these strings the GNU libstdc++ library (integrated into the GNU Compiler Collection) provides a function called __cxa_demangle(). Combined with backtrace(3) a pretty stack backtrace can be outputted. The demangling function only works for programs compiled with g++.

The following header file contains a function print_stacktrace(), which uses backtrace(3), backtrace_symbols(3) and __cxa_demangle() to print a readable C++ stack backtrace.

This blog entry continues on the next page ...

Small drawing of a B+ tree

Update Release of STX B+ Tree 0.8.2

Posted on 2008-08-13 16:48 by Timo Bingmann at Permlink with 0 Comments. Tags: c++ stx-btree

Released an updated version 0.8.2 of the STX B+ Tree C++ Template Classes package. The updated release fixes up all issues with iterators and one harmless bad-memory access.

The reverse_iterator classes of the B+ tree were completely reworked. Now they are real implementations and do not use STL magic. Both reverse_iterator and const_reverse_iterator should work as expected now. Added two large test cases for iterators. Enabled public default-constructors on iterators.

Also fixed a memory access bug which happens in erase_one_descend(): leaf->slotkey[leaf->slotuse - 1] if leaf-slotuse == 0. This doesn't have any other bad effect, because the case only occurs when leaf == root and then the resulting btree_update_lastkey message is never really processed. However it still is a bad-memory access.

The updated source code package including the wxBTreeDemo source is available for download from this webpage.

Some compiled binaries of wxBTreeDemo for Win32 and Linux are available on the demo download page.

As before, the updated main B+ tree implementation can be found in doxygen stx/btree.h or with plain text comments stx/btree.h.


Funny Drawing with 'C++' 'FLEX' and a Bison

Published Flex Bison C++ Example 0.1.2

Posted on 2008-08-03 14:26 by Timo Bingmann at Permlink with 0 Comments. Tags: flex-bison-cpp-example c++ code-example

Released an updated source code package for Flex Bison C++ Example. The example source code is released into the public domain or, at your option, under the Do What The Fuck You Want To Public License (WTFPL).

This bugfix release solves two problems there were reported to me via e-mail:

The first problem were compilation errors that occured when no %union directive is used in the grammar: in this case the include headers order is changed around by bison and thereby breaks compilation. This was fixed by never including parser.h directly, but always using scanner.h.

And the second issue was raised because new versions of flex were released after years of stagnation. The new flex version 2.5.35 adds a virtual function yywrap() to the yyFlexLexer class. This function is automatically defined in any lexer source file generated by flex. However because I copied FlexLexer.h from an older flex distribution, the function definition throughs a "no yywrap() member function" compiler error. Updating the FlexLexer.h with a conditional declaration of yywrap() hopefully did the trick and now works on all versions. Usually this file should be taken from /usr/include and not from the package. However that will break compilation if flex is not installed, and a self-sufficient compilation package was a primary goal of the example.

For more information and the download package see the Flex Bison C++ Example web page.


Cryptograph Speedtest - All Tests: Speed by Data Length on p4-3200-gentoo

Speedtest and Comparsion of Open-Source Cryptography Libraries and Compiler Flags

Posted on 2008-07-14 14:53 by Timo Bingmann at Permlink with 12 Comments. Tags: cryptography crypto-speedtest

Abstract

There are many well-known open-source cryptography libraries available, which implement many different ciphers. So which library and which cipher(s) should one use for a new program? This comparison presents a wealth of experimentally determined speed test results to allow an educated answer to this question.

The speed tests encompass eight open-source cryptography libraries of which 15 different ciphers are examined. The performance experiments were run on five different computers which had up to six different Linux distributions installed, leading to ten CPU / distribution combinations tests. Ultimately the cipher code was also compiled using four different C++ compilers with 35 different optimization flag combinations.

Two different test programs were written: the first to verify cipher implementations against each other, the second to perform timed speed tests on the ciphers exported by the different libraries. A cipher speed test run is composed of both encryption and decryption of a buffer. The buffer length is varied from 16 bytes to 1 MB in size.

Many of the observed results are unexpected. Blowfish turned out to be the fastest cipher. But cipher selection cannot be solely based on speed, other parameters like (perceived) strength and age are more important. However raw speed data is important for further discussion.

When regarding the eight selected cryptography libraries, one would expect all libraries to contain approximately the same core cipher implementation, as all calculation results have to be equal. However the libraries' performances varies greatly. OpenSSL and Beecrypt contain implementations with highest optimization levels, but the libraries only implement few ciphers. Tomcrypt, Botan and Crypto++ implement many different ciphers with consistently good performance on all of them. The smaller Nettle library trails somewhat behind, probably due to it's age.

The first real surprise of the speed comparison is the extremely slow test results measured on all ciphers implemented in libmcrypt and libgcrypt. libmcrypt's ciphers show an extremely long start-up overhead, but once it is amortized the cipher's throughput is equal to faster libraries. libgcrypt's results on the other hand are really abysmal and trail far behind all the other libraries. This does not bode well for GnuTLS's SSL performance. And libmcrypt's slow start promises bad performance for thousands of PHP applications encrypting small chunks of user data.

Most of the speed test experiments were run on Gentoo Linux, which compiles all programs from source with user-defined compiler flags. This contrasts to most other Linux distributions which ship pre-compiled binary packages. To verify that previous results stay valid on other distributions the experiments were rerun in chroot-jailed installations. As expected Gentoo Linux showed the highest performance, closely followed by the newer versions of Ubuntu (hardy) and Debian (lenny). The oldest distribution in the test, Debian etch, showed nearly 15% slower speed results than Gentoo.

To make the results transferable onto other computers and CPUs the speed test experiments were run on five different computers, which all had Debian etch installed. No unexpected results were observable: all results show the expected scaling with CPU speed. Most importantly no cache effects or special speed-ups were detectable. Most robust cipher was CAST5 and the one most fragile to CPU architecture was Serpent.

Most interesting for applications outside the scope of cipher algorithms was the compiler and optimization flags comparison. The speed test code and cipher library Crypto++ was compiled with many different compiler / flags combinations. It was even compiled and speed measured on Windows to compare Microsoft's compiler with those available on Linux.

The experimental results showed that Intel's C++ compiler produces by far the most optimized code for all ciphers tested. Second and third place goes to Microsoft Visual C++ 8.0 and gcc 4.1.2, which generate code which is roughly 16.5% and 17.5% slower than that generated by Intel's compiler. gcc's performance is highly dependent on the amount to optimization flags enabled: a simple -O3 is not sufficient to produce well optimized binary code. Relative to gcc 4.1.2 the older compiler version 3.4.6 is about 10% slower on most tests.

All in all the experimental results provide some hard numbers on which to base further discussion. Hopefully some of the libraries' spotlighted deficits can be corrected or at least explained. Lastly the most concrete result: the cipher and library I will use for my planned application is Serpent from the Botan library.

This blog entry continues on the next page ...

Kooperative LaTeX-Mitschrift zu Algebra 2 bei Prof. Herrlich

Posted on 2008-05-10 15:59 by Timo Bingmann at Permlink with 2 Comments. Tags: algebra latex

Nachdem ich in der letzten Woche die Prüfung zu Algebra 2 abgelegt habe, betrachte ich nun das dazugehörige Skript auch als abgeschlossen.

Zu der Vorlesung im Sommersemester 2006 entstand kooperativ per Internet eine LaTeX-Mitschrift. Das gemeinsame Mitschreiben/Nach-TeXen wurde möglich durch das LaTeX-Wikisystem latexki von Joachim Breitner. Auf dem Mitschrieb-Wiki haben damals verschiedene Leute zusammen das LaTeX kapitelweise zusammengestellt. Ich habe ungefähr sechs Vorlesungen dazu beigetragen.

Irgendwann hatte ich damals einen lokalen Branch der LaTeX Dateien mittels SVK angefangen. Dafür gab es verschiedene Gründe. Insbesondere war lokales Editieren der LaTeX-Dateien mit XEmacs sehr viel bequemer als online im Browser-Formularfeld. Außerdem war das Einbinden von externen EPS/PDF Graphiken auf dem Wiki-System leider nicht möglich. Ich hatte auch andere Vorstellungen vom optischen Seitenlayout und Schriften, welche das LaTeX-Wiki nicht akzeptierte.

Der Branch ist dann permanent geworden und ich habe beim Lernen sehr, sehr viele kleine Fehler im Skript gefunden und einige kurz gefasste Stellen ergänzt. Leider ist es nicht mehr möglich die Änderungen auf das Wiki hochzuladen, da einige Neuerungen insbesondere die Graphiken nicht unterstützt werden und die ganzen anderen kleinen Änderungen nur noch schwer nachvollziehbar sind.

Darum gibt es hier meine (private) Version des Mitschrieb-PDFs und des LaTeX-Quellcodes.

Das fertig kompilierte Skript Algebra2.pdf ist 611 kB groß.

Der LaTeX-Code zum Skript ist in eine Hauptdatei und kleine Kapitel-Dateien aufgeteilt. Die folgenden Links führen zum Quellcode mit Syntaxhighlighting.

Hauptdatei:
Algebra2.tex
Teil 1:
Algebra2Par11.part.tex
Algebra2Par12.part.tex
Algebra2Par13.part.tex
Algebra2Par14.part.tex
Algebra2Par15.part.tex
Algebra2Par16.part.tex
Algebra2Par17.part.tex
Teil 2:
Algebra2Par21.part.tex
Algebra2Par22.part.tex
Algebra2Par23.part.tex
Algebra2Par24.part.tex
Algebra2Par25.part.tex
Algebra2Par26.part.tex
Algebra2Par27.part.tex
Algebra2Par28.part.tex
Algebra2Par29.part.tex
Algebra2Par2A.part.tex
Algebra2Par2B.part.tex
Extras:
Algebra2Par28.pic1.fig
Algebra2Par29.pic1.fig
Algebra2Par29.pic1.pictex
Algebra2Par29.pic2.gnuplot
Algebra2Par29-pic2.pdf

Cover-Algebra12.tex
Komplett:
Algebra2.zip

Da ich mein altes Algebra 1 Skript zusammen mit dem neuen Algebra 2 Skript zu einem kleinen Buch binden wollte, habe ich noch ein Deckblatt-PDF (Cover-Algebra12.pdf) für die beiden Teile angefertigt.


Small drawing of a B+ tree

Bugfix Release of STX B+ Tree 0.8.1

Posted on 2008-01-25 15:48 by Timo Bingmann at Permlink with 1 Comments. Tags: c++ stx-btree

Released a bugfix version 0.8.1 of the STX B+ Tree C++ Template Classes package. The bug fixed is a possibly illegal memory access during find() function.

I received a new test case via email in which valgrind detected an uninitialized memory access. By tracing it, I soon found that it happens during any find(key) call with a key that is larger than any item contained in the tree. During the find() function find_lower() is called on a leaf node and returns the slot number with the smallest or equal key. However if the queried key is larger than all keys in a leaf node or in the whole tree, find_lower() returns a slot number past the last valid key slot. Comparison of this invalid slot with the queried key then yields an uninitialized memory error in valgrind.

The updated source code package including the wxBTreeDemo source is available for download from this webpage.

Some compiled binaries of wxBTreeDemo for Win32 and Linux are available on the demo download page.

As before, the updated main B+ tree implementation can be found in doxygen stx/btree.h or with plain text comments stx/btree.h.


RSS 2.0 Weblog Feed Atom 1.0 Weblog Feed Valid XHTML 1.1 Valid CSS (2.1)
Copyright 2005-2014 Timo Bingmann - Impressum