El futuro de los PCs es cada vez más incierto, y es que mientras que la arquitectura x86 ha ralentizado sus avances, ARM ya se ha postulado como un serio candidato, por no hablar de RISC-V, que es que la que menos ruido hace pese a la que parece ser la futura ganadora.
|
etiquetas: futuro , arquitectura pc 
Ni la arquitectura, ni las herramientas están a la altura necesaria para poner a Risc-V por encima de otras arquitecturas, salvo casos y cosas muy muy puntuales no vale la pena actualmente y a corto plazo en el futuro tampoco. Eso no quita que sea muy jugosa para invertir y desarrollarla y que si que tenga mucho futuro.
Insluso si lees el artículo lo deja claro: es la más fácil con la que trabajar desde cero desde el punto de vista del ingeniero de hardware, no la mejor, no la más práctica y ya si nos pasamos al punto de vista del software... (y sin software, el mejor hardware no sirve para nada).
El problema es la compatibilidad con todo el software que hay hoy en dia y el hecho de dejar tirados a los usuarios, como hizo Apple cuando paso de RISC a X86, o con Catalina que se pela cualquier app que no sea de 64bits.
Ya lo están haciendo:
es.wikipedia.org/wiki/Apple_M1
#9 Basado en la arquitectura de otros.
Apple ha diseñado hasta su propio socket pero bueno, como dice #11 es solo marketing y nunca han innovado en nada, en fin...
No es recompilar, es cambiar el juego de instrucciones completamente, lo que viene siendo rehacer los programas vamos jeje
Aún no eres demasiado viejuno, jajaja.
Fue el intento de competencia al Betamax y al VHS, pero no se comió un colín..
Los movimientos de impulso de la arquitectura RISC-V vienen de China y parece ser que también vendrán de Europa, es a nivel gubernamental no empresarial. Lo de Europa es más bien una cosa desesperada ante la total dependencia de fuera, en cambio lo de China sí es para tenerlo en consideración, lo tienen todo para dar la vuelta al mercado (con o sin el mercado EEUU donde serán paulatinamente baneados)
Edit: perdón #11 y #12 he ido con retardo en mi comentario.
El 2000 fue el pagafantas del vídeo. Mala calidad, pero cintas de doble cara que duraban horas, ...
... ejem, yo tenía cintas de 240 minutos en VHS.
Y por cierto, cuando entré en 1995 en un estudio de vídeo, y me pusieron cintas U-Matic en un reproductor de tropecientos cabezales, supe que ni VHS ni Betamax estaban preparados para lo que venía. Más modernos, pero una calidad de mierda.
"lo primero que saca Apple en décadas que de verdad ofrece algo más que la competencia a la que dobla en precio"
Eso es distinto que decir que es lo primero que saca Apple.
Apple lleva... desde siempre... con su propio ecosistema, entre otras cosas, porque hacerse mínimamente compatible con cualquier otro sistema les jodería esa sensación de exclusividad en la que se basa su marketing.
En los dos últimos comentarios me has discutido algo que no he dicho... a ver en este.
Pero el vídeo 2000 no lo había escuchado.
Tambien recuerdo la guerra dvd-R y dvd-R (almenos en grabación)
Seguro que dentro de unos meses lo volvéis a mencionar y no me volveré a acordar.
Los hay mejores? A todas todas.
Vamonos a x86_64
Metamos las funcionalidades que necesitamos a x86_64
x86_64 es muy complejo por que tiene muchas implementaciones y funcionalidades....
Vamonos a Arm...
Metamos las funcionalidades que necesitamos a Arm...
Arm es muy complejo por que tiene muchas implementaciones y funcionalidades...
Vamonos a RISC-V y le metamos las funcionalidades que necesitamos...
No se de que me suena esto.
El problema es que tubo enfrente algo mucho más barato; Linux con x86_64.
Y ahí se acabó todo.
El commodity hardware con GNU Linux se cargó a UNIX y el hardware donde corría, con muchas otras cosas con ello.
Aviso: Llevo 20 años con Linux. He hecho carrera y ganó dinero con ello.
Pero algunos pasos se han dado demasiado rápido. Y no es culpa de Linux, sino como se ha usado
Si alguien aquí tubo jamás la suerte de trabajar con Tru64/TruCluster y el AFS, sabra a que me refiero.
Es una lastima que se perdiese todo eso.
Cuando llegaron al mercado de España los vídeos, valían una buena pasta, ¡Ay de los pobres que escogiesen el 2000!; el Beta tampoco era una buena elección para el mercado doméstico, entre otras cosas por la poca proporción de películas que había en los videoclubs.
De todas maneras, eso fue unos años después, cuando llegó la guerra de los formatos, en muchas familias de clase media u obrera, aún estábamos pagando los plazos del primer televisor a color.
SiFive HiFive Unmatched
architecnologia.es/risc-v-pc
ASUS ROG Strix H470 I Gaming + 16 Gb Ram + intel i3-10105
rog.asus.com/motherboards/rog-strix/rog-strix-h470-i-gaming-model/
Así que Philips fue el de 2000. Fracasó estrepitosamente.
Y mis dedos, que porque las ponen juntas!
Gracias!
Básicamente ahora culaquier software profesional tiene que tener versión Windows, Linux y iOS combinados en plataformas hardware x86, arm o riscV.
Para pegarse un tiro.
#53 Lo que no encuentro por ningún lado es datos comparativos de velocidad de procesamiento
www.anandtech.com/show/16777/intel-licenses-sifives-portfolio-for-inte
De hecho estaban viendo para comprarla y fabricar sus chips
www.tomshardware.com/news/intel-offers-dollar2-billion-for-risc-v-star
Por supuesto tiene optimizaciones propias, del mismo modo que Qualcomm añade optimizaciones y cosas propias a sus Snapdragon, haciendo que estos sean mucho mejores que los de Mediatek, los de Samsung (Exynos) o los Kirin de Huawei, pero la base es el diseño y el I+D de ARM.
AMD al principio usaba los diseños de Intel, no empezó a añadir cosas propias hasta los K5. Y el x86-64bits es totalmente una invención de AMD que licenció a Intel. Intel originalmente quería abandonar el x86 en favor de los Itanium, que resultaron ser un fracaso
m.youtube.com/watch?v=bqekGqREf9k
A Apple no le ha costado unos meses. Apple partía de un software que ya había desarrollado en su día y que tuvo que adaptar, tanto portar su software para que ejecute nativamente como el traductor para ejecutar software no nativo (el proceso internamente duraría años, aunque a nosotros nos parezca que todo estaba ya listo). Para portar su software de manera nativa tuvo que desarrollar o adaptar herramientas básicas (recrear los runtimes, compiladores, debugueadores, etc), como hacen su software muy optimizado y pegado a su hardware tienen que modificar todas las partes más dependientes del mismo en sus programas (por ejemplo, a su sistema operativo habrán tenido que reescribirle partes críticas, a las librerías que tiran de recursos del sistema, a los programas que usan características del sistema que ahora funcionan de manera diferente habrán tenido que incorporarles excepciones o manejar esos nuevos comportamientos, etc) y muchas más cosas. Parece sencillo (y más cuando te dicen que ya ha hecho esto otras veces) pero no lo es, lo único que la experiencia ayuda a diseñar hojas de ruta y transiciones de manera más eficiente; si esto lo intentara hacer otra empresa y partiendo de cero, se habrían pegado un castañazo de órdago.
Entiendo que no es moco de pavo cambiar de arquitectura, pero a nivel compilación, es usar un compilador que genere código de máquina de otra arquitectura.
AMD diseñó su proyecto fusión con la idea de tomar una CPU X86_64 (un procesador) y unirla con una GPU (una gráfica) de la casa, de manera que pudieras tener un chip que aprovechara los elementos comunes de ambos (abaratando precio de no duplicar recursos y poder aprovechar ese espacio para añadir más unidades de computación, o lo que se quisiera) y además se viera potenciado por una serie de características novedosas en ese entonces, un híbrido que pudiera hacer frente a los procesadores de Intel con garantías.
La idea base y uno de los pilares de fusion era: si tenemos una gráfica capaz de acceder a la memoria del sistema sin coste ni penalización alguna, podemos acelerar muchísimo operaciones que ahora mismo son muy lentas (las transferencias entre memoria del sistema y memoria gráfica tradicionalmente eran muy lentas primero por cuestión de saturar buses de sistema moviendo datos -el ancho de banda era muy limitado- y luego porque tenías que hacer copias de los mismos varias veces, resultando el proceso muy ineficiente; por poner un ejemplo probablemente irreal, si modificabas dinámicamente una textura tenías que copiarla de memoria de vídeo a memoria de sistema, retocarla y luego volver a copiarla de memoria de sistema a memoria de video... con el proyecto fusión se trabajaba directamente en la memoria del sistema, no habiendo transferencias y pudiendo acceder directamente a ella, sin copias, sin saturar buses), podemos hacer computación sobre grandes cantidades de datos con un mínimo esfuerzo (mientras la parte de CPU hacía sus cosas, la GPU podía realizar cálculos y computación sobre conjuntos de datos; al estar estos en memoria accesible, una vez más, no habían copias, acelerando muchísimo todo).
En resumen, para poder aprovechar estas características especiales y aprovechar la eficiencia de estos procesadores, hay que programar adecuadamente para ellos. La esperanza de AMD era básicamente que se universalizara el uso de OpenCL en aplicaciones de todo tipo, donde su fusión podía marcar una diferencia importante con la competencia, cosa que no sucedió. Y es que no vale usar código genérico, porque el código genérico fuerza al sistema a hacer copias entre regiones de memoria porque si no, no funcionaría en el resto de hardware del mercado, y perdiendo así todas las ventajas que pudiera tener este hardware específico (esto es un ejemplo para ilustrar por qué adaptar el software es tan importante).
Todo esto, sobre… » ver todo el comentario
Entonces si algo no funcionaba, se arreglaba o se extendía.
Ahora el paradigma es otro. Si no funciona, no te partas los cuernos, usa un XaaS que te haga la función y tira.
O si un framework se queda corto... Cambio de framework! En mitad de proyecto.
Documentación? L o L
Readme mal estructurado si tienes suerte.
He tenido peleas malas con jefes de proyecto por querer documentar bien.
...
Todo esto en parte es porque la máquina ha dejado de ser importante, el sistema operativo ha dejado de importar también, porque ambos son baratos y además cualquier desarrollador de medio pelo ahora te puede hacer se sysadmin ( L o L ), aunque no haga más que reusar una plantilla de aws o gcp.
...
Que se ha perdido?
El trabajo cuidado, la exactitud, el entregar proyectos acabados, donde una versión 1.0 tenga todo lo que necesita el servicio.
...
Es todo así de malo? En absoluto. Pero la mayoría de cosas si.
Antes teníamos menos pero de mayor calidad. Ahora es difícil encontrar nada buen lo entre tanta paja, tanto bandolero del software y tanto inutil pagado.