Par zogzog, dimanche 24 octobre 2010 à 20:36 :: Dev
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.
Par zogzog, jeudi 14 octobre 2010 à 00:31 :: Dev
oscpkt , si ça peut servir à quelqu'un faites vous plaisir.
Par zogzog, lundi 11 octobre 2010 à 01:17 :: Dev
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.
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)
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.
Par zogzog, mercredi 6 octobre 2010 à 00:59 :: Dev
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.