El Snapdragon 845 equivale a un Athlon II X3 450 o un Celeron N3450 en Windows 10

[jorge_kai]

El Snapdragon 845 equivale a un Athlon II X3 450 o un Celeron N3450 en Windows 10



Leemos en elchapuzasinformatico.com

<< Gracias al software de benchmarking de Geekbench ya podemos conocer cómo será el rendimiento del SoC Snapdragon 845 empleado para los equipos portátiles dotados del sistema operativo Windows 10, recordando que este procesador hace uso de una configuración de 8 núcleos basados en la arquitectura ARM que, según un desconocido equipo de Lenovo, llegará con un notable overclock de 2.96 GHz (vs 2.45 GHz), algo posible debido a que los portátiles ofrecen espacio más que suficiente para disipar el calor generado junto al uso de una batería de mucha mayor capacidad para compensar el drenaje a tal velocidad. Este equipo se vio las caras con el Asus NovaGO TP370QL, basado en el SoC Snapdragon 835 @ 2.21 GHz y ambos compartían 4 GB de memoria RAM. Gracias a Geekbench conocemos que el Snapdragon 845 alcanzó una puntuación de 1352 y 4280 puntos en las pruebas mono/multinúcleo, lo que se traduce en ser un 60%/37% más potente de forma respectiva. >>

fuente: elchapuzasinformatico.com

[jorge_kai]

https://elchapuzasinformatico.com/20...en-windows-10

Ir al link original: https://elchapuzasinformatico.com/2018/05/el-snapdragon-845-equivale-a-un-athlon-ii-x3-450-o-un-celeron-n3450-en-windows-10

[ismacom]

Pero ese Geekbench mide la potencia usando instrucciones RISC (ARM) únicamente o tb mide el rendimiento de las instrucciones CISC (x86-64)??

Porque si es lo primero, nada nuevo bajo el sol, de hecho recuerdo con mi, en su momento, novísimo Galaxy S3 que se decía era más rápido que un i3 de la época, pero claro porque el i3 no hacía uso de sus tecnologías avanzadas, y si se hacia una prueba que usase las instrucciones del i3, el S3 directamente no podía hacer la prueba.

Si, por el contrario, con algún tipo de emulación el Snapdragon 845 ejecuta todas las instrucciones que puede ejecutar un Athlon X3 o un Celeron N3450, sin ser éstos un referente en rendimiento de ningún tipo, entonces sí que consideraré esas pruebas un logro.

[carapapa]

auténtica chorrada de comparativa. No hay por donde cogerla

[liver]

Cuanto tiempo libre

[DaSound]

 Cita: Originalmente Escrito por ismacom

Pero ese Geekbench mide la potencia usando instrucciones RISC (ARM) únicamente o tb mide el rendimiento de las instrucciones CISC (x86-64)??

Porque si es lo primero, nada nuevo bajo el sol, de hecho recuerdo con mi, en su momento, novísimo Galaxy S3 que se decía era más rápido que un i3 de la época, pero claro porque el i3 no hacía uso de sus tecnologías avanzadas, y si se hacia una prueba que usase las instrucciones del i3, el S3 directamente no podía hacer la prueba.

Si, por el contrario, con algún tipo de emulación el Snapdragon 845 ejecuta todas las instrucciones que puede ejecutar un Athlon X3 o un Celeron N3450, sin ser éstos un referente en rendimiento de ningún tipo, entonces sí que consideraré esas pruebas un logro.

Ambos... está midiendo el rendimiento sobre Windows 10, por lo que está usando la traducción de instrucciones que Microsoft implementó y que minan el rendimiento. Sobre todo por el hecho de tener que pasar por la capa WOW64, que es la encargada de traducir las instrucciones CISC de 64bits a RISC 32bits... en efecto, aunque los porcesadores ARM sean de 64 bits, su juego de instrucciones es de 32bits siempre.

[MariaValero]

Creo que la compativa esta bien

[groche97]

No esta nada mal para estar virtualizado... Aunque me gustaría ver una comparativa tu a tu compilando cosas en linux y demás de forma nativa

[djtosby]

yo creo que es mas un amd sempron del 2005 porque aunque su arquitectura sea de 64bits no leveo futuro siendo parte de amd o intel en la competencia, teniendo en cuenta lo que sus mas altos procesadores pueden hacer

[DaSound]

 Cita: Originalmente Escrito por groche97

No esta nada mal para estar virtualizado... Aunque me gustaría ver una comparativa tu a tu compilando cosas en linux y demás de forma nativa

Ahí es donde lo daría todo... pero claro hablamos del entorno actual, en su Android natal ya hemos visto que el desempeño es mucho mejor.

Verdaderamente no es una virtualización, porque no hay abstracción entre el hardware y el sistema... es una traducción a bajo nivel del juego de instrucciones. El verdadero problema es un sistema que funciona a 64bits para procesadores CISC de 64bits con instrucciones de 64bits contra un procesador RISC con instrucciones de 32 bits. Encajar eso es un trabajo que se deja la mitad del rendimiento por el camino.

[alecrim]

 Cita: Originalmente Escrito por DaSound

El verdadero problema es un sistema que funciona a 64bits para procesadores CISC de 64bits con instrucciones de 64bits contra un procesador RISC con instrucciones de 32 bits. Encajar eso es un trabajo que se deja la mitad del rendimiento por el camino.

No lo entiendo. La anchura de las instrucciones me parece irrelevante, lo que sí debería influir es la anchura de los registros y buses de datos, pero las instrucciones ¿Qué más da su anchura? Como si son de 8 bits.

[DaSound]

 Cita: Originalmente Escrito por alecrim

No lo entiendo. La anchura de las instrucciones me parece irrelevante, lo que sí debería influir es la anchura de los registros y buses de datos, pero las instrucciones ¿Qué más da su anchura? Como si son de 8 bits.

¿Cómo que qué más da? daría igual en sentido inverso, pero traducir instrucciones de 64bits en 32 supone un trabajado... ¿en serio?... una instrucción de 64bits completa necesito ser diversificada en 2 de 32, incluso una instrucción que no va completa supone ser diversificada y desperdiciar una parte de los bits.

Absolutamente, es la pura base de la informática vamos... precisamente el cambio de arquitectura de 32 a 64 bits ha mejorado enormemente la computación, llevando el doble de información que un procesador es capaz de efectuar por ciclo de reloj... ¿cómo que da igual que sean de 8? es una barbaridad.

Si fuese un procesador de 64bits en un sistema de 32 entiendo que se deduce que 32bits entran en 64 sin problema, pero no al revés!!!!!

Precisamente los registros es lo que no importa, porque ellos están trabajando de forma normal, es la capa de traducción la que ha convertido las instrucciones de 64 a 32 y se la provee al procesador, que las almacena en los registros y las procesa.

[alecrim]

 Cita: Originalmente Escrito por DaSound

¿Cómo que qué más da? daría igual en sentido inverso, pero traducir instrucciones de 64bits en 32 supone un trabajado... ¿en serio?... una instrucción de 64bits completa necesito ser diversificada en 2 de 32, incluso una instrucción que no va completa supone ser diversificada y desperdiciar una parte de los bits.

Absolutamente, es la pura base de la informática vamos... precisamente el cambio de arquitectura de 32 a 64 bits ha mejorado enormemente la computación, llevando el doble de información que un procesador es capaz de efectuar por ciclo de reloj... ¿cómo que da igual que sean de 8? es una barbaridad.

Si fuese un procesador de 64bits en un sistema de 32 entiendo que se deduce que 32bits entran en 64 sin problema, pero no al revés!!!!!

Precisamente los registros es lo que no importa, porque ellos están trabajando de forma normal, es la capa de traducción la que ha convertido las instrucciones de 64 a 32 y se la provee al procesador, que las almacena en los registros y las procesa.

Eso sólo sucede la primera vez que se ejecuta el proceso. El código traducido a ARM queda almacenado en disco y las siguientes veces que se necesita ejecutar la misma rutina se tira directamente de ese código almacenado. El sistema ni se entera de cómo era ese código en x86, está ejecutando código ARM.

[DaSound]

 Cita: Originalmente Escrito por alecrim

Eso sólo sucede la primera vez que se ejecuta el proceso. El código traducido a ARM queda almacenado en disco y las siguientes veces que se necesita ejecutar la misma rutina se tira directamente de ese código almacenado. El sistema ni se entera de cómo era ese código en x86, está ejecutando código ARM.

¿Cómo? eso no va a ser así. Eso funciona así en la caché del procesador, y solamente para instrucciones esenciales, pero nunca las de cualquier programa por ejemplo.. ¿crees que en la nimia caché que tiene un SD845 vas a almacenar instrucciones de un Windows 10 corriendo apps de escritorio como para no notar la capa de traducción? Pues siento decirte que no.

Es más, la caché no ahorrará ni una sola traducción, porque para poder cotejar la almacenada en caché, primero tendrá que ser convertida, así que siempre vas a tener una pérdida de rendimiento ya que la traducción se hace siempre un nivel por encima.

[alecrim]

 Cita: Originalmente Escrito por DaSound

¿Cómo? eso no va a ser así. Eso funciona así en la caché del procesador, y solamente para instrucciones esenciales, pero nunca las de cualquier programa por ejemplo.. ¿crees que en la nimia caché que tiene un SD845 vas a almacenar instrucciones de un Windows 10 corriendo apps de escritorio como para no notar la capa de traducción? Pues siento decirte que no.

Es más, la caché no ahorrará ni una sola traducción, porque para poder cotejar la almacenada en caché, primero tendrá que ser convertida, así que siempre vas a tener una pérdida de rendimiento ya que la traducción se hace siempre un nivel por encima.

Es verdad que Microsoft habla de caché en la documentación, pero entiendo que es en su significado más genérico, no se refiere a la memoria caché del procesador. Todos los artículos que hablan del tema dan a entender que el código traducido se guarda en disco.