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:
us.battle.net/forums/en/sc2/topic/16203380383
Viendo los comentarios está claro que ha funcionado...
tengo la esperanza que estas ultimas generaciones de amd inviertan la tendencia.
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.
Ahí lo digo todo.
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.
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.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).
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.
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.
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.
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.
>uname -a
OpenBSD openbsd.home 6.6 GENERIC.MP#0 amd64
www.agner.org/optimize/blog/read.php?i=49#49
www.ftc.gov/news-events/press-releases/2010/08/ftc-settles-charges-ant
en.wikipedia.org/wiki/CPUID
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.
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
Por curiosidad.
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.
Se podrá centrar en X86 y en juegos de instrucciones donde es más avanzado Intel, pero usar la pregunta Intel Genuine para no verificar que el procesador tiene SSE4, AVX y AVX2 es una guarrada y puede que ilegal.
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.
Y total, Intel MKL es sólo una librería, hay otras Open Source que (según ellos) dan mucho mejor rendimiento.
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).
dame numpy, pandas y sympy, y dominaré el mundo.
Me ha gustado el concepto de tidyverse. Quizá implemente algo sencillo para poner a prueba su rendimiento.
Mis circunstancias no me permiten cambiar de la noche a la mañana mi caja de herramientas, pero reconozco algo bueno cuando lo veo.
Muchas gracias
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
> 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>
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.
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
Al margen de la explicación lógica, también he recabado experiencia con aplicaciones de servidor en ambas arquitecturas, y puedo decirte que hasta la fecha he resuelto 3 problemas de rendimiento que he encontrado en 3 clientes moviendo el sistema de amd a intel (en la misma generación, sin hacer trampas y hasta la fecha no he experimentado la situación opuesta.
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.
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.
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.
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.
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)-.
www.zdnet.com/article/top-linux-developer-on-intel-chip-security-probl
Coge cualquier distro de Linux con las vulns sin parchear desde el arranque editando el grub, dejando todo de serie, observa la diferencia de rendimiento.
En OpenBSD han tenido que desactivar el SMT, no te digo más. Si lo activas, por tu cuenta está con sysctl.