¿Diferencia de rendimiento entre las compilaciones de VALA y AOT?

Question

He estado desarrollando una aplicación de procesamiento de imágenes en Java, pero recientemente me interesó VALA. La razón es porque creo que puedo aumentar el rendimiento de la aplicación (mi preocupación se centra principalmente en la interconexión con librerías C/C++, ya que parece < Example> que hay un castigo de rendimiento cuando se utilizan puentes C/C++ en Java).

de fondo (lo que sé):

• VALA se traduce en código C y entonces su compilado a un código máquina nativo.
• AOT (Java/Mono C#) también puede producir códigos de máquina nativos (en lugar de utilizar máquinas virtuales, pero aún requiere el paquete de tiempo de ejecución).
• En algunos casos, el uso de una VM puede ser incluso más rápido que un código de máquina nativo (ya que se puede optimizar a través del compilador JIT).
• Las bibliotecas de C/C++ de consumibles se pueden producir utilizando VALA.

Hay algo que va alrededor de mi cabeza y no puedo encontrar la respuesta:

1. CAN/C++ bibliotecas consumibles C pueden producir usando un compilador AOT? (Supongo que no).
2. ¿El binario producido de AOT sigue teniendo el problema de rendimiento de puente? (Supongo que sí)
3. Llamar a las bibliotecas C/C++ en VALA tiene el mismo rendimiento que llamarlas desde C? (Creo que es).

¿Alguna idea?

Answer 1

1. ¿Pueden producirse bibliotecas de consumibles C/C++ utilizando un compilador AOT?

No debería ser posible ya que no tenemos encabezados y no es estrictamente una clase C lo que el compilador AOT está creando, sino solo el código de máquina.

(Nota al margen: las clases de Java pueden ser called inside C/C++, pero como los compiladores de AOT producen un solo archivo binario, estoy seguro de que no puede acceder a las clases de Java desde fuera de ese archivo).

Respuesta: NO

2. ¿Tiene el binario AOT producido, todavía tiene el problema de rendimiento puente?

Primero, necesitamos saber: si llamar cualquier clase C/C++ desde Java usando un puente (como JNI, javacpp, etc.) siempre dará como resultado una pérdida de rendimiento?

Según "W_" de ##java@irc.freenode.net:

que depende de lo que estés llamándolo (por ejemplo, si los argumentos tienen que ser convertidos y tal). Simplemente llamar a una función de biblioteca sin argumentos o devolver la conversión de tipo no debería tomar un tiempo diferente que en cualquier aplicación C .

Pero como estoy usando JavaCV como puente para la biblioteca OpenCV, utiliza varios tipos de objetos que, si lo anterior es cierto, debería afectar el rendimiento.

Por lo tanto, puede ser lógico que la compilación AOT pueda acelerar un poco la ejecución, pero aún tiene que pasar por el puente y realizar la conversión de tipo.

Respuesta: Sí (pero puede ser un poco más rápido)

3. llamante/C++ bibliotecas de C en VALA tiene el mismo rendimiento que llamarlos de C?

Como se convierte directamente en C, no veo una razón por la que no. Esto fue respaldado por "nemequ" de #vala@irc.gimp.org:

prácticamente, sí. vala tiene el hábito de usar variables temporales, pero es exactamente el tipo de cosa que la mayoría de los compiladores pueden optimizar fácilmente de distancia. si estás usando gcc, pasa -O2 y deberías estar bien.

Respuesta: SÍ

Todavía no sé por qué "alguien" votó para cerrar mi pregunta y él/ella no se molestó siquiera para comentar al respecto. Creo que estas preguntas/respuestas son suficientemente constructivas (como pst comentadas) y pueden ser útiles para otras personas que son nuevas en los compiladores VALA o AOT.

Si mis conclusiones no son correctas, por favor corrígeme.