LLVM 8 import starting

Hi folks, following up the now rc3 tagged of LLVM 8.0.0, Dimitry Andric had decided to import it in the base system already. Indeed, generally the 3rd or so release candidate already reflects the final release ; the changes, at this stage, usually occurs more into the documentations for example, it is pretty safe as is ... Curious as always, I personally already planned to recompile the whole system as I write to benefit all the improvements I mentioned over the last months.

While at LLVM ; like many other "githubers", I go through other people projects and one particularly attracted my attention, if you are interested into LLVM IR generation, there is this Java-7 compatible compiler even though it requires a particular environment to build it all and even if you do not have direct professional or personal usage per se ; it can be somewhat an interesting subject of study. About php, the awaited new feature, which is the JIT support, is still under review as I write, despite it is Dmitry Stogov behind the keyboard it needs to take time to fix and improve as it is tested ... but ... it might be for soon !

Personally, these last days I have been pushing few improvements to radare to report better arm and mips ELF binaries sections or also more specifically adding OpenBSD sections. Also, I have been pushing a tiny update to the NSS library, which "powers" Firefox for example, to support the new getentropy call from FreeBSD 12 which had been merged ; another slightly more important code will be reviewed.The jemalloc project had entered into the release candidate phase thus my little contribution to improve the profiling for FreeBSD won t be into the soon 5.2 release as I pushed a bit too late :-) but that is very understandable ; they need to be careful as it undergoes stress tests and so on.

Zapcc 1.0.1

Hi folks,

following the test I did last year about zapcc, a very fast C++ compiler with a very effective in memory cache which gives benefits to large C++ code bases, there is a new released version 1.0.1 available here. Since the beta version the zapcc's server which holds the caching feature seems more stable/reliable.

This version is based now on clang 5.0.0 which is in fact a specific version of the related subversion trunk version I believe since only the 4.x serie is released.

First little "glitch", since the last test, I moved on from Linux mint to Arch Linux recently, the ncurses version shipped with does not have libtinfo shared library which zapcc/clang needs ... I do not know if it is a strong requirement of Zapcc or maybe LLVM could be compiled without terminfo support as a fix.

Apart of this little detail, zapcc delivers all its promises ! Like last time I made a test with one of my preferred C++ open source softwares, LMMS. This time I configured zapcc a bit differently. Since I run the test inside a virtualized ubuntu's environment, I set the memory per process according to the RAM limits I put and since I ll use two parallel jobs at best ...

This time also I will not cache auto generated headers and c++ files of LMMS and its plugins

Now, it is time to test against vanilla clang with two jobs. This is the general compilation time I get

And with zapcc

Since there is already a noticeable difference in this reasonable sized project, you can be insured in larger C++ code base, which is very common in C++ world, the delta is even beyond where you can see more than 3 times the speed. In my case I may have gotten a bigger difference if the cache memory limit was significantly bigger but it is actually fair enough as it is. Bear in mind though that zapcc is beneficial to C++ projects despite zapcc existence, for C code the usual ccache's solution is generally sufficient.

Hopefully, the mac OS and the Windows versions will be released in a reasonable near future.

Better, stronger, faster ... there is zapcc

Hi folks,


Today is test's day ! After the test of the static code analyser PVS-STUDIO, this time it will be a new C/C++  compiler on the market, zapcc from the young company Ceemple Software which is based on a modified version of LLVM/clang coming with an innovative caching system. It is available on Mac OS X, Linux and Windows. It works with any unix project based with cmake, autotools.

1/ Projects to test

To have some interesting numbers, I will try with some software important enough which needs several minutes of compilation, LMMS, the popular professional music production platform ... The tests will be conducted with unmodified clang provided by the system and zapcc, under Linux Mint, hardware is a i5-5200U CPU and 8GB of RAM.

Let's start with clang

This is the output with make's 5 jobs

Now ... zapcc which I just increased the default memory cache in the zapccs.config file from 1200 to 2000. Apart of this, we can also add which files we do not wish to be cached.

 The compilers executables are respectively zapcc and zapcc++ but we can see their clang "inheritance" through the following output ...

As you can see, there is a noticeable time decrease.
What if I try with another source code, opencv for instance to see if there is again a visible decrease as opencv takes longer to build than lmms.

Here, the output with clang ....

zapcc ...

As you can see, the delta is again pretty important ! Good job !


2/ Conclusion
 
Zapcc would be valuable for projects like Qt4/5 which usually take several hours to complete the compilation of all the components. In a professional perspective, the value of zappc is perceptible, usually C++ projects mean important sizes, thus by lessening the time spent on the build we can reallocate this time for other ressources ... But due to the caching, you have to keep in mind there is a logical and unavoidable memory usage increase, thus the settings of this part ought to be balanced regarding the target hardware ...

As zapcc is based on clang/LLVM, it could be possibly ported to FreeBSD as this platform gains more and more popularity in the professional world, it might be worthy to consider this possibility.

Another Microkernel based OS ... with DeviceAtlas

Hi folks,

As usual, the ... unusual can get my attention. So this time, it is Minix 3 (the 3.3.0, but tested previously 3.2,0 which, apparently, did not have shared library linkage support ...), which is a quite small smart Unix OS. But this one is a Micro kernel based one and it is exactly one of the reasons it is interested me in first place. So if it is a micro kernel, not surprising, that the kernel itself does not have million of lines of code but only something like 9000 ... Also, the userland is NetBSD compatible, they gave up on GGC suite; then now it is the couple LLVM/Clang.

So after charging the two Device Atlas C++ API on this VM, everything was compiled in a few seconds (Remember it is NetBSD compatible so Carrier Identification is compilable directly). Very good ! All work as expected (apache module included...), did not get the issue I had with 3.2.0 version.

Althought I would not use Minix 3 as my daily OS (alright ... its first target is the embedded world...), it is somehow an interesting and worthy one, its educational "roots" should not make you think it is a very poor Unix like (it is SMP capable, has ASLR even in the kernel part ...).