panthema (page 6 of 1 2 3 4 5 6 7 8 9)
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 34 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.


Cry of Dolour by Stanislav Ossovsky

Cry of Dolour by Stanislav Ossovsky - Free Fantastic Classic-Metal Music

Posted on 2007-10-14 21:25 by Timo Bingmann at Permlink with 0 Comments. Tags: music

While stumbling around the web, today I found some fantastic instrumental classic-metal music. Listening into some random web music streams, I heard a piece that immediately matched my music taste. That taste is maybe best described as symphonic epic metal, though I'm generally against over-detailed (music) categorization.

Consequently I entered the song's name into Amazon's search, but nothing was found. Some googling revealed that the song is downloadable for free: http://www.cryofdolour.ru - (download page)

It is part of a complete album of similar pieces composed by this Russian musician who signed the page with RAO. The pieces combine classic music motifs with metallic drumming and guitars. Sounds impossible, yet the songs masterfully weaved both styles together creating a bombastic epic expression. Yes, the songs are all instrumental, and yes, you need some patience for the first track. Having heard the pieces over and over again, I soon noticed that while the musical composition is excellent the tracks' sound itself does not reach usual CD production quality. They sound a bit synthetic and miss some bass blast. But hey, it's free.

Original, incredible music by an unknown artist! My three favourite tracks are: "Hymn to Solitude", "Dies Irae", "It is Coming" and "Prelude". Ah, that is now four and I still missed some of the best. Just hear them yourself.

If you also have no clue as to what the Russian text on the main page is about, I suggest reading Google's translation of that page.


Thumbnail of Escher's Relativity in Lego

Really Good Lego Model of Escher's "Relativity"

Posted on 2007-09-07 10:41 by Timo Bingmann at Permlink with 0 Comments. Tags: fun

The idea strikes me as very strange: to take the impossible figures sketched by Escher and build Lego models of them.

Someone actually took up this seemingly "impossible" feat. Yesterday I found their pictures of "Relativity", of which I have a poster on the wall left of my PC. I've had some long looks at the poster. So the minute details of the Lego reconstruction interested me immediately. Due to the studs of (standard) Lego tiles pointing in only one direction they had to leave out a few railings, which help form the twisted triangle's composition lines. Each of the red Lego men are at the correct place and hold the correct action props. Sweetest are the Lego flowers and plants positioned at the picture's upper left, lower right and center. A very good job indeed.


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

Published Flex Bison C++ Example 0.1

Posted on 2007-08-20 11:53 by Timo Bingmann at Permlink with 2 Comments. Tags: flex-bison-cpp-example c++ code-example

Released example source code package 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 example shows how to use both Flex and Bison in C++ mode. This way both lexer and parser code and data is encapsulated into classes. Thus the lexer and parser are fully re-entrant, because all state variables are contained in the class objects. Furthermore multiple different lexer-parser pairs can easily be linked into one binary, because they have different class names and/or are located in a different namespace.

Why Use These Old Tools? Well, they are here to stay and they work well. But most important, the code generated by Flex and Bison requires no compile-time dependencies, because they generate fully autonomous source code. So far I have not found any modern parser generator which outputs independent code. It is even possible to compile the generated source on Windows with Visual C++ 2005.

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


Show Page: 1 2 3 4 5 6 7 8 9 Next >
RSS 2.0 Weblog Feed Atom 1.0 Weblog Feed Valid XHTML 1.1 Valid CSS (2.1)
Copyright 2005-2017 Timo Bingmann - Impressum