node --trace-hydrogen bench
	Log un fichier hydrogen.cfg avec des tas d'infos de compilation.

node --trace-alloc bench
	Affiche une blinde de trucs incompréhensibles comme
	Processing interval 116 start=120
	Moving live range 29 from active to handled

node --trace-representation bench
	rien de compréhensible, des centaines de lignes comme :
	Operation ADD has type info Smi, change representation assumption for Add (ID 29) from t to i

node --trap-on-deopt
	Ne fait rien :-(

--print-opt-code n'est pas présent sous Node (debug mode build only)




OÙ ÇA COINCE
	• Apparemment au niveau du passage Array -> Uint32Array.
	node bench :
		twin-bcrypt.slowarray.js -> 50 ms
		twin-bcrypt.utin32array.js -> 280 ms
	(juste en changeant heap32=[] en heap32=new Uint32Array(new ArrayBuffer(8192)) )
	Piste : dans un Uint32Array l'écriture d'entiers 32 bits est nettement plus lente que pour les entiers 31 bits.
		(les smi - small integers - font 31 bits et ont leur 32e bit réservé. Les entiers 32 bits doivent être boxés)
		https://www.mail-archive.com/v8-users@googlegroups.com/msg05036.html
		Ça ne justifie pas forcément ce facteur ×5 ou ×6, d'autant que la version finale n'est qu'en ×2 à peine.


	• node 0.10.32, nouvelle version de V8 apparemment, sortie le 16 septembre 2014.
	Une série de nouvelles désoptimisations, encore liées aux smi, sur les heap[offset + i].
	La solution consiste à les remplacer par heap[offset | i].
	Ça oblige à pas mettre n'importe quoi comme offsets, mais au moins V8 n'imagine pas qu'avec le + on va
	avoir un dépassement des 31 bits, donc il continue à optimiser.
	Le V8 de node 0.10.17 n'était pas aussi pointilleux.