¿Qué lenguaje/marco para HPC: Java/.Net/Delphi/C/C++/Objective-C?

Question

He deliberado interminablemente sobre qué idioma/marco se adapta mejor a lo siguiente. Necesito desarrollar un marco HPC. Todo el procesamiento será completamente OO. Pasará objetos entre instancias (externa) e internamente entre subprocesos & motores. Los objetos serán una extensión de Active Messages.

Estos casos podrían funcionar en el móvil, Windows, Mac, Linux, etc.

El sistema tiene que ser capaz de realizar un cálculo altamente paralelo con la velocidad & eficiencia, lo ideal es tomar ventaja de la ESS, e idealmente soporte CUDA/OpenCL.

he considerado lo siguiente:

Java - es la memoria hambre y no se ejecuta en Mac (no oficialmente, de todos modos)
.Net - Memoria de hambre; limitado en el alcance de la plataforma; sin SSE nativo
Delphi - no de 64 bits; ámbito de plataforma limitado
C/C++ - no admitido directamente por Mac; complejo para codificar; sin embargo, es omnipresente
Objective-C - compatible con Mac; parece ser compatible en otro lugar; funciona pasando mensajes, que es según mis requisitos de diseño; no sé mucho al respecto

¿Alguna sugerencia?

Answer 1

Aquí está mi recorrido por algunas de las opciones (en ningún orden en particular):

C/C++

Si todo lo que importa es el rendimiento (y nada otra cosa), éstas proporcionarán. El acceso directo a las construcciones de nivel del sistema, como la afinidad del procesador y el ensamblaje en línea, sin duda puede tener un impacto en el rendimiento. Sin embargo, hay 2 inconvenientes principales en la opción C/C++. En primer lugar, ninguno tiene un modelo de memoria bien definido, por lo que el modelo de memoria que está desarrollando es el de la CPU en la que está ejecutando el sistema (si no sabe qué modelo de memoria se aplica a la programación concurrente, entonces no debería estaré haciéndolo). Esto te vincula muy estrechamente a una sola plataforma. El segundo es la falta de un recolector de basura, la administración manual de la memoria es complicada (pero factible) en los casos simples, con C++ varias utilidades de apoyo que simplifican el problema (por ejemplo, punteros automáticos/punteros inteligentes). Al escribir código concurrente es un orden de magnitud más difícil ya que las reglas para liberar una determinada pieza de memoria se vuelven muy difíciles de definir. P.ej. cuando un objeto se pasa a un hilo diferente, ¿quién es el responsable de liberarlo? Si usa C++, es importante asegurarse de que está utilizando versiones seguras para subprocesos de las clases utilizadas para ayudar a administrar la memoria. P.ej. el puntero inteligente de refuerzo solo admite el uso de métodos declarados como "const" en diferentes subprocesos (por ejemplo, desreferencia está bien), sin embargo, los métodos no const (por ejemplo, la asignación) no son seguros para subprocesos.

Java

Java sería mi recomendación, que tiene soporte en todas las plataformas que usted ha mencionado (incluyendo móvil, por ejemplo JavaME y Android), así como CUDA support. Java tiene un modelo de memoria bien definido que es consistente en todas las plataformas, un JIT y optimizador robusto y maduro, y una cantidad de recolectores de basura buenos y que mejoran. La mayoría de las aplicaciones de uso general escritas en Java se ejecutarán tan rápido como sus contrapartes de C/C++. Si bien es un poco difícil de recordar, si está haciendo un trabajo de HPC, es muy probable que le arroje un hardware decente al problema. Dado que puede abordar cientos de GB en hardware básico, el problema de memoria es menos problemático de lo que solía ser.El móvil es la única área real donde el uso de la memoria está restringido y los entornos de tiempo de ejecución especializados funcionan mejor en este aspecto (ver arriba). El único inconveniente principal para Java (desde una perspectiva de HPC) es la falta de tipos complejos de paso a paso (es decir, estructuras en C#), por lo que todos los objetos complejos deben asignarse de manera estable para ejercer presión sobre el GC. Se supone que el análisis de escape ayuda bastante con esto, sin embargo, es difícil hacerlo funcionar bien en casos muy generales (tenga en cuenta que ha entrado y salido de varias revisiones del JDK recientemente).

Vale la pena mencionar el apoyo amplio idioma (Scala y Groovy ++ tienen muy buenos perfiles de rendimiento) y hay una serie de marcos de paso de mensajes simultáneos (actors, akka, kilim).

C# /. Net

Probablemente el más completo desde el punto de vista del lenguaje, especialmente si se incluyen cosas como F # para abordar las cosas de una manera funcional. Sin embargo, generalmente se lo empuja hacia una plataforma MS si quiere el mejor rendimiento (y la historia móvil aquí tampoco es buena). Mono produce una muy buena característica de plataforma (advertencia: soy colaborador); sin embargo, todavía están jugando al alcanzar el rendimiento, p. se ha agregado recientemente un colector preciso y compacto, y aún es un poco experimental.

Google Ir

Muy nuevo, pero interesante desde el punto de vista de que está compilado de forma nativa (sin sobrecarga JIT), pero todavía tiene un tiempo de ejecución fuerte, modelo de memoria, recolector de basura y el apoyo directo para la CSP (procesamiento secuencial simultánea) características en los idiomas (canales). Probablemente aún le queda camino por recorrer, el desarrollo de un nuevo GC se ha puesto en marcha pero aún no ha salido a la superficie y es probable que haya mucho más que puedan sacar del compilador.

Haskell y otros lenguajes funcionales

No

mucha experiencia aquí, pero algunas de las construcciones funcionales, tales como inmutabilidad y colecciones persistentes pueden ser muy útiles para construir aplicaciones robustas concurrentes.

Answer 2

el sistema tiene que ser capaz de realizar la computación altamente paralelo con velocidad & eficiencia, idealmente tomar ventaja de SSE, e idealmente apoyar CUDA/OpenCL.

Esto lo reduce a C o C++. Y como quiere OO, se ha reducido a solo C++.

serio, elige lo que usted o sus desarrolladores son mejores en.