MATLAB, el un popular 'laboratorio de matrices' empleado en universidades y centros de investigación y desarrollo, pero tiene grandes inconvenientes, y es que algunas de sus operaciones se pueden realizar mediante la biblioteca de rutinas matemáticas Intel MKL (Math Kernel Library), que está mal optimizada para los procesadores AMD Ryzen, lo que conlleva una enorme pérdida de rendimiento, pero esto ahora tiene arreglo.
|
etiquetas: mat , lab , intel , amd
El año que aprobé el último curso de la carrera donde tenía que usar esa bazofia, así amanecía mi sábana cada mañana que me despertaba y me acordaba de que jamás tendría que volver a verla:
tengo la esperanza que estas ultimas generaciones de amd inviertan la tendencia.
Por curiosidad.
Viendo los comentarios está claro que ha funcionado...
La librería está perfectamente desarrollada y puede leer que el procesador es compatible con esos juegos de instrucciones. Parece que está hecha así a posta para discriminar procesadores de la competencia. Es como si al detectar un procesador no Intel, decidiese usar la mitad de RAM.
Es como si la página web de Samsung se carga distinto en un Samsung y en otro móvil y no por versión del navegador, un detalle feo o mala práctica en algo bastante menos importante que esa librería.
Y total, Intel MKL es sólo una librería, hay otras Open Source que (según ellos) dan mucho mejor rendimiento.
us.battle.net/forums/en/sc2/topic/16203380383
Pero desde luego que, algo ha salido mal para que el programa funcione al triple de velocidad si se desactiva la optimización para ese procesador.
Sí, me lo he leído, y precisamente por eso, no veo nada de miserable en él. Tú crees que hay una intencionalidad en rebajar el rendimiento, yo simplemente veo una despreocupación, no hay una implementación específica para rebajarlo, simplemente una falta de implementación para optimizarlo. Y eso se soluciona utilizando otras librerías.
1992) y ahora se ve amenazado por los R y Python y con este último los Tensorflow, Keras, Scikits... además de Octave. Vaya, es una compañía que lo tiene que pelear ahora con los niveles de servicios y soporte a grandes grupos de investigación en empresas con la miríada de Toolboxes muy especializados que tienen, porque el mundo educativo me da que ya lo ha perdido.Pues ya que sacas el tema, si octave se compila con MKL tambien debería tener una mejora de rendimiento.
github.com/NexMirror/Octave/blob/53bad7604f15491a7a22e1029bd21ec075000
Python es muy popular, se usa mucho y es un buen lenguaje para aprender (por eso se enseña en muchas carreras).
En algunos campos, R es muy popular (estadística en general y biología molecular, por ejemplo). Obviamente puedes encontrar ejemplos tanto en estadística como en biología donde usan Python, o donde usan Matlab. Precisamente esto es lo que digo: el mundo no es blanco y negro.
La noticia es el workaround que permite usar AVX2 "engañando" a la MKL usando una variable no documentada. De hecho, MATLAB ha sacado un parche. Yo no sé si hay cierta "maldad" por parte de Intel, pero está claro que hay una guerra comercial entre Intel y AMD y esto va a joderles bastante.
Ya si encima las usamos con la implementación MPI de Intel es como la noche y el día para una basta cantidad de aplicaciones.
Ah, no son código abierto, pero se pueden descargar gratuitamente.
hardzone.es/noticias/procesadores/amd-intel-venta-procesadores-septiem
#39 El plan de Apple en un principio es diseñar sus propios procesadores basados en ARM. Si lo consiguen será la cuadratura del círculo... El tiempo dirá. De momento con AMD mantienen una "sana" relación en cuestión de chips gráficos a golpe de odio común a Nvidia.
También destacar que el "plan maléfico" de AMD es integrar gráfica y CPU en un mismo "chip" y de paso liquidar a Nvidia en el mercado doméstico. No van mal, teniendo en cuenta que los SoC de las dos grandes consolas los esta acaparando AMD.
Como no se saquen algo de la manga, de momento pinta la cosa mal para intel (y Nvidia).
No sabría decirte, Nvidia está pegando muy fuerte con la inteligencia artificial. Corrígeme si me equivoco, pero va por delante de AMD en Ray Tracing, en relación potencia/consume Y CUDA es casi ya un estándar por delante de openCL
Hay características "externas" que son las que todo el mundo (habitualmente) conoce: longitud de las líneas de cache, número de registro vectoriales y su longitud, conjuntos de instrucciones, etc.. Hay otras muchas características que no son tan conocidas, como el número de reservation stations (registros que te permiten recibir datos de memoria fuera de orden) que estan bastante escondidas en el manual de 600 paginas de programación del procesador que toque, y hay otras características que no las conoce ni gente que trabaja en Intel (si no ha estado en el grupo que las desarrollaba), o sea que imaginate cualquier otro...
Toda esa información se usa para optimizar las librerías lo máximo posible para unas arquitecturas dadas. Entonces, dado que Intel no es una fundación benéfica, y que las MKL cuestan un huevo de optimizar para las nuevas arquitecturas, es perfectamente normal que Intel las desactive si detecta que es un procesador para la que no ha sido optimizada.
Finalmente: me gustaría saber si de la misma manera que han publicado esto habrían publicado la noticia de "Pues no ha habido potra, corriendo la MKL haciendo pasar la CPU por Intel deja frito el procesador por exceso de potencia consumida" o similar.
Esto, al final, es una anécdota (que bien por ellos, pero es una anécdota).
R es para estadística y data science.
Matlab es más para ingeniería.
Python es un lenguaje genérico pero tiene librerías muy populares para maschine learning y data science.
En cuanto a librerías R tiene un porrón para cualquier cosa imaginable, es rollo académico pero es un caos total.
Python tiene menos librerías pero suficientes para lo más popular, está más organizado, tiene más documentación y prácticamente todos los libros de maschine learning usan Python como lenguaje.
No conozco mucho las posibilidades de Python en cuanto a gráficos y presentación pero sospecho que las librerías de R son bastante más potentes y fáciles de usar. Así que para análisis y presentación de datos me quedaría con R antes que Python. R también se puede integrar fácilmente con .NET, de hecho se puede programar en R en Visual Studio con un plug-in.
Ahí lo digo todo.
> array = matrix(c(4,2,3))
> array
[,1]
[1,] 4
[2,] 2
[3,] 3
> is.matrix(array)
[1] TRUE
> array[1,1]
[1] 4
> array[0,0]
<0 x 0 matrix>
dame numpy, pandas y sympy, y dominaré el mundo.
El coste de un sistema no es simplemente lo que pagas para usarlo. Cuando pagas software estas pagando soporte, mantenimiento, una garantía de que el sistema en el que basas tus desarrollos es estable, etc. Puede que a mas de una empresa le resulte mas barato pagar las licencias de Simulink que meterse a migrar modelos sin ninguna garantía de estabilidad, equivalencia de funcionalidad, teniendo que revalidar los modelos y encima tener que formar nuevamente a sus ingenieros y pagar el soporte (si es que lo hay).
A eso súmale que, en determinados roles de ingeniería, el MATLAB y el Simulink son herramientas que conoce cualquier ingeniero.
La peña de Meneame debería comprender un poco mejor cómo funcionan las empresas antes de lanzarse ciegamente a decir que no hay motivo para no usar software libre en todos y cada uno de los sitios donde se requiere un ordenador.
Tengo un Phenom II 1090T que como procesador es una auténtica bestia, pero la placa no ha salido fina (chipsets AMD 790GX + SB750), y eso que no me salió barata y el procesador compilando es una estufita de 125W. La gráfica interna de la placa es horrible, tanto en diseño como en controladores, y algo salva una gráfica externa mínimamente decente incluso para 2D, sobretodo en FB (no juego).
towardsdatascience.com/on-the-state-of-deep-learning-outside-of-cudas-
El Ray Tracing... Ni te doy la razón ni te la quito, me explico: AMD va a presentar dentro de poco su propia implementación en su (por fin) nueva arquitectura RDNA2, la cual se sabe que lleva desarrollando tiempo, por ejemplo para las próximas consolas.
Nvidia tiene sus RTcores en el mercado desde hace un año, pero no han tenido mucho éxito ni entre el público ni entre los desarrolladores. Con este panorama da la sensación de que se han precipitado y AMD no llega tarde a nada en este campo.
E Insisto, ojo con AMD y RDNA2 este año que lo mismo se lo explica en rendimiento a Turing y la tenemos, porque todo el "ecosistema" Nvidia tanto doméstico como profesional es superpropietario y caro de cojones. A ver como justificas eso si la competencia, mas
abiertabarata sencillamente se pone casi a la par.En fin, son mis percepciones y el tiempo dirá, tampoco soy pitoniso.
Haceos un favor y pasad a Python, a menos que os guste el sado.
Los procesadores evolucionan con el tiempo. Normalmente, nos parece que los procesadores son todos compatibles entre ellos, pero no siempre es del todo cierto. Es bastante comun que los procesadores nuevos incluyan instrucciones nuevas que permiten realizar ciertas operaciones mas rapido. Sin embargo, sin un programa intenta ejecutar una de estas instrucciones en un procesador viejo, el programa no funcionará.
Si no controlas el hardware en el que tu codigo se va a ejecutar, te quedan tres alternativas:
- Asegurarte que solo usas instrucciones tan viejas que cualquier CPU en el mercado va a utilizar. Durante mucho tiempo esto era el juego de instrucciones disponibles en un 386. Despues, el juego mas comun fue PentiumPro (i686). Hoy en dia esto seria x86-64, alla por principio del 2000.
- Utilizar instrucciones mas nuevas, pero dejar claro que tu programa requiere una CPU como esa o superior
- Hacer uso condicional de estas instrucciones. Tu codigo puede estar preparado para ejecutarse utilizando instrucciones nuevas, pero si durante la ejecucion se detecta que estas instrucciones no estan soportadas, se utiliza una version que no las requiere. La CPU es capaz de anunciar que juegos de instrucciones soporta.
Este ultimo caso es el que nos atañe, concretamente usando un juego de instrucciones que se conoce como AVX2. Este es un juego de instrucciones que fue añadido en CPUs Intel en 2013 y en CPUs de AMD en 2015. Son instrucciones SIMD, como en su dia fueron MMX o SSE. Lo que han descubierto es que esta libreria solo usa la version con soporte de AVX2 en procesadores Intel, incluso cuando se ejecuta en procesadores AMD.
En el pasado, esto no seria una sorpresa. Antiguamente un procesador intel usaba SSE, mientras que uno de AMD usaba 3DNow!. SSE y 3DNow eran similares, no eran exactamente iguales. La compatibilidad entre ambas no estaba garantizada y un procesador de AMD no diria que soportaba SSE (de la misma manera que uno de intel no soportaba 3DNow!). Era por tanto posible que un programa solo comprobara si la CPU soportaba SSE, sin comprobar si soportaba 3DNow, y en esos casos, se podia notar bastante la diferencia.
Sin embargo, este no es el caso para extensiones nuevas. Estas extensiones son las mismas para Intel y AMD, y la CPU responde de la misma forma. Los ingenieros de intel han añadido una comprobacion adicional. No solo hace falta que tu CPU soporte las extensiones para utilizarlas, sino que ademas tiene que ser una cpu Intel.
Y el problema es no solo que no utilice AVX2. AVX, SSE3 y SSE4 son tambien deshabilitadas si tu CPU no es Intel, independientemente de si tu procesador las soporta (SSE3 es de 2004, como referencia).
Y la pregunta final. Como han conseguido engañar al software de Intel para que crea que una CPU de AMD es realmente de intel? Pues porque los propios ingenieros de Intel añadieron una opcion no documentada para poder saltarse la comprobacion del fabricante de CPU usando una variable llamada MKL_DEBUG_CPU_TYPE.
Este el hilo de reddit en el que se basa la noticia:
old.reddit.com/r/matlab/comments/dxn38s/howto_force_matlab_to_use_a_fa
Pero vamos, aparentemente esto no es nuevo:
github.com/flame/blis/issues/312
Mi trabajo no tiene que ver con Matlab. No he usado Matlab desde que deje la universidad. No me pregunteis por Matlab, por favor.
Pero si cualquier CPU de Intel de hace años integra GPU, lo raro es que AMD no lo haya hecho antes al comprar ATI.
Para mi gusto te ha faltado añadir que históricamente la arquitectura x86 es propiedad de intel y que AMD (entre otros como cyrix) la copio/licenció? por su popularidad, y que puedes compilar aplicaciones para intel en cualquiera de sus generaciones (y perdiendo plataformas según indicas), o para AMD si el compilador lo soporta.
Aunque la verdad, mi PC favorito sería:
hackaday.io/project/643-minibsd-laptop-computer
- Placa PIC32-HMZ144 con 4MB de RAM, idealmente 8MB. invidio.us/watch?v=JeQjxYTONp0
- BSD 4.4 lite 2. Me sobra. Funcionaría casi todo lo actual bajo terminal, entre ello, lynx y mpg123 github.com/sergev/4.4BSD-Lite2
- Teclado, cualquiera, me basta un conector i2c a USB/PS2
- Sonido NPI, no costaría demasiado meter una tarjeta USB.
Es de esperar diferentes comportamientos de la misma aplicación en función de la plataforma y lo contrario es fruto de la ignorancia y desconocimiento en cuanto al funcionamiento de un procesador.
Piensa en coger a dos programadores y asignarles a cada uno el mismo problema complejo. Les indicas el nombre de una función y que parámetros acepta y que parámetros ha de devolver dicha función. Cada uno te desarrollará una solución compatible con el problema, pero cada uno la implementará a su juicio, y pueden (y de hecho son) diferentes en rendimiento.
Ahora extrapolalo a intel y amd, con la diferencia que intel al ser propietario de x86 va por delante, y AMD que quiere ser compatible tiene que copiarlo. Lo de que se comparten licencias... bueno, you can't spell x86-64 without x86.
En cuanto a tu BSD pic, no deja de ser una ordenador con su ram, rom y procesador con su propia arquitectura tambien, con un ISA definido: MIPS.
Sobre compilar contra plataformas especificas, si. En el mensaje original intentaba explicar algo mas sobre el tema, como por ejemplo que este es el motivo por el que algunos juegos te piden una cpu de gama baja para jugar y no vale una cpu mas vieja aunque sea mucho mas potente (aunque no es un caso muy comun). Al final, acabe quitandolo por no hacer el mensaje mas largo con informacion que no tiene mucho que ver con esta noticia
Pero si alguien tiene interes, la lista que se usa en gcc (probablemente el compilar mas famoso):
gcc.gnu.org/onlinedocs/gcc/x86-Options.html
En cuanto al BSD pic, pues he dicho PC al principio. Los 512kb de RAM no me convencen, mínimo 8MB para poder usar tcc, un compilador de Inform6, o bien frotz con facilidad teniendo un flite debajo pronunciando en inglés sin morirse la SD con tanto acceso a la SWAP.
>uname -a
OpenBSD openbsd.home 6.6 GENERIC.MP#0 amd64
Itanium era la sucesora 64 de x86, y su 'problema' (por asi decirlo) fue querer dar el salto sin vaselina, es decir, no tenia soporte 32bits y todo lo que instalases en un Itanium tenia que estar específicamente compilado para 64.
AMD hizo la arquitectura x86-64, totalmente desaprovechada porque no se instalaba nada mas que SOs y aplicaciones 32 en arquitecturas con soporte 64, y ahi tenias los usuarios pagando de más por lo mismo. Eso sí, mas tarde facilito la transicion a 64 y aqui estamos hoy, con Apple eliminando el soporte 32 (otros le seguirán).
cc #87
He aqui un ejemplo:
github.com/torvalds/linux/tree/master/Documentation/x86
Una pena, amd64 es mucho mas comodo de escribir. La unica desventaja es que es muy parecida a arm64 si estas leyendo rapido (pero tampoco importa mucho porque por otros motivos, arm de 64 bits es casi siempre llamado aarch64). Incluso me hubiera valido x64, que suele usar Microsoft. Pero x86-64, con el guion, los dos seises... uff
Sobre totalmente desaprovechada, será en otros sitios, en Linux tardaron poco en pasarla a 64bit al contrario que Windows (lo mismo los BSD) y muchos se cagaban tanto en Adobe como en los codecs propietarios de Mplayer via wine, donde instalar los de 64 bit era una puta odisea.
Y Apple con Catalina se está pegando un tiro en el pie, sobre todo con retrocompatibilidad que no es poca y su exíguo mercado de juegos en Steam.
Puede usar algo parecido a la virtualizacion con hypervisor.framework y un puente hacia Metal desde las libs OpenGL de 32 bit, pero eso de Apple no se le epera, no está en tiempos de cuando rulabas cosas PPC en Intel y antes, m68k en PPC, solo quieren vender para accionistas e idiotas sugiriendo basura como la touchbar y de paso cargándote la tecla de escape.
- VAX con BSD 4.3, me costó cero configurar vi correctamente, la terminal y la red. No es dificil configurar date(1) con soporte y2k, es pasar un signo de unsigned long a long creo en la especificación de la fecha. Configurar el host OpenBSD fué un chiste con bridge tap y una regla para PF. En Linux me quería cortar las venas.
- PDP10 con Tops-20 e intérprete frotz, probando aventuras conversaciones que ando generando en dicha plataforma con inform6.
- NetBSD con la CPU esa del Blit, lo que usaban en SDF más o menos, por curiosidad.
En Opera antiguamente y ahora en Chrome, en OpenBSD, ciertas cosas como Skype solo tiraban con User Agent de Microsoft.
Algunos drivers de X en Unix dan mas rendimiento que los de serie, sobre todo en gráficas intel --(modesetting(4) vs intel(4)-.
x86-64 estuvo desaprovechada al principio, pero eso no es ninguna sorpresa. Ni siquiera fue una sorpresa en su momento, simplemente una evolucion natural
cc #96 (no es una ñapa)