Portada
mis comunidades
otras secciones
#17:
#14 https://es.m.wikipedia.org/wiki/Video_2000
Aún no eres demasiado viejuno, jajaja.
Fue el intento de competencia al Betamax y al VHS, pero no se comió un colín..
Aún no eres demasiado viejuno, jajaja.
Fue el intento de competencia al Betamax y al VHS, pero no se comió un colín..
#8:
si se desarrollara bien el software no haría falta tanto procesador.... siempre vamos al límite. el acrobat reader (por poner un ejemplo) lleva tardando un minuto en abrir desde el primer pentium que tuve y las funcionalidades son las mismas
#6:
Nos ha jodido, y un X86-64 sin todas las dependencias de hace 40 años necesarias para la retrocompatiblidad seria mucho mas rapido y eficiente.
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.
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.
#16:
#10 ni de broma. Apple lleva años planeando el cambio a ARM. Solo tienes que ver como hay muchísimas aplicaciones que no funcionan nativamente todavia en osx, utilizan un interprete (como proton para linux).
No es recompilar, es cambiar el juego de instrucciones completamente, lo que viene siendo rehacer los programas vamos jeje
No es recompilar, es cambiar el juego de instrucciones completamente, lo que viene siendo rehacer los programas vamos jeje
Comentarios
si se desarrollara bien el software no haría falta tanto procesador.... siempre vamos al límite. el acrobat reader (por poner un ejemplo) lleva tardando un minuto en abrir desde el primer pentium que tuve y las funcionalidades son las mismas
#8 Hay otros visores mucho más ligeros, como este https://es.m.wikipedia.org/wiki/Sumatra_PDF
#8 no me creo que te tarde 1 minuto en un ordenador moderno
#8 Es bloatware pero el reader hace más cosas, firma documentos y seguro que alguna conversión de formatos o rollos de sincronización y cuentas online hace.
Los hay mejores? A todas todas.
#8 ssd
Nos ha jodido, y un X86-64 sin todas las dependencias de hace 40 años necesarias para la retrocompatiblidad seria mucho mas rapido y eficiente.
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.
#6 Yo quiero seguir usando CP/M en mi Ryzen 9
#6 dejó tirados a loa usuarios? Y Rosetta?
Espero que no sea como el Beta VS VHS
#1 Peor sería VHS vs 2000
#2 No entiendo la referencia a 2000. Que es 2000?
#14 https://es.m.wikipedia.org/wiki/Video_2000
Aún no eres demasiado viejuno, jajaja.
Fue el intento de competencia al Betamax y al VHS, pero no se comió un colín..
#17 No lo conocía. Pensaba que sólo había betamaz y VHS.
#22 https://es.wikipedia.org/wiki/Guerra_de_formatos_de_cintas_de_video
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.
#51 Nosotros teníamos VHS Así que yo podía alquilar todas las pelis que quisiera. Creo recordar, que en uno de los videoclubs del pueblo había una sección para citas Beta.
Así que Philips fue el de 2000. Fracasó estrepitosamente.
#17 yo probé uno. Era de cintas reversibles, cara a y cara b, y se atascaba bastante. De muy pequeño
#14 Jajaja, un adolescente tecnológico
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.
#27 No tan adolescente. Pero la verdad que no me acordaba para nada. Tenía un amigo que su padre tenía BETA y decía que era lo mejor (sobre todo porque era aficionado al vídeo). Así, que vi ambos formatos.
Pero el vídeo 2000 no lo había escuchado.
#32 Pues espera a oir hablar del LaserDisc... https://en.wikipedia.org/wiki/LaserDisc
#39 Lo conozco. Solo no conocía el 2000. Porque debió super minoritario y mi memoria lo ha borrado.
Seguro que dentro de unos meses lo volvéis a mencionar y no me volveré a acordar.
#40 Allá por el año 86 el objeto de tecnología de consumo de moda era el reproductor de vídeo... de aquellas todos mis amigos que tenían uno o era VHS o Beta, menos uno, y el pobre era el paria porque no podía alquilar nada en el videoclub... qué tiempos.
#39 en mi casa había uno. Solamente teníamos documentales
#27 Y de ahí, pasamos al Betacam.
#27 Las cintas de 240 minutos eran en Long play que salió años después.
#1 en la que salimos perdiendo los consumidores europeos por que eligieron las empresas, cosa más difícil hoy día.
#5 creo que el porno eligió no ? O esto fue con el bluray vs dvdHD ?
Tambien recuerdo la guerra dvd-R y dvd-R (almenos en grabación)
#37 ufff... si fuese por el porno, con los 60 minutos de Betamax original tendríamos mas que suficiente
x86 es muy complejo por que tiene muchas implementaciones y funcionalidades....
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.
#45 Se te olvida la mayor diferencia, que es una implementación de código abierto: "Intel, AMD y ARM se basan en IP propietaria y las empresas venden y/o licencian sus productos. RISC-V es una especificación y una plataforma abiertas; no es un procesador de código abierto. Existen núcleos RISC-V de código abierto, pero también hay núcleos con licencia comercial." https://www.microcontrollertips.com/risc-v-vs-arm-vs-x86-whats-the-difference/
#52 no cambiara cuando le metan mano, pero lo veo completamente para una solucion gubernamental, que la UE empiece a trabajar en ello, me parece genial, pero seamos realistas hasta dentro de 5 años no tendremos algo competente y entonces aun tendra alternativas mas eficaces con total seguridad.
#76 El tema de tener que pagar licencias, conseguir permisos hace muy complicado y ralentiza el desarrollo de estos proyectos. Ahora estará por ver, pero en el mundo del software, está claro que Stallman tenía razón y el software propietario sigue dominando en la administración pero en el mundo empresarial el Opensource gana de lleno.
Sólo apuntar ésto: "Linus Torvalds carga contra Intel: «Espero que AVX512 tenga una muerte dolorosa» - https://www.muylinux.com/2020/07/13/linus-torvalds-contra-intel/
#26 ¿Tu lees los comentarios enteros?
"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.
#29 Realmente no entiendo tu comentario, ¿con qué crees que debería ser compatible Apple que a día de hoy no lo es? ¿Con Windows?
#29 los procesadores Ax ganan por goleada en rendimiento a los equivalentes Qualcomm o exynos de su respectiva generación
Si quisieras fabricar un PC a dia de hoy, escogerías un X86/64; si por el contrario quisieras fabricar un ordenador, podrías escoger RISC-V, ARM, o cualquier otra mierda.
#79 Se me olvidó comentar que claro, apple en su software se lo guisa y se lo come todo: si hace falta cambiar todo el sistema operativo, librerías de desarrollo y las aplicaciones de la casa para aprovechar una instrucción única de su hardware, se hace. Eso es en lo que generalmente consiste la diferencia entre aplicaciones genéricas que se notan torpes o lentas en otros sistemas (android, windows, etc) respecto a los equivalentes de apple, la optimización y adaptación del software al hardware.
No entiendo porque Apple, teniendo todo el dinero del mundo no hace su propio procesador desde cero, si su filosofía es tener su propio ecosistema, no se porque se me viene a la mente Xerox y BSD
#4 Haré mi propio procesador. ¡Con casinos! ¡Y furcias!
Ya lo están haciendo:
https://es.wikipedia.org/wiki/Apple_M1
#4 Porque da más dinero usar la arquitectura de otros. No se pueden poner a diseñar cada componente desde cero. Creo que la gente tiene un poco endiosada a Apple. No se os olvide que lo más importante en Apple es su departamento de marketing.
#9 Basado en la arquitectura de otros.
#12 Eso es como decir que Intel y AMD es x86, es exactamente lo mismo
Apple ha diseñado hasta su propio socket pero bueno, como dice #11 es solo marketing y nunca han innovado en nada, en fin...
#15 es que no es x86? En su gama de procesadores claro
#15 Yo no he dicho que solo sea marketing. Solo que es lo más importante de esa empresa. De hecho el m1 es lo primero que saca Apple en décadas que de verdad ofrece algo más que la competencia a la que dobla en precio.
#23 Vamos a ver, M1 es para ordenadores de sobremesa y portátiles, los Ax son los procesadores para móviles y tablets, y lleva más de 10 años con su propios diseños en procesadores y tarjetas gráficas, así que eso que es lo primero que saca Apple en décadas, pues como que vas un poco descaminado
#15 Usa la arquitectura y el juego de instrucciones de ARM.
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
#15 No tengo nada de Apple ni lo quiero, pero decir que Apple no innovo en nada... no se, como que suena a incorrecto.
#9 No es desde cero, han cogido una arquitectura ya existente ARM, (sí, llevándola a un nivel sin precedentes) y ahora se han dado cuenta que ser el mejor con tecnología de otros no basta cuando esta puede cambiar de dueños de no mucho de su agrado el día menos pensado.
#9 m1 es ARM
Hoy día un ordenador RISC-V te sale por 600$ con la potencia de un x86 que te cueste 400$ ... el precio no lo es todo pero cuenta.
SiFive HiFive Unmatched
https://architecnologia.es/risc-v-pc
ASUS ROG Strix H470 I Gaming + 16 Gb Ram + intel i3-10105
https://rog.asus.com/motherboards/rog-strix/rog-strix-h470-i-gaming-model/
Los desarrolladores de software tienen que estar encantados. Una nueva plataforma PC que se une a arm.
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
#56 encontré un vídeo corriendo Ubuntu. Joder menuda castaña por 600€ peor que una Raspberry:
ira para largo te comprarias un pc nuevo se quedaria obsoleto y todavia latecnologia RISC-V estaria todavia por consolidarse
Para pasado mañana puede. Para mañana lo más probable es que no. Y para hoy en día, ni de coña.
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).
#3 No entiendo lo del software. Basta con recompilar a la nueva arquitectura. A Apple pasar el ecosistema de x86_64 a ARM, incluso con terceros, le ha costado unos meses.
#10 ni de broma. Apple lleva años planeando el cambio a ARM. Solo tienes que ver como hay muchísimas aplicaciones que no funcionan nativamente todavia en osx, utilizan un interprete (como proton para linux).
No es recompilar, es cambiar el juego de instrucciones completamente, lo que viene siendo rehacer los programas vamos jeje
#16 Recompilar es cambiar el juego de instrucciones.
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.
#10 Meses, pero aplicando el know how de 2 migraciones de arquitectura (Motorola -> PowerPC -> Intel), recuerda que el invento de Rosetta fue el que usaron en la segunda.
#10 Si tienes un software relativamente sencillo y diseñado para ser genérico y portable, quizá baste con eso. Pero date cuenta de que con la arquitectura no sólo estás cambiando las instrucciones de nombre como quien dice, es que muchas cosas que puede hacer un x86 o un arm actual son imposibles o casi mejor, impracticables, con un risc-v. No es simplemente "en lugar de ejecutar una instrucción, ejecuto las necesarias para definir un algoritmo que emule su comportamiento", que también aunque ejecutar ese algoritmo emulado sea 1000 veces más costoso, es que estamos hablando de arquitecturas, hay cosas que Risc-V simplemente no puede hacer a día de hoy (por ejemplo, ejecutar máquinas virtuales y si me apuras contenedores, porque no tiene extensiones de virtualización estandarizadas; creo que se estaba trabajando en ello; se puede hacer sin esas instrucciones, pero tendrías que modificar los hipervisores actuales que tiran de esas instrucciones, y todo eso... ¿a qué costo?).
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.
#10 Para recompilar necesitas el código fuente. Muchos profesionales dependen de un software cuyo proveedor sólo te proporciona en formato binario, así que no pueden cambiar de arquitectura.
#3 Y ahora explicalo para que los ignorantes en el tema nos enteremos.
#62 Te voy a poner un ejemplo.
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 el papel, era muy bueno y funcionaba muy bien. Tanto que el famoso M1 de apple, más de un lustro después, reinventó la rueda y hace lo mismo (con algunas mejoras arquitectónicas de ARM). ¿Por qué el M1 es maravilloso y el proyecto fusion fracasó estrepitosamente? pues por el software, simplemente por el software. AMD no tenía fuerza, dinero y programadores suficientes como para adaptar el software y marcar una diferencia real con la competencia. Lo que terminó pasando es que a la vista de los potenciales clientes, su procesador era más débil, iba más lento, consumía más y era más caro (hay más factores por medio, claro, por ejemplo, que todo el software benchmark del mercado estaba optimizado para Intel, que ejercía mucha presión en el mercado y usaba malas tácticas para seguir manteniéndolo; AMD fabricaba con nodos más antiguos, sacaba menos chips por oblea, tecnología que no le permitía minimizar los consumos, etc... apple hoy en día tiene "secuestrados" por contrato los nodos más modernos de fabricación que hay hoy en día para su uso exclusivo por lo que puede fabricar chips más pequeños, frescos, eficientes y baratos al poder fabricar más cantidad por oblea que la competencia).
Volviendo al tema que nos trae, Risc-V es una arquitectura básica (extremadamente básica, justo tiene las mínimas y más simples instrucciones necesarias) que compite con arquitecturas complejas (las instrucciones ARM que son simples, ya se dividen en hasta cuatro microinstrucciones más simples, las instrucciones x86 ya son muchísimo más complejas y pueden hacer cosas muchísimo más complejas en comparación). Para que Risc-V funcione, tiene que acompañarse con extensiones (estándares o hechas a medida para alguien) que hagan cosas particulares. Eso implica, que los programas han de diseñarse pensando en esas extensiones más que en las instrucciones base. Cuando tienes que adaptar el software para que rinda adecuadamente ya es un esfuerzo extra, habrá quien esté dispuesto a hacerlo y habrá quien prefiera no atarse a estrellas fugaces y seguir el camino de siempre, que es sencillo, cómodo, super probado y comprobado y que por ser de uso masivo, es barato.
Risc-V por lo tanto, tiene que desarrollar una serie de extensiones útiles, tienen que ser buenas, tienen que estandarizarse, tienen que ser equivalentes a lo que ya usen otras arquitecturas (e incluso así, al cambiar toda una arquitectura completa, habría que cambiar más cosas... la disposición y cantidad de cachés, su funcionamiento, la forma en que se ordenan y leen las instrucciones... todo importa a la hora de conseguir rendimiento y todo depende muy mucho de la arquitectura), todo ello tiene que ser rentable en cuanto a implementación (o sea, tiene que dar chips al menos igual de potentes y al menos igual de eficientes, tienes que poder fabricarlos a un precio competitivo y además aportar algo extra de valor; en este caso, la licencia gratuíta podría serlo o la garantía de que el diseño está libre de puertas traseras y esas cosas). Aparte de eso, el software tiene que adaptarse para aprovechar todas estas características (si no usa esas extensiones, será rematadamente lento e ineficaz, estarías malgastando la inversión), y el software siempre tarda en hacerlo (primero tienes que desarrollar herramientas y librerías y sobre ellas adaptar los programas, etc). Y todo eso tardará bastante, no se aceptará de manera masiva y rápida, pasará al menos un lustro antes de que sea una opción (ARM llevan lustros desbancando al x86 y aún no han conseguido llegar a ello, y eso que si tienen mucho software adaptado; quizá a partir del M1 empiecen a llegar competidores serios).
#68 buenísima explicación, muchas gracias
Muy interesante, sí
A x86 lo llevan matando desde que nacio
¿Volvemos a apostar por arquitecturas risc? ¿Como los powerPC de los 2000?
#33 la arquitectura POWER en general es muy potente.
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.
#46 tuvo con v.
#50 mi autocorrector en el teléfono dice que le da igual, porque no me lee.
Y mis dedos, que porque las ponen juntas!
Gracias!
#46 Aquí uno. Viniendo de mucho Linux en PC montado por mi mismo, aquellas estaciones Alpha parecían tanques invencibles ejecutando un sistema operativo familiar pero diferente que se las zampaba todas: recuerdo cómo me llamaba la atención que la interfaz gráfica (mwm a pelo, ni tan siquiera CDE) seguía respondiendo cuando la carga del sistema andaba disparada. De todas formas, ojo que igual lo que estamos echando de menos no son prestaciones concretas sino la sensación de "esto no es lo normal" que había por aquel entonces. ¿Qué pasos crees que se han dado demasiado rápido? ¿Qué tenía que haber pasado?
#73 hasta hace unos 20 años, un proyecto de IT tenía partes definidas, equipos estructurados, que usaban lenguajes maduros y framework y herramientas completas, probadas y bien documentadas.
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.
Y ese tipo de procesadores quien los va a fabricar? Intel, AMD no se si estan por la labor.
#44 si hay colgados que fabrican el cerebras-ws2 y lo venden con garantías, hecho por TSMC, cualquier cosa más pequeña vale.
#44 Intel andaba a vueltas con sifive para hacer de partner ya que les interesa está tecnología para hacerle la competencia a arm.
https://www.anandtech.com/show/16777/intel-licenses-sifives-portfolio-for-intel-foundry-services-on-7nm
De hecho estaban viendo para comprarla y fabricar sus chips
https://www.tomshardware.com/news/intel-offers-dollar2-billion-for-risc-v-startup-sifive-bloomberg
No, Jim Keller no va a pasar los Exynos a la arquitectura RISC-V, tampoco Apple se lo va a plantear a corto/medio plazo, están en plena migración con ARM y va a durar años... Los movimientos que se ven parecen más bien amagos ante la próxima autorización de la compra de ARM por Nvidia, si es que es autorizada. Que Apple busque alternativas no significa que hallan tomado ninguna decisió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)
Es un desastre todo. Cada uno defendiendo lo que le apetece, arm no deja de ser risc (esta es mi defensa jeje)…y al final, parece que dependemos más de poder poner más transistores por cm2 que la arquitectura en sí
Si quisiera fabricar un PC escogería sin duda un Zilog Z80.
Seguramente si a día de hoy fabricaras un pc risc, te comerias un colín a 2 manos
A dia de hoy, salvo que seas AMD, Apple, intel o alguna de esas, como tengas que limitarte a las implementaciones de referencia de esa u otras, no esperes mucho rendimiento por watt. Y claro que el ISA no marca eso, pero es que el funcionamiento interno si, y si coges algo que no sea de dos o tres fabricantes... vas a crear algo mas o menos usable pero a medio camino de ser mas un juguete que un PC.
#7 Habana, Graphcore, Google o Amazon con el Trainium tiene juguetes con sus ISAs, y precisamente por rendimiento.
#13 Desconozco la mitad de esas, pero es que el ISA, que marca un poco la compactacion/uso de memoria y hace mas o menos simple la decodificacion y los compiladores, si, no te va a marcar mucho el rendimiento. Pero si tiras de reference implementations de un RISC-V u otras cosas por ahi, sin ir a diseños mas brutos de, no se, no mas de 10 empresas en el mundo, no creo que puedas tener un buen performance per watt. Que igual sigue sirviendo, como sirven muchas cosas, pero no creo que sea un PC "apetecible".