2010-02-05 12 views

Respuesta

11

La funcionalidad de rastreo, puntos de interrupción y paso a paso que el emulador BEAM proporciona no están disponibles en código compilado nativo. También existe la limitación de que el código nativo no se descarga realmente de la memoria cuando carga versiones más nuevas del mismo módulo. (Esto puede ser un problema si tiene un sistema de larga ejecución donde continúa actualizando módulos o generando y compilando módulos de forma dinámica.)

Además, hay una pequeña sobrecarga al saltar entre código nativo y emulado BEAM, por lo que debería evitar tener ese tipo de cambio de modo en un circuito cerrado donde la velocidad importa. Preferentemente, compile todos los módulos estrechamente relacionados con los módulos de biblioteca estándar nativos y, si es posible, también los más importantes.

Finalmente, aunque el compilador nativo está bastante probado, la probabilidad de un error del compilador en HiPE es un poco mayor que la de los errores en el código C del emulador BEAM (aunque probablemente no sea más alta que la de los errores en GCC) por lo que puede correr un mayor riesgo de segfaults del sistema. Sin embargo, es bastante raro en estos días.

En resumen, el lugar principal donde la compilación nativa probablemente no se recomienda por ahora, es en productos independientes (como un servidor de caja negra que entrega a un cliente), donde la estabilidad, la depuración remota y poca memoria el uso es su principal preocupación y la velocidad de cálculo generalmente no lo es.

+0

"el lugar principal donde la compilación nativa probablemente no se recomienda por ahora, es en productos independientes": esto parece contrastar con lo que dijo @rvidring en una publicación relacionada. – jldupont

+0

Parece que no puede encontrar la publicación a la que se refiere. ¿Puntero? – RichardC

+3

¿Qué he dicho? :-) Parece que tampoco puedo encontrarlo. – rvirding

Cuestiones relacionadas