I found the following comparison:

http://www.xaraxtreme.org/about-performance.html

This makes having doubts about the performance of cairo on babelview…

Babelview’s goal is to provide a simple, no-bloat phone framework. Yes, it is 2010, and I think that bloat is not the answer for usability and feature. The principle of babelview is the more you want, the more you have to pay for it in terms of responsiveness, start-up time of applications. The goal is to boot a linux based phone on the reference platform “openmoko freerunner” in less than 10 seconds. I mean “boot”, to have the phone in a state where it is possible to make phone calls, or start applications.

The highlights of the “should be state” of the minimal babelview stack:

• simple widget kit that focuses on full screen applications
• full screen transparent keyboard for simple application manipulation
• simple and consistent gest recognision system
• own rendering engine (draw (line, circle, etc.), draw string
• jpeg viewer with basic transformations
• pdf viewer for document viewing
• ebook reader
• navit navigation, map viewing software
• web browser
• powerful and fast text editor (the new viq) engine

Really amazed about the fast boot speed of the new Ubuntu release, under 10 seconds on older 2.6 Ghz Pentium. I assume that some heavy work was done to start boot scripts in parallel…

Standards in IT are like the promises in the bible, that your next life will be in heaven. Most people believe that they exist, as they do not go beyond some basic system call names like write/open, etc., and they continue to believe in life in heaven. I am already sick with all these preaches about standards that always failed. In case of linux things are even worst. As most of other unices are dying out, linux is practically the main reference point. Linux took it however in an even worst direction. They say they would keep compatibility blah blah. The same time is lot of chaos, but the more the chaos is growing the less chance is given for new ideas.

What is my problem at the moment. Well, I wanted to use already for longer in different situations the power of MMU to do different tricks. Finally I had to draw the conclusion that it is impossible on Linux. It is simply impossible, as Linux obscures part of the pattern. Today I was thinking to write a very little program to test different random memory layouts inside a linux process in different contexts, based on different sequences of mmap and brk calls. The idea was to “scan” the memory by trying to write to it. You set up a signal handler to sigsegv, and then if you try to write to an inexistent page, then the MMU will trigger an interrupt, the kernel will try to recover the page from swap, if it is the case, and then calls a signal handler. What went wrong in my experiment? After the signal handler did it’s job, the kernel is restoring the stack and the state of the registers, and will continue the process where it was stopped before the “bad” instruction was executed. The problem is that the instruction pointer does not advance so again the same sick instruction is called.
So, what is missing? Well, simply a piece of glue that the kernel should call after it has restored the state of the stack and registers, so that the “victim” process can safely jump over the “bad” instruction and handle it in some way.

Well, my little experiment is impossible, unless I will try to unwind the stack, find the position of the wrong instruction, and help it to run, run..

Well, how is this related this to my frustration? Simply, if something like “post signal handler” would would be proposed to the key linux kernel developers it would be rejected as many many (other ) brilliant ideas I saw being lost… As the motto is industry ueber alles! In a better world, system calls would be able to cope with some primitive userspace closures, etc. etc. Well… nonsense to waste time to develop the idea

Would you like have a frenglish lesson? Read the pour lisaac documentation. So briefly, I have two problems with lisaac:

• the language
• the language

It seems that the author and people around would like to initiate a new wave of latinization of English. Documentation is very poor, just hype hype, we are the best, we do what other did not, even more, “we are going to write the French operating system”. There are 2 pdf files as documentation. Obviously the quickstart is in French, so the quick way of doing it was not designed for you this time. Do not know if it has something to do with a french law, that if you use any english word in any published text, you might end in the jail :).  They claim that lisaac would have only 19 keywoards compared with C that has 63. Had a first insight into the grammar, I think the 19 should renamed at least into 20, as one of the worst mistakes in the this lisaac is that your are condemned to name all types with uppercase. Another weakness is that there is no reference to namespaces. Size, hm the size… french like size… For a 624 lines (15745 bytes) of lisaac code a 43320 lines (593669) of C code is generated, and the compiled and stripped executable is 582208 plus the dependencies on libc.

There are however few good points in this story:

• trying to create a compiled prototype language
• there was a little effort to create a syntax that is more intuitive for object oriented thinking.

So thanks guys for your effort, but not for the moment…

addition: the bastard lisaac installation overwrote my .vimrc file!!! luckily I have stuff saved in .git…

Henry Kroll III mentioned on the tcc mailing list a little tool he wrote that would save some time in writing C code by skipping some apparently redundant “grammar markers”. He proposes practically to write C code with a syntax a bit closer to python, and his tool would decorate it, resulting in a C code. I really liked the idea to write less, and let the computer do some completion, but I do not see how something like that could be integrated into a development process. The only way I can find use for his idea is to write some vim script (or similar macros for other editors), that would do on the fly the completion based on the proposed syntax.

Discovered already months ago radare, same learning curve as with vim… for sure would not recommend to the 90% of the people working in It, but only for the 10%. If you hate vi, you will hate radare, if you love vi, you will even love more radare.

Did you ever think to print only text from a binary….

hexdump -v -e ‘80/1 “%_p” “\n”‘ /bin/ls.

or to see text in the physical memory (need admin rights, take care!)

hexdump -v -e ‘80/1 “%_p” “\n”‘ /dev/mem

read here: http://lwn.net/Articles/147901. It is about /dev/kmem . Something that was on my linux systems for ages… And I wanted to have a look inside it… and the big disappointment came… And the I found the article.. And found all that bunch of incompetents, who argue about writing any piece of software is crazy as rootkits and other mall-wares might exploit it. …

Well not anymore… I spent a little time to add new labels, and move stuff around. Who did not find an umbrella, was sent to archive. Now everything is fast. After doing that I realised that what was probably making my gmail interface slow were the “Multiple inboxes” on top. (You may activate them under settings). When opening the inbox, the “Multiple inboxes” boxes are doing a search based on the criteria in the definition. Anyway, they are still searching in the archive, but now my mailbox is responsive like before…

Investigating different memmem string search algorithms for my future vi like text editor, turns out that the libc replacements for embededd devices are slower than the native gnulibc. The test program opens a 300MB file (linux kernel header and source files merged-that is my reference), and searches for the (random) string “xxxxxxxxxxxxxxxxboeuoeuboeuoeu”. I linked against the memmem functions from 4 different libraries + a Boyer-Moore algorithm implementation. The results below show the time to search through the are the results (measured with time utility):

* dietlibc: 3.529
* newlibc: 1.955
* libc: 1.238
* klibc: 0.694
* Boyer Moore impl: 0.228

Did anybody really hear about klibc? Me not before. But it seems that it is providing the fastest algorithm. Dietlibc and newlibc are interesting projects for embedded devices. The goal was not speed, but size. However for a string search algorithm space shuld not be so much of compromise.

Making further tests… hm.. doing simple grep hm… result: 0.157, searching for the same string in the same file (about file cache: all programs had the same chance of having the file inside the fs cache). Well the reason is that grep is not loading the full file into the memory, it just loads chunks, and searches inside those chunks. The test program loads the full buffer into memory. The numbers above are for a mmap-ed version. Mmap seems to be overall better solution. However the page misses introduce too much noise in the results of the measurement of the algorithm. However in order to get more accurate results, I modified the test program to allocate ~300MB, and “read” the file into the 300MB. Reading the file is slower than the going through the mmap, as you can see below. However once having the full file in RAM, the measurements are more accurate:

with malloc/read
* Boyer-Moore: read/mmap time 0.358, memmem time 0.092
* klibc: read/mmap time 0.358, memmem time 0.555
* libc: read/mmap time 0.357, memmem time 1.100
* newlib: read/mmap time 0.358, memmem time 1.177
* dietlibc: read/mmap time 0.358, memmem time 3.344

So, the “Naïve string search algorithm” used by dietlibc is clearly the looser. Having in mind that dietlibc is intended for embedded devices, would make sense to improve it.

note: the read/mmap functions are from glibc for klibc/dietlibc/newlibc