lunes, 1 de septiembre de 2008

¿Funcionan las optimizaciones sobre el modelo de threading?

http://www.infoq.com/articles/java-threading-optimizations-p1

Interesantísimo artículo, que explica varias de las opciones de arranque de la JVM que yo recomendaba en el post JVM tuning: Parámetros de lanzamiento de JVM: Sun Hotspot, complementando así la información que publiqué en el post Allocation, deallocation and escape analysis for Java . Trata los siguientes conceptos:
  • Escape analysis - lock elision explained
  • Biased locking explained
  • Lock coarsening explained
  • Adaptive spinning explained
Adicionalmente presenta los resultados de un benchmarking hecho por él mismo probando combinaciones de varias de estas opciones y comparando el rendimiento de StringBuffer vs StringBuilder en ellas. Si la magia existiera, los tiempos del StringBuffer deberían tender a los del StringBuilder al aplicar todas las optimizaciones. Sus resultados:

Mis resultados en Linux x64 con 2xXEONx4Cores:

  • Son similares a estos en cuanto a los parámetros que más contribuyen al rendimiento y en cuanto a que "la magia no existe: usa versiones no sincronizadas de las clases!". Nota: las pruebas de rendimiento sobre varios núcleos y/o varios procesadores son muy distintas que en máquinas con un sólo núcleo, donde no hay contención entre threads "reales".
  • Curiosamente, en mis pruebas con distintas versiones del JDK (1.5, 1.6.0_07, 1.6.0_06-6p, y JRockit) he visto cómo el rendimiento en la "Performance Release 6" se ha incrementado drásticamente en el uso de StringBuilders frente a la edición "normal" de Java 6 (que por cieto es más lenta que JDK 1.5), pero no tanto de StringBuffers. Y también que los resultados de JRockit en ambos casos eran los mismos, es decir que JRockit sí que optimiza correctamente cuando no hay contención posible y Hotspot no del todo...

No hay comentarios: