Los nuevos Apple A10 demuestran que un MacBook ARM es posible

No quiero ofenderte rocketboom, pero lo que dices es una tontería. Porque además es justo lo contrario... es cierto que el conjunto de instrucciones es muy distinto, algo lógico porque son plataformas totalmente distintas. Pero es que además, si seguimos tu ejemplo, resulta que tu camión internamente tiene un motor de moto... Ya que actualmente no hay prácticamente ninguna CPU CISC pura, y menos las CPUs x86, que desde mediados de los 90, internamente son RISC (por ejemplo en Intel desde el Pentium Pro de 1995). Externamente las instrucciones son CISC, concretamente x86, por mantener la compatibilidad... pero el decodificador de instrucciones coge esas instrucciones y las convierte en microinstrucciones compatibles con un core RISC.

Pero bueno, es que ya partes antes de otro error de concepto, aunque muy extendido: que RISC implica instrucciones sencillas y un set muy pequeño de ellas. Eso es parcialmente verdad y fue lo que al final hizo que los RISC reinaran... Pero curiosamente eso no es esencial y muchos RISC tienen instrucciones complejas, etc... Porque lo anterior es consecuencia, no la base. El motivo porque eso sea así es debido a que a diferencia de los CISC, en un RISC las instrucciones siempre cumplen:

- las instrucciones son de tamaño fijo y con pocos formatos
- las instrucciones o son de carga/almacenamiento (las que traen o llevan datos a la RAM, unidades de I/O) o de operación (sumas, restas, comparaciones, etc)

Adicionalmente, aunque no necesario, normalmente las CPUs RISC cuentan con un buen repertorio de registros de propósito general (realmente en muchas arquitecturas RISC, registros como el puntero de pila, etc, es un registro concreto, pero que funciona como cualquier otro registro, etc). Frente a los escasos y especializados registros en arquitecturas CISC.

Lo anterior tiene la consecuencia de que hacen faltan muy pocas instrucciones y muy sencillas, que puedes estar haciendo operaciones de carga/almacenamiento al mismo tiempo que se están ejecutando instrucciones de operación, porque no se molestan entre sí y además, muchas se pueden ejecutar fuera de orden. Además lo anterior tiene una consecuencia inmediata: las CPUs RISC son mucho más sencillas, pero por todo ello se pueden duplicar muchas partes del procesador y así hacer aun mucho más trabajo.

Al final, es cierto que en casos muy concretos, la aproximación CISC gana (también ganaría si la RAM fuese igual de rápida que la CPU o más rápida aun, como paso en los 70 y hasta mediados de los 80)... en el resto de escenarios no hay color. Por ello, actualmente arquitecturas aparentemente CISC como la x86, realmente lo único CISC ya son las instrucciones, porque internamente todo es RISC.

Siguiendo tu analogía, pues sería como enfrentar tu camión en un reparto en medio de una ciudad grande, con decenas de pequeñas motos... para algún paquete concreto, pues el camión gana, para el resto, es que pierde por mucho (aunque optimices con la ruta mientras que las motos después de cada entrega o recogida, siempre vuelvan a base y con el camión no sea así... en gran medida porque es muy difícil optimizar adecuadamente en un entorno dinámico).

Pero además no es un descubrimiento moderno... sino de los años 80 (realmente ya Cray ya hacía diseños RISC aunque no existiera el concepto como tal, pues en los años 60).

Las arquitecturas RISC solo tienen un gran punto débil: la densidad de código es menor... en cristiano, los programas ocupan más espacio en disco. Pero, en la práctica, eso solo afecta en microcontroladores y soluciones así en que la capacidad de almacenamiento de programa es muy pequeña.

No es que los CISC no tengan sentido a día de hoy, por ejemplo para ciertos usos siguen siendo interesantes, por ejemplo, aunque los microcontroladores están tendiendo todos a RISC, pues ahí en esos ambientes en que se quiere un microcontrolador que no tiene que ser rápido, sino barato, en donde la RAM puede ir a la velocidad del microcontrolador (en fin de cuentos muchos trabajas a pocos MHz), etc... Pues diseños CISC Hardvard (el hardware de PC sigue el diseño Von Newman en donde datos y instrucciones van juntos en la misma memoría, en Hardvard van separados) dan mejores resultados. Aunque diseños de módulos genéricos tipo Arduino están copando buena parte del mercado.

Hasta luego

El problema es si el test realmente es significativo o no a la hora de comparar.

Por ejemplo, si comparas el 0-100 de una locomotora de tren con respecto a un utilitario, te saldrá que el utilitario es mucho más 'potente' que el tren porque consigue mejor tiempo.
Pero tú y yo sabemos que no es así, y que el que quiera arrastrar vagones seguirá usando una locomotora.

Para mí estos tests sería significativos si implementasen tests complejos que obliguen a las CPUs a darlo todo (incluyendo el uso de las instrucciones específicas de la arquitectura x86-64), durante un lapso de tiempo significativo. No pequeños algoritmos que apenas representan todo lo que hacen cientos de programas que se usan a diario en equipos de sobremesa.

Jajajaja yo creía que las habías puesto de broma

Creo que ha sido un error el haberte dado un brillante a un comentario que se contradice bestialmente.

Se sabe que son arquitecturas distintas. Pero se sabe que las aplicaciones tienden a ser agnosticas. Es inevitable comparar. Además habrá que ver que Apple mejoró notablemente su performance. Lo que queda pendiente es ver cómo escala a una arquitectura más grande. Allí se vería que tan efectivos son los procesadores de Apple y que tanto ARM ha evolucionado.

Que va el te dice toda la verdad son comparables pero lo único que demuestra el estudio es que colocan CPU muy malas en los MacBook.

la gente vota positivo, porque sabe la diferencia entre un procesador ARM y uno x86, y que las comparaciones entre ambas arquitecturas no tienen sentido. Tu, que no conoces las diferencias, pues no entiendes porque, y luego iras por ahi diciendoles a tus amigos que el micro de tu telefono es casi tan potente como el de sus sobremesas de ultima generacion de 400 euros.

Cuando se entere se queda como este:

https://www.youtube.com/watch?v=8l_FXRdJO44

xDDD

por cierto, releyendo los mensajes, quizas haya sonado un poco "violento" el tono.
Te pido disculpas si te has sentido "violentado" o no te ha gustado como me he expresado.

No me he sentido para nada violentado. Mi positivo para si solo por ese detalle. Digno de elogiar desde mi punto de vista. Ojala todo el mundo que comenta por aqui fuera así.

Pregunta trampa, pero creo que ni te has dado cuenta.
No. No son el mismo sistema operativo.
Si sabes algo de sistemas operativos sabras que no pueden ser el mismo sistema operativo, ni parecido, el que se ejecute bajo una arquitectura x86 (que no 64) y una ARM.
Por tanto, aunque ambos sistemas operativos se llamen GNU-LINUX (que no linux a secas, que es solo el kernel, y no el OS), ambos OS se pareceran lo mismo que un huevo a una castaña... ambos tienen cierta forma ovalada, si. Pero no se pueden comparar, porque son cosas diferentes.

Pero no te tenias que haber ido a linux hombre... hay versiones de windows para ARM... ¿no ves que hay w10 para las raspberrypi?

Hola m0w!!

Hablando sobre GNu/Linux. Te cuento. Soy usuario de Gentoo (Larga vida a la optimización!). Como tal, la instalación del sistema se realiza mediante binarios. Imagino que sabrás qué es. Al trabajar sobre binarios, se puede compilar el sistema para el procesador que se desee, además de poder ajustar los parámetros de optimización (en make.conf con las CFLAGS, LFLAGS, etc. Dolores de cabeza a miles hasta llegar al sumun). No se si me explico bien o se me entiende lo que quiero decir (Estas horas ya no dejan pensar con claridad). Lo que quiero decir es que si, que se puede compilar un mismo sistema para distintas arquitecturas y sí, seguirá siendo el mismo sistema pues procede de binarios. Es más con el tema de la optimización, se puede compilar para un mismo procesador con diferentes grados y a mismo procesador en unos irá mejor que en otros (-O0 vs -O2), aunque la mejora del rendimiento a nivel usuario es leve, se llega a notar sobre todo en el consumo de RAM (KDE cargado en 380MB y sin apurar el kernel). Si lo trasladamos a servidores, llegué a leer que se puede ahorrar bastante en energía hasta un 30% con un sistema compilado para una arquitectura específica. No encuentro ahora la noticia para poner link.

Lo de Windows ARM, bueno, sin comentarios.

Respecto al resto de comentarios decir que sí, que las dos arquitecturas son comparables perfectamente. Pues las dos desarrollan un trabajo pero con juegos de instrucciones distintos (RISC/CISC). Como ha dicho LC III, se trata de medir del Punto A al punto B.

P.D: Siempre he pensado que algún fabricante podría sacar una placa de portátil o sobremesa con varios chips ARM, a modo de cluster, y lo petaría. Por supuesto only for Linux ;)

P.D.2: Disculpad por el batiburrillo de palabras, pero estoy medio dormido

Se podrían poner 4 A10 en paralelo? O es técnicamente imposible? Así quizás podría igualar el rendimiento de un i7 actual y mas o menos con el mismo tamaño.

Quien dice poner 4 en paralelo dice incluirlos todos en un mismo chip bien integrado con el mismo tamaño de un i7. (A eso me refería)

Parece que tienen futuro estos procesadores con un OS bien optimizado.

Ambas son ,máquinas de von neumman, me explicas que diferencia de arquitectura hace que no sean comparables?

Viendo que tu comentario tiene tantos votos positivos, me hago una idea del alto nivel de incultura y cuñadismo que tiene el lector medio de este blog.

Según tú, entonces, no se pueden comparar tarjetas gráficas NVidia contra AMD (Pascal VS Polaris), ni aplicaciones C contra Java, ni Windows contra Linux, ni... bueno, no sigo porque la cantidad de chorradas que se están escribiendo por aquí da para hacer un documental entero. Varios ingenieros de barra de bar que afirman que "son diferentes" sin tener ni puta idea de arquitectura de computadores. Y ya está, y os quedáis tan anchos. Seguro que sóis los mismos que seguís afirmando que la fotografia móvil no vale para nada, que la informática es el futuro y otros clichés propios de gente que vive en las ideas de listillos de hace diez años. Pues lo lamento, pero repetir los mismos dogmas sobre la informática año tras año, te deja cada vez más en evidencia.

Os toca aprender nuevas frases para hacer creer a vuestros familiares en la cenas de Navidad que sóis los que más sabéis de tecnología. Hoy en día, hasta cosas como las extensiones de virtualización están presentes en la arquitectura ARM.

Que los procesadores ARM cada vez son más potentes es un hecho, y no es descabellado pensar que esta arquitectura se siga desarrollando en el futuro y a medio-largo plazo consiga meterse en el sector de los PC. Eso sí, lo de utilizar un SO orientado a móvil en PC, sí que me parece una chorrada como un templo, sabiendo que el uso de ambos tipos de dispositivos es totalmente distinto.

Antes de OSX Apple hizo pruebas de su sistema en Intel, así que estoy seguro que tiene OSX para sus procesadores ARM desde hace mucho tiempo, ahora vete a saber cuanto tardarán en sacarlo o si lo usaran algún día.

De hecho OS X era RISC hasta no hace tanto, y teníamos aplicaciones compiladas para PPC y X86 al mismo tiempo.

Voy más lejos, el kernel xnu es compatible a día de hoy con arm (con código publicado). Salvo aplicaciones que tengan optimizaciones hechas en ensamblador o características de OpenGL no compatibles, se supone que todo lo demás debería ser compilar y punto.

Lo mínimo que se puede decir de tu teoría de que hay algún OSX que funciona sobre A8 es que tiene una base sólida.

Me has hecho mirar y todo ^^
Según veo en la documentación de apple lo que soporta es openGL ES 3.0, y openGL tiene instrucciones que no tiene openGL ES, si quisieses usar una de esas instrucciones en openGL cuando vaya a compilar el programa (las gráficas compilan los shaders en tiempo de ejecución) tiene que fallar. Peor aún si no es en la compilación el shader.

Lo que pase a partir de ahí dependerá de lo bien hecho que esté el programa.

PD: Otra cosa es como de complejo sería portar openGL completo.

Dentro de OpenGL tienes varias versiones y no son pleanemente compatibles entre ellas, por ejemplo openGL 3.1 es compatible con OpenGL 3.0 pero openGL 3.0 no lo es con todo lo que tiene 3.1.

OpenGL ES es una versión reducida de OpenGL. El problema que se podría dar es que una aplicación (y esto puede ser desde el escritorio hasta un editor de videos) use algo de OpenGL que no esté disponible en OpenGL ES.

PD: La versión de OpenGL depende de la gráfica y los drivers de esta, si tu montas un android con un gráfica que soporte opengl 4.5 y los drivers adecuados tienes opengl 4.5 en android.

EDIT: Aunque yo me dedico a infraestructura, cloud y rendimiento (de esto me toca a hacer menos por desgracia) me gusta el tema de los gráficos generados por ordenador y he programado un poquito en opengl por hobby.

prueba a hacer un memcpy de una variable tipo int, por ejemplo en una arquitectura little endian y en otra big endian de un array de bytes o char.

Pero eso solo debería afectar a cosas a muy bajo nivel (nivel kernel a la hora de hablar directamente con el hardware) o si has hecho cosas mal y no has tenido esto en cuenta en el I/O.

Si tienes una cantidad alta de problemas de endianness, tienes un problema mucho más serio que los bugs, y es que tus programadores no son aptos.

PD: En un array de bytes no te afecta el endianness.

la pregunta es esto bajarias los precios de las mcbook?

LC, con el sistema de trabajo con archivos, ¿te refieres a una indexación estricta de ficheros de todo tipo (de un proyecto) en carpetas y subcarpetas?

Porque yo eso sí lo veo muy atrasado respecto a cualquier sistema de escritorio, pero con los "ejecutables" (ya sean archivos de fotografía, música, video, documentos) que se abren con su aplicación correspondiente y no necesitan librerías ni archivos complementarios, el sistema iOS tampoco funciona tan mal.

Y por que no optas por una tablet Windows? Ejemplo un Surface Pro.

Soy otro que pienso que Apple ya está probando cosas así hace mucho, ahora están experimentado con Big.little y según van mejorando sus Ax y Intel se prepara para fabricar ARM queda poco para ver la siguiente transición de macos.

Ojo que MS ya lo intentó y le salió mal, pero Apple tiene algo que MS no tiene, planificación y un buen equipo que va animaros desarrolladores a trabajar en modificar sus programas de X86 para programas universales.

Como el test se va a compilar en distintos procesadores, con distintos compiladores lo que se ejecuta no es el mismo código máquina pero hace lo mismo.

Al fin y al cabo a ti te da igual si te va bien o mal o por el procesador o por el kernel o por las librerías del sistema o por el compilador, a ti lo que te preocupa es el resultado final y eso es lo que miden estos tests, el cómputo de todo.

Ok, pero de ahí a aseverar que "tienen un rendimiento muy similar ambos procesadores" hay un trecho importante...

Y para que estan los benchmarks? es la única prueba independiente. Lo demás pueden ser subjetividades pero un benchmark es la objetividad pura.

Si el benchmark de Geekbench (no de Applebench) da que tiene un rendimiento similar, es que da un rendimiento similar.

La evolucion de los procesadores Arm ha sido bestial:

https://browser.primatelabs.com/ios-benchmarks
https://browser.primatelabs.com/android-benchmarks

Sobre todo en el caso de Apple a partir del a9 que pego un estiron enorme.

Yo no soy fanboy de Apple ni de Samsung (y sino mirad mi perfil y mis comentarios) pero al Cesar lo que es del Cesar.

Por qué? (no es una pregunta retórica es que no veo que tiene de malo o incorrecto decir que el rendimiento es similar)

Muy poca, Geekbench usa cargas de trabajo muy pequeñas las cuales caben en memoria cache, con lo que muchas partes sobre el procesador no se evalúan.

Por ejemplo la multiplicación de matrices,son multiplicar matrices de 512 X 512 en simple precision,con lo cual todo el procesamiento se hace en cache,un mal manejo de memoria puede disminuir el rendimiento de 10 a 20 veces,por que casi lo mas complicado de la programación de alto rendimiento es poner todos los datos al procesador aritmético-logico.

Otros Test de rendimiento pueden como SPEC duran horas de ejecución y usan GigaBytes de RAM para sus cargas de trabajo.

Al fin alguien que ve más allá de lo evidente y los cuatro tests de Geekbench.

Que pena que a estas alturas la gente esté más preocupada de la polémica que en pensar en lo que comentas.

No entendí lol.

Osea que, ¿mientras el procesador ARM aguante los mismos GB de RAM que el x86 todo está resuelto?

Pues si comparas el Geekbench con el Passmark u otros programas de benchmark veras que los datos son correctos. Geekbench no es una empresa de Apple si te refieres a eso.

De hecho en la página web de geekbench aparecen entre otros como empresas que usan Geekbench:

Microsoft, Intel, Amd, Dell, Hp, Mediatek,...

Ninguna, por eso este artículo... en fin... es una pajarada en al cabeza de alguien que ya leí la semana pasada y que aquí han replicado otra vez.

Y esto lo dices en base a?

i7 5960X 384 GFlops
GTX 1080 8.9 TFlops.

La GTX es 23 veces mas potente que el i7.

Ahora pon la GTX a hacer sumas de enteros y me lo cuentas.

exacto!!!!
y tiene el mismo sentido que comparar la potencia de un horno de leña de una panaderia con la de un motor de combustion de un camion o coche... aunque ambos utilicen el poder calorifico como fuente de energia.

El horno de leña produce energía calorífica y el motor de combustión interna energía mecánica y como residuo energía calorífica, la comparación es estúpida.

Ambas arquitecturas de procesador hacen cálculos y como residuo energía calorífica, la comparativa es lógica.

Hay otra y es más efectiva: ANDROID. Miren el performance del procesador Intel y compararlo con un Qualcomm o Mediatek. Allí hay mas conclusiones.

Yo no descartaría un ipad con teclado integrado, eso si que sería indecente.

hola,
cuando instale la primera version de linux en mi arcaico 486 (slackware 3.0) es probable que aun no hubieses nacido, asi que, tranquilo... he visto correr infinidad de sistemas operativos en infinidad de hardware.
Mi macbook PRO de 1800 euros de 2010 esta muerto de risa desde 6 meses despues de comprarlo por su pauperrimo rendimiento... ¿sabes porque? porque PARA NO HACER RUIDO Y GASTAR POCA BATERIA los ventiladores nunca pasan del 60%... al no pasar del 60% de velocidad, la grafica NVIDIA que lleva dentro, empieza a calentarse cosa mala... cuando lleva unos 15 minutos encendido en CUALQUIER programa que pida un minimo de rendimiento, LITERALMENTE te quemas las manos con su "estupenda" carcasa de ¿aluminio? ... el aluminio no se caliente, ni metiendolo en el horno a 200 grados (pero ese es otro cantar)... asi que, para que las soldaduras del micro, de la placa, de la grafica y demas cosillas que lleva dentro de esa carcasa-horno no se fundan y salten, lo que hace, tanto micro como grafica es bajar la frecuencia al 40-60%... con lo que el rendimiento se reduce en igual porcentaje.

Esto se puede arreglar, ¿sabes como? instalando un programa externo (programado por alguien de fuera de apple) que obliga a los ventiladores a funcionar al % que tu quieras. Para poder trabajar con el portatil, hay que poner los ventiladores al 100% (y aun asi se calienta cosa mala y baja frecuencias en segun que programas)... y ¡¡tachan!! ¿sabes que pasa al poner los ventiladores al 100%? que la bateria dura mucho menos y que parece que en vez de un portatil estas trabajando con un secador de pelo al maximo.

Pero tienes razon... el problema de la potencia de los macbooks se soluciono gracias a los discos SSD... pa mear y no echar gota hoyga

Entonces tu afirmación habla sobre lo bueno que son los discos SSD que montan los macs, y no lo que rodea al Macbook, en windows te voy a hacer un spoiler... los Mac rinden mejor que con osx.

Claro, porque un core m3 es lo mismo que un i7 4470

Me han sangrado los ojos, por FAVOR, revisa tus comentarios antes de publicarlos.

Google translate... Lo hizo de nuevo!!!!
😂

Y así como ARM da la licencia para su arquitectura, ¿quien la da para x86?