A not so minimalistic OSC library

Finalement j'ai trouvé une utilité à oscpkt, ce n'est pas l'usage que je prévoyais quand j'ai commencé mais ça ma donné l'occasion de fignoler un peu le truc, de le rendre cross-plateforme (pour la partie sockets) et d'y ajouter le pattern matching sur les chemins OSC. J'ai aussi agrémenté la homepage avec une image de Troy McClure.

Ultra minimalistic OSC library

oscpkt , si ça peut servir à quelqu'un faites vous plaisir.

Quick comparison of the ARM Cortex A9 and Intel Atom

Here are two small benchmarks that I have just run on an Intel Atom N270, running at 1.6GHz, and a ARM Cortex A9 castrated by nvidia (the neon unit has been ablated in tegra2). The arm is a dual-core cpu running at 1GHz. Both are running ubuntu, the compiler used being gcc 4.4.

First bench: compilation of a very large (250000 lines) c++ file. This stresses the cpu and memory, but not the swap (the ARM one does not even have any swap). The compilation consumes ~300MB. This is of course a single-threaded test.

  • Atom: 1m15 sec.
  • Cortex: 1m49 sec.

That is a ratio of 1.44. gcc 4.4 on the Atom is much faster than on the cortex A9 (this is the gcc version of ubuntu maverick, so it is built for ARMv7).

The second test compares the anemic VFP floatting point unit of the Cortex A9 with the old Atom fpu. This is a typical linear system solve, in double precision, with pretty straighforward scalar code without any specific optimization or tricks, repeated 100 times. Standard compiler optimisations ( -O3 -ffast-math , with also -mfpu=vfpv3-d16 -march=cortex-a9 for the ARM)

  • Atom: t=4.68 sec.
  • Cortex: t=6.16 sec.

The ratio is 1.31 , so basically the same as the gcc compilation bench. Clock for clock, the cortex is slightly faster than Atom, but the Atom has a higher clock. And it still has its ballsSIMD unit, which will allow any Atom to humiliate the tegra2 cpu in any single precision floating point benchmark.

ARM d'honneur

Je commence à regarder la documentation de NEON, l'unité simd des ARM Cortex A8 et supérieurs. Il n'y a pas encore des masses de docs "accessibles" à ce sujet, pas évident de trouver des tutoriaux de la qualité de ceux qui existent pour Altivec ou SSE. On trouve quand même une série d'articles très interessants sur blogs.arm.com:

Et franchement après avoir lu ça on ne peut qu'éprouver un sentiment de gêne pour Intel et son SSE tellement rustique qu'il fait figure d'idiot du village (le village des instructions simd). Car oui, NEON n'est pas psychorigide sur les questions d'alignement mémoire (et c'est *tellement* chiant avec SSE, et un peu chiant avec altivec). Il est aussi capable d'opérations de shuffling très avancées, avec la possibilité, en une seule instruction, de charger, désentrelacer jusqu'à 4 vecteurs 64 bits ET de post-incrementer le registre d'adresse d'une valeur abitraire. Take that, SSE. Et enfin il propose un nombre de registres raisonnable, càd 32 registres de 64 bits, qui peuvent aussi être manipulés comme 16 registres de 128 bits (chez intel: 8 registres de 128 bits en mode 32-bits, 16 registres en mode 64-bit; chez altivec: 32 registres de 128 bits). On peut aussi remarquer que neon a une operation de multiply-add, le genre de trucs que intel n'a pas mis dans SSE, ni dans SSE2, ni dans SSE3, ni dans SSSE, ni dans SSE4v1, ni dans SSE4v2, mais dans AVX (celui des futurs Sandy bridge). Et enfin, les instructions neon ONT trois opérandes: deux termes sources, une destination. Comme altivec, et contrairement à SSE. Là aussi ça permet d'économiser des tonnes de MOVAPS stupides dont la seule raison d'être est d'éviter d'écraser la précieuse valeur d'un registre. C'est encore un domaine où Intel a fini par voir la lumière puisque AVX aura des instructions à trois opérandes.

Voila voila, donc après avoir lu tout ça je me décide, avec entrain, à faire quelques tests puisque j'ai reçu un Toshiba AC100 en début de semaine, le premier netbook à base de ARM Cortex A9 (parfum tegra2), justement pour tester neon. Un netbook fourni avec android, et sur lequel je me suis quand même bien fait chier à installer une ubuntu (c'est pas facile). Et là paf, quand je lance les programmes de test c'est "Illegal Instruction" sur la première instruction neon rencontrée. Bizarre. Effectivement le /proc/cpuinfo ne fait aucune mention de neon .

Et pour cause puisque ces gros tocards de nvidia n'ont pas implementé l'unité NEON dans tegra2. Je l'ignorais.

Je vais donc maintenant frapper ce netbook avec un marteau jusqu'à ce qu'il ne reste plus que quelque misérables copeaux que je balancerai aux chiottes, je tirerai la chasse, puis j'irai me coucher.

malloc lent

Le malloc de macos a la réputation d'être relativement pas rapide, et je viens de le constater sur un petit bout de code, qui passe la majeure partie de son temps à faire du malloc/free (vérifié avec Shark). Sous Snow Leopard, il met 14s à s'executer, alors que sous linux (dans une VM tournant sous macos), le même code, avec une version similaire de g++ et les mêmes optimisations, ne prend plus que 9s , ce qui fait une différence somme toute assez significative ! Voilà qui est édifiant.