El MATLAB mejora en hasta un 300% en CPUs AMD Ryzen al hacerlas pasar como una CPU Intel

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.

[#7 Supercinexin]

Matlab, la mayor puta mierda que el ser humano computerizado ha creado.

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:

[#14 PacoJones]

#7 Sutil, muy sutil... y totalmente de acuerdo.

[#46 vaiano]

#7 amanecía brillante y marrón?

[#54 Desactivado]

#7 Jajjjajajajajjaajaaa suscribo todas y cada una de tus palabras.

[#60 Desactivado]

#7 si te digo que culpo a mi director de tesis de tener resultados demasiado tarde por obligarme a usar MATLAB y tener que lidiar con cosas que no tenían sentido....

[#65 EspañoI]

#41 #37 #7 en Matlab los arrays empiezan en 1.

Ahí lo digo todo.

[#66 Sr.Aracnido]

#65 Em...en R también.

> 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]

[#67 EspañoI]

#66 Este mundo se nos va al garete...

dame numpy, pandas y sympy, y dominaré el mundo.

[#69 reparador_reputaciones]

#67 Más quisiera pandas funcionar la mitad de bien que los data frames de R base. Y si te metes en el tidyverse ya ni te cuento

[#112 EspañoI]

#69 había perdido la esperanza de encontrar comentarios valiosos en meneame, y vienes tú con una sola palabra, y me haces pasar media noche jugando con R.

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

[#120 AsVHEn]

#65 Es que los vectores tienen que empezar en 1 y no en 0. Otra cosa es que los informáticos no sepan contar.

[#78 Desactivado]

#7 no sé tú caso ni el uso que le diste, pero es una herramienta que tras saber usarla es bastante útil. Sus librerías de análisis de señal son bastante buenas y sencillas de usar, y permite por ejemplo probar el comportamiento de un algoritmo de procesado de señal antes de meterlo en un DSP o una FPGA, en incluso traducir tu algoritmo a C o VHDL para poder hacerlo mucho más fácilmente, aunque ahí he de decir que no lo he probado y no se cómo de bueno será.

[#1 DangiAll]

Esto me recuerda a la guerra sucia de Intel contra AMD, y su compilador que perjudicaba expresamente las CPUs AMD.

[#2 Desactivado]

#1 Lo de siempre Intel se ha dormido en los laureles y no le duelen prendas en enmierdar.

[#32 Zaknafein]

#1 En el starcraft 2 tambien pasaba. De echo va mejor en un maquina virtual con la ID de la CPU cambiada a intel que en el host rulando AMD.

https://us.battle.net/forums/en/sc2/topic/16203380383

[#73 Mustela]

#32 Mmmm... sospechoso. No todo es procesador. Los puentes son muy relevantes en cuanto al rendimiento, así como la memoria. Lo de la máquina virtual habría que analizarlo detenidamente. Aunque no es la primera vez que veo batallas de este estilo entre Intel y AMD.

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).

[#105 heffeque]

#73 Qué va a ser una bestia. Quizás hace ya unos cuantos años. A día de hoy poca bestia es.

[#38 Lokodelbajo]

#1 Ahí nos faltan benas políticas antimonopolio, especialmente en el sector tecnológico.

[#10 ElPerroDeLosCinco]

Me encanta cuando una noticia tecnológica hiper-especializada llega a la portada de Menéame. Me recuerda a los viejos tiempos.

[#15 virginia]

#10 Hombre, hiper-especializado esto tampoco es... Pero sí, mola tener este tipo de noticias en portada (¡y más frikis aún también!).

[#17 Desactivado]

#15 ¿Para qué? Sólo tienes que ver los comentarios, ninguno ha entendido nada....

[#31 ElPerroDeLosCinco]

#15 A mí sí me parece hiper-especializado ¿Qué porcentaje de los meneantes crees que va a beneficiarse de este truco? Como mucho, un 10% sabe lo que es Matlab, y un 25% reconocen los nombre Intel y AMD. Y estoy siendo optimista. Pero vamos, que realmente configuren el Matlab a nivel de procesador, ni el 1% del personal.

[#11 Desactivado]

Clickbait sensacionalista... El título hace entender que hay un chanchullo para que en una prueba de benchmarking salgan mal parados los procesadores AMD, cuando la realidad es que simplemente nadie ha desarrollado aún la librería para AMD, y sí la de Intel y por tanto tiene que ir a una implementación AMD más antigua y no aprovecha todas las capacidades actuales de AMD.

Viendo los comentarios está claro que ha funcionado...

[#19 parladoiro]

#11 la MKL es desarrollado por Intel y no es libre. No es cuestión tanto del Matlab como de la MKL. No se hace una librería para AMD, se hace una librería que se salta la comprobación que es un Intel genuino y y así usa instrucciones que no usaría si no fiera un Intel genuino aún teniéndolas el procesador.

[#23 Desactivado]

#19 La Intel MKL está diseñada para ser óptima en procesadores INTEL, eso es así. Si quieres algo optimizado para procesadores AMD, pues tendrás que irte a otras librerías o hacer el tweak del que habla el artículo. Porque ya las hay (librerías optimizadas para AMD).

[#28 parladoiro]

#23 la optimización es que el programa tire de instrucciones del procesador, no que por que el procesador a la pregunta de si es un Intel genuino si responde «no» la librería no use instrucciones que tiene el procesador ya que esas instrucciones son estándar.
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.

[#47 DeusExM]

#28 La librería seguramente controle más allá de GenuineIntel y mire modelos o fechas de fabricación porque, de hecho, no todos los procesadores Intel soportan las instrucciones AVX2 (por ejemplo si son Xeon de hace unos 6 años -experiencia propia inside-). Y tampoco es justo que tenga que comprobar nada de la competencia y tener que mantener una lista de todos los modelos del mercado que no son suyos. Si ve que los suyos las soportan pues adelante, si no al standard más seguro que es el más antiguo y, claro, el más lento. Está claro que le viene muy bien, pero no creo que sea tan juego sucio puro y duro.

[#109 Desactivado]

#47 La cuestión es que si el micro te dice que soporta AVX2, tú deberías usar AVX2. Que luego no funciona bien porque la implementación no es buena, no es problema tuyo, pero lo que no puedes hacer es capar funcionalidades en función del fabricante del hardware.

[#95 b.roz]

#19 Y esto que dices, que la librería Intel MKL es desarrollada por Intel para SUS procesadores es lo que aquí casi no se menciona. El compilador de Intel y la MKL están mas optimizados que otros como gcc y el rendimiento es muy superior. El compilador no es de uso gratuito si no todo lo contrario, es bastante caro, pero las librerías si que están disponibles gratuitamente. Entiendo que podrían abrirlo, pero también que están en su total derecho de restringirlo a procesadores intel, por mucho que los amd integren esas instrucciones. De hecho, la pregunta sería la contraria, es legal engañar a la librería para que funcione en un AMD?

[#96 Desactivado]

#95 Ilegal no es, las ñapas como esa están a la orden del día. El navegador Links+ que uso tiene el User Agent de Opera Mini 3 y todo se dibuja maravillosamente bien.

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)-.

[#99 Razhan]

#95 El codigo de MKL incluye soporte para leer una variable de entorno y dependiendo del valor, saltarse la comprobacion de que la CPU es de intel. Vamos, que aqui a la libreria no la esta engañando nadie.

cc #96 (no es una ñapa)

[#113 parladoiro]

#95 no tiene derecho a restringirlo https://www.muycomputer.com/2014/06/13/multa-a-intel-por-monopolio/
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.

[#22 bralmu]

#11 La librería salió en 2003 y ha tenido muchas actualizaciones (la ultima de 2018). Esto no es actualidad porque se llevan quejando desde 2009. Tal vez lo actual es que ahora lo han probado con un Ryzen.

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.

[#45 Desactivado]

#22 Hace como 6 años que yo no trabajo con esto y de aquella ya se sabía que la MKL da sopas con hondas cuando usa AVX2 y que hace fallback a SSE si detecta una CPU de AMD.
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.

[#108 Desactivado]

#11 No, no es sensacionalista. La cuestión es que la MKL decide habilitar o no el soporte para SSE2/SSE3/SSE4/AVX/AVX2/etc. en función del fabricante del micro, y no de si el micro dispone o no de dichas funcionalidades (que se puede consultar con la instrucción CPUID). Intel lleva jugando sucio desde hace más de 10 años:

https://www.agner.org/optimize/blog/read.php?i=49#49
https://www.ftc.gov/news-events/press-releases/2010/08/ftc-settles-charges-anticompetitive-conduct-against-intel
https://en.wikipedia.org/wiki/CPUID

[#5 hey_jou]

lo de intel es siempre lo mismo, noticia en la que se muestra cómo de miserables són, y aún así lo máximo que se consigue es que la gente compre sus productos, pero muy enfadados, ya sea porque tienen potencia, ya sea porque los rebajan de precio.

tengo la esperanza que estas ultimas generaciones de amd inviertan la tendencia.

[#12 Desactivado]

#5 ¿Pero cómo que miserables?

[#18 abuelillo]

#12 Porque por lo que se lee en la noticia realmente no es que la biblioteca esté mal optimizada para no Intel, si fuese así aún haciéndolo pasar por Intel funcionaria más lento, simplemente si no es intel pasan completamente de optimizar nada, ni siquiera usan características estándar que tiene el procesador que son idénticas a las de los procesadores Intel.

[#21 Desactivado]

#18 De ahí a decir que es culpa de Intel o que Intel hace cosas "miserables" como se lee en los comentarios, hay un trecho, más bien la explicación más sencilla: "Nadie se ha interesado por optimizar para AMD esa librería"...

[#25 AdaSH]

#21 No parece falta de optimización, parece que la adaptación a AMD no debieron hacerla, ya que, funciona mejor con la (no) optimización para Intel en los AMD.

[#29 Desactivado]

#25 La mejora (de hasta el 300%) es respecto al rendimiento de AMD vs AMD (con tweak), no respecto a Intel.

Y total, Intel MKL es sólo una librería, hay otras Open Source que (según ellos) dan mucho mejor rendimiento.

[#33 AdaSH]

#29 No he dicho lo contrario sobre lo del 300%.

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.

[#51 Desactivado]

#29 Intel MKL son un conjunto de librerías matemáticas que no tienen rival como suite a día de hoy. Las OpenSource como OpenBLAS, FFTW, ScaLAPACK, etc. no pueden competir con estas. Sí a lo mejor alguna implementación suelta como la primera de la lista, pero no las demás.

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.

[#30 abuelillo]

#21 Creo que no has entendido lo que he dicho, la librería a sabiendas no aplica optimizaciones que tiene implementadas y podría usar. La libreria sabe que tal o cual característica existe en el procesador peo no la usa por no ser Intel, por eso hablan de hacer cosas miserables, el desarrollador de la libreria la hizo así a sabiendas para perjudicar a procesadores no Intel.

[#59 flixter]

#18 Pero la cosa no es tan simple hombre, y lo digo despues de haber trabajado con un ingeniero que en ese tiempo (hace 3 años) programaba la MKL y usaba nuestros programas como benchmarks de rendimiento, por lo que colaborabamos para sacar el mayor rendimiento posible.

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).

[#107 Desactivado]

#59 No te líes con detalles de microarquitectura, que es mucho más sencillo que todo eso: si la biblioteca detecta que el microprocesador es Intel activa el soporte para AVX y AVX2, y si no es Intel se queda con SSE 1 pelado, aunque el procesador soporte instrucciones más modernas.

[#16 tdgwho]

#5 yo cambié mi torre hace 6 meses, tenia un i5, ahora un ryzen 5. nada del otro mundo, pero paso de intel, tienen demasiados bugs, problemas y vulnerabilidades.... y para un uso normal, sirven perfectamente los amd

[#39 Desactivado]

#5 de momento Apple dijo que se salía de Intel en unos años no?

[#53 Desactivado]

#5 Esta invertida a lo bestia desde hace unos meses.

https://hardzone.es/noticias/procesadores/amd-intel-venta-procesadores-septiembre-2019/

#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).

[#56 Sr.Aracnido]

#53 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

[#74 Desactivado]

#56 En computación les va de puta madre, pero yo hablaba de mercado doméstico. Y les va de puta madre de momento.

https://towardsdatascience.com/on-the-state-of-deep-learning-outside-of-cudas-walled-garden-d88c8bbb4342

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 abierta barata sencillamente se pone casi a la par.

En fin, son mis percepciones y el tiempo dirá, tampoco soy pitoniso.

[#75 Sr.Aracnido]

#74 Interesante enlace, luego le echo un vistazo con detenimiento pero no sabría decirte. CUDA parece llevar demasiada ventaja con respecto a openCL y no sabría decirte si ser software libre y multiplataforma vaya a compensarlo. Con respecto a AMD en el mercado doméstico y su nueva arquitectura...parece haber un salto cualitativo con respecto a Polaris, igual que lo hubo respecto a TeraScale y eso puede no significar mucho más que ponerse a un nivel similar con Nvidia -o lo que saque Intel, que vete a saber-, no necesariamente superior. Pero volvemos a lo mismo, es hacer de pitonisas.

[#61 Desactivado]

#53 a ver si se les cae el chiringuito

[#81 Desactivado]

#53 >También destacar que el "plan maléfico" de AMD es integrar gráfica y CPU en un mismo "chip"

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.

[#79 Razhan]

Vamos a intentar explicar esto para gente sin conocimiento especializado de procesadores.

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:
https://old.reddit.com/r/matlab/comments/dxn38s/howto_force_matlab_to_use_a_fast_codepath_on_amd/

Pero vamos, aparentemente esto no es nuevo:
https://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.

[#82 lolerman]

#79 Genial explicación, de los pocos que lo entienden y ademas se molestan en explicarlo.

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.

[#83 Desactivado]

#82 Intel permite a AMD usar su licencia i386 y AMD hace lo mismo con amd64 a intel.

Aunque la verdad, mi PC favorito sería:

https://hackaday.io/project/643-minibsd-laptop-computer


- Placa PIC32-HMZ144 con 4MB de RAM, idealmente 8MB. https://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 https://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.

[#84 lolerman]

#83 Pero no desarrollan sus procesadores conjuntamente ni comparten el ISA (https://en.wikipedia.org/wiki/Instruction_set_architecture) por lo que siguen siendo dos plataformas diferenciadas.

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.

[#85 Desactivado]

#84 He, no tan diferenciadas. Si tu OS de juguete arranca en amd64 al igual que el intel, y los programas pasan todos los tests, son plataformas compatibles.

[#86 lolerman]

#85 ¿Y que pasa si arrancan? Los juegos de instrucciones CISC los componen instrucciones complejas que tratan de ahorrar tiempo no usando instrucciones mas simples. El rendimiento no tiene por que ser el mismo aunque ambos implementen las mismas instrucciones.

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.

[#89 Desactivado]

#86 Sobre las licencias, pues eso. Intel no tenía amd64 y ni se le esperaba, así que rebajó requisitos de licencias para poder operarlo, los cuales antes tenían Itanium que eran una cosa marciana de narices.

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.

[#91 lolerman]

#89 Itanium no es marciano. Ni lo es Power, ni MIPS, ni PowerPC, ni Alpha, ni HP PA-RISC. Son cosas que han tenido su extensión, mercado y uso. Lo que pasa es que tu no eres su mercado y te suena marciano.

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

[#93 Desactivado]

#91 Eh, he rulado cosas MIPS y PowerPC, digo "marciano" porque en todas las lineas sucesorias de CPU hubo bastante retrocompatbilidad por detrás. Itanium tenía bastate poco uso respecto a otras arquitecturas en su día.

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.

[#94 Desactivado]

#91 Aunque en emulación las cosas más raras que he tirado son:

- 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.

[#97 lolerman]

#94 Ya no me cuesta entender como una cuenta de 13 días tiene +400 comentarios. Se te nota que te gusta presumir. Ya crecerás

[#100 Desactivado]

#97 Hablas como si no conociera Menéame desde hace 10 años o más y antes no hubiera perdido el tiemp... aprendido en barrapunto.

[#101 lolerman]

#100 Hablo como si el comentario #94 no aportara información a la conversación.

[#98 Razhan]

#91 Itanium no fue un acierto, eso esta claro. Es el producto de una epoca donde se creyo que analisis estatico de codigo, asi como soporte adicional en el compilador podia generar una arquitectura mas eficiente. Estamos hablando de cosas como el compilador intentandole decir a la CPU que rama era la mas probable que se ejecutara durante la compilacion, o intentar comprimir multiples instrucciones en una sola instruccion gigantesca. Muy poca de la tecnologia exclusiva de Itanium se a reaprovechado para procesadores actuales.

x86-64 estuvo desaprovechada al principio, pero eso no es ninguna sorpresa. Ni siquiera fue una sorpresa en su momento, simplemente una evolucion natural

[#87 juanlinux]

#82 te recuerdo que cuando AMD saco los 64 bits, túvo Intel que pagar a AMD para poder emplear procesadores de 64 bits en condiciones, si 64 bits pero que al emplear software de 32 no perdieran rendimiento como los itanium es decir tuvo que meter código de AMD, en sus procesadores a los cuales llamo x86_64

[#90 Desactivado]

#87 En lInux y BSD la arquitectura de 64 bit "intel" se llama "amd64" con pleno derecho.

>uname -a
OpenBSD openbsd.home 6.6 GENERIC.MP#0 amd64

[#92 Razhan]

#90 El nombre oficial en el kernel de linux es x86-64, no amd64. Debian si que utiliza amd64 de manera oficial, al igual que gentoo.

He aqui un ejemplo:
https://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

[#88 Razhan]

#82 Efectivamente x86 es propiedad de Intel, pero Intel y AMD siempre han tenido acuerdos legales para intercambiar tecnologia (al menos desde que salio x86). Sin embargo, x86-64 es trabajo de AMD. Diria que hoy en dia la posibilidad de que rompan dichos acuerdos es minima, ambos tienen cosas que el otro quiere.

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):
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

[#41 Sr.Aracnido]

#37 Hoy por hoy tengo muy claro que prefiero meterme en R y currarme una función propia o buscar algún paquete esotérico perdiendo una tarde si hace falta antes que volver a meterle mano a Matlab. Muy necesitado tendría que estar de alguna super importante característica específica. Si no, ni con un palo. Y con SPSS tres cuartos de lo mismo, aunque éste a día de hoy sí lo sigo viendo útil. Y Octave...no es 100% compatible y en IA por ejemplo, he visto dar disgustos a más de uno...Matlab para mí que se irá reduciendo a un nicho de mercado muy especializado donde R o Python no estén básicamente porque o no han llegado todavía o no les haya interesado estar.

[#3 Zeioth]

Me han dicho que el lenguaje 'R' se está merendando a Matlab. Es esto cierto?

[#4 Suigetsu]

#3 Más que R, es Python.

[#8 BodyOfCrime]

#4 R se merendó a matlab y python se merendo a R como buena Anaconda

[#20 ecam]

#3 #4 #8 El mundo real no es ni blanco ni negro. Depende de en que campos, Matlab sigue siendo superior, o R, o Python.

[#24 Suigetsu]

#20 Simplemente te digo lo que se usa. En las universidades de ingenieria las prácticas se haces en python. La imagen del agujero negro se generó en python etc.

[#34 derivada]

#24 ostiá la imagen del agujero negro se generó en python? wow!

[#50 Suigetsu]

#34 http://www.blog.pythonlibrary.org/2019/04/11/python-used-to-take-photo-of-black-hole/

[#72 dirok]

#50 a ver si esto lo ve@BilisPorBandera que hace una semana me decía que Python solo se usaba en juguetes.

[#114 Desactivado]

#72 Un ejemplo VS el resto de cosas.
Parece una buena muestra para tomar conclusiones

[#42 ecam]

#24 Y muchas otras cosas se hacen en Matlab, y muchas otras en R.

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.

[#44 Suigetsu]

#42 En ningún momento he dicho que solo se use Python. Simplemente te he dicho la moda.

[#48 EmuAGR]

#24 En las universidades de ingeniería las prácticas se hacen el Matlab. Pero qué estás contando.

[#49 Suigetsu]

#48 Pues la verdad. Antes sin duda matlab o octave, ahora ya no.

[#55 barni]

#49 buena suerte reemplazando SimuLink...

[#62 Suigetsu]

#55

[#70 barni]

#62 sabes lo que implica para empresas que tienen todos sus modelos desarrollados durante años en Simulink migrar a algo simplemente porque es gratis y porque se puede hacer?

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.

[#71 Suigetsu]

#70 Alto colega, simplemente te he dicho que existe la alternativa. Lo demás te lo has sacado tu de la manga.

[#80 Desactivado]

#70 En redes neuronales Python lo peta. Por cierto, sobre velocidad, llaman a BLAS/LAPACK por debajo, y son librerías creadas en Fortran.

[#63 ivan123]

#c-48" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3213499/order/48">#48 Depende, no hay un único lenguaje para prácticas en ingenierías, mi mujer está estudiando ahora una ingeniería y en imágenes biomédicas usan Matlab, en estadística R y en otras Python, Java o C#

[#58 TetraFreak]

#24 A mí me metieron Pascal

[#106 Desactivado]

#24 pues en las de física se sigue usando MatLab, no se exactamente por qué, pero hace virguerías y se da en primero. Al final cada compilador tiene sus ventajas y desventajas dependiendo del campo en el k se use. Además Python es un lenguaje o un compilador? Porque me suena que MatLab es más que un lenguaje.

[#26 Naiyeel]

#20 En olor a añejo... 1970, buena añada para algunos vinos.

[#76 BodyOfCrime]

#20 Y en otros se usa Cobol. Eso no significa que haya otros predominantes

[#27 Sr.Aracnido]

#3 #8 Matlab lo he usado sobretodo en inteligencia artificial, y personalmente nunca terminó de gustarme -aunque también odio de corazón Mathematica , aún con sus virtudes- R lo veo más potente en el sentido de más capaz de manipular matrices con utilidad estadística Ahora mismo, diría que es un toma y daca entre R y Python, esta última tiene la ventaja de sus librerías aunque puedes usar ambas a la vez, siendo en muchos casos innecesario elegir.

[#37 pantulis]

#27 A Matlab lo que le está pasando es un proceso de "unbundling": de pasar a ser una herramienta para todo lo que tuviese que ver con matemáticas y ordenadores (entre Matlab y SPSS estaban en su época 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.

[#64 Desactivado]

#4
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.

[#68 ur_quan_master]

#4 más que Python, las librerías C C++ con interfaz para Python.

[#9 Robus]

¿Han probado de ejecutar la misma aplicación en Octave a ver que tarda en cada uno de ellos?

Por curiosidad.

[#40 Desactivado]

#9
Pues ya que sacas el tema, si octave se compila con MKL tambien debería tener una mejora de rendimiento.
https://github.com/NexMirror/Octave/blob/53bad7604f15491a7a22e1029bd21ec075000057/m4/ax_blas.m4#L138

[#52 Desactivado]

Que holor a estafa...

[#35 derivada]

#11o no te has leido el artículo o no lo has entendido

[#36 Desactivado]

#35 Entiendo que iba por mí, que ya ni linkar comentarios sabemos...

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.

[#43 Jakeukalane]

#35 diría que se refiere al titular "El Matlab".

[#6 tiwaz]

Vaya, seguro que ha sido mala suerte que esté mal optimizada para los Ryzen. Si es que la gente desconfía a la mínima...

[#13 Desactivado]

El Jonathan, la Jessy.

[#57 Desactivado]

El MATLAB mejora en hasta un 300% en CPUs de el Ryzen de el AMD al hacerlas pasar como una CPU de el Intel

[#77 nospotfer]

Todavía hay gente que usa MATLAB?
Haceos un favor y pasad a Python, a menos que os guste el sado.