#59 en las sociedades socialistas era igual ,los viejos edemas no tenian nada
El fenómeno tiene hasta canción "oficial"...
#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"
Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#19 Pero un chip RiscV debe funcionar en todos lados, otra cosa es que uses esas mierdas o las ignores. RiscV no es ARM (que licencia y olvida), la filosofía es "comparte la base tal cual, estándar y sin tocar y funcionarás en todos lados; y las mierdas que quieras añadir por tu lado, irán por separado". ¿Recuerdas que habían ordenadores pentium soportando mmx y otros que no? pues el software o aprovechaba mmx o no, pero todo seguía funcionando (más o menos lento, pero funcionaba). Con ARM esto no es así, tienes que compilar con compiladores diferentes y generar código diferente, a veces tan sustancialmente diferente que no funciona en los dispositivos ARM de la competencia o en los tuyos propios de meses atrás, las diferencias llegan a esos extremos.
#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.
#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"
Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.
En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.
#20 ¿Y de qué van las mejores prestaciones? ¿de ocultarlas bajo las soluciones de siempre (añadir cosas que aceleren otras cosas por hardware y optimizar el software propio para exprimirlas, aunque el rendimiento con el software de terceros apeste hasta que les sueltes pasta o les convenzas de que optimicen específicamente para ti) y pagar más para tener mejores tecnologías de fabricación para poder luego decir que su solución es mejor que la de los demás? ¿como lo de presumir que las arquitecturas ARM son mejores y consumen menos cuando se fabrican en los mejores nodos de fabricación y con técnicas de fabricación específicas para lograr poco consumo porque su nicho de mercado es el móvil, servidores flojitos pero con "high core count" y como mucho portátiles pero que escalan horriblemente mal?
Te voy a poner un ejemplo: ¿Sabes quién fue la primera arquitectura que apostó por muchísimos cores ligeros y poco potentes para atacar el mercado de los servidores web y java? la sun SPARC (en particular, a partir del UltraSparc T2 -8 cores con 8 hilos cada uno, hasta 64 threads simultáneas- y T3 -16 cores con 16 hilos cada uno, 128 hilos, que se dice pronto-) . Y tuvo relativo éxito, pero al final el mercado buscaba cosas más generalistas y potentes y murió. ¿Sabes qué otra arquitectura intentó algo similar? bulldozer de amd. Y falló en parte por estar fabricados con tecnología que intel podía barrer tranquilamente (aunque con gran capacidad multitarea, poco potentes y consumiendo más que los procesadores de intel). Y ojo, que hablamos de la tecnología que movió la play4.
Justamente ahora AMD tiene soluciones que aunan todo y por eso están comiéndose ciertos mercados: tienen cpus con gran cantidad de capacidad multiproceso, con muchísima potencia cada núcleo individual y con un consumo contenidísimo y mucho menor que el de los productos de sus rivales en sus mismas gamas y tecnologías de fabricación equivalentes (si, incluso comparados con apple... sácalos de productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).
Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).
Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.
#52 Son cosas diferentes y atacan ámbitos diferentes. MS y otras han tenido que asociarse para permitir usar patentes en desarrollos de software libre porque se dieron cuenta de que estaban pisándose su propia prosperidad con eso (dado que las compañías propietarias hacen mucho dinero con el software libre y demandarse unas a otras por cosas que usan todas al final era una tontería).
#6 Lo primero y más importante: Es estándar.
Cada dispositivo ARM es modificado por cada empresa para añadir sus mierd... cosas, tienen software de arranque distinto, etc. Hacer un kernel ARM universal (como podría ser un x86 o un riscv) es imposible ahora mismo.
RISC-V ha tomado un camino diferente: extensiones (estándares y no estándares). RISC-V base es soportado por todos y luego cada uno soportará las extensiones que necesite. Si por lo que sea, añade extensiones no estándares, no afectaría a un kernel que soporte la base de RISC-V, simplemente no las aprovecharía.
Además, las extensiones tratan de pensarse, madurarse y estandarizarse en comité para que sean útiles, bien diseñadas y permitan añadir un valor importante al conjunto de la arquitectura. Lo contrario que ARM, vamos.
#17 nada legal impide que mierdas sean mucho peores en risc-v y por nada es que los que están poniendo dinero precisamente es la característica que están vendiendo, modifico mi IP core para vendertela y hacer el sistema incompatible con otros clientes a los que les vendo mi IP, lo que viene a ser «configuracion y personalizacion».
#19 Pero un chip RiscV debe funcionar en todos lados, otra cosa es que uses esas mierdas o las ignores. RiscV no es ARM (que licencia y olvida), la filosofía es "comparte la base tal cual, estándar y sin tocar y funcionarás en todos lados; y las mierdas que quieras añadir por tu lado, irán por separado". ¿Recuerdas que habían ordenadores pentium soportando mmx y otros que no? pues el software o aprovechaba mmx o no, pero todo seguía funcionando (más o menos lento, pero funcionaba). Con ARM esto no es así, tienes que compilar con compiladores diferentes y generar código diferente, a veces tan sustancialmente diferente que no funciona en los dispositivos ARM de la competencia o en los tuyos propios de meses atrás, las diferencias llegan a esos extremos.
#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.
#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.
Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html
"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"
Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.
Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html
Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html
#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.
La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.
#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?
RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."
Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...
No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...
Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes
#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/
La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado:
#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.
"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."
¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...
#17 yo hablo de mejores prestaciones no de filosofía tecnología
#20 ¿Y de qué van las mejores prestaciones? ¿de ocultarlas bajo las soluciones de siempre (añadir cosas que aceleren otras cosas por hardware y optimizar el software propio para exprimirlas, aunque el rendimiento con el software de terceros apeste hasta que les sueltes pasta o les convenzas de que optimicen específicamente para ti) y pagar más para tener mejores tecnologías de fabricación para poder luego decir que su solución es mejor que la de los demás? ¿como lo de presumir que las arquitecturas ARM son mejores y consumen menos cuando se fabrican en los mejores nodos de fabricación y con técnicas de fabricación específicas para lograr poco consumo porque su nicho de mercado es el móvil, servidores flojitos pero con "high core count" y como mucho portátiles pero que escalan horriblemente mal?
Te voy a poner un ejemplo: ¿Sabes quién fue la primera arquitectura que apostó por muchísimos cores ligeros y poco potentes para atacar el mercado de los servidores web y java? la sun SPARC (en particular, a partir del UltraSparc T2 -8 cores con 8 hilos cada uno, hasta 64 threads simultáneas- y T3 -16 cores con 16 hilos cada uno, 128 hilos, que se dice pronto-) . Y tuvo relativo éxito, pero al final el mercado buscaba cosas más generalistas y potentes y murió. ¿Sabes qué otra arquitectura intentó algo similar? bulldozer de amd. Y falló en parte por estar fabricados con tecnología que intel podía barrer tranquilamente (aunque con gran capacidad multitarea, poco potentes y consumiendo más que los procesadores de intel). Y ojo, que hablamos de la tecnología que movió la play4.
Justamente ahora AMD tiene soluciones que aunan todo y por eso están comiéndose ciertos mercados: tienen cpus con gran cantidad de capacidad multiproceso, con muchísima potencia cada núcleo individual y con un consumo contenidísimo y mucho menor que el de los productos de sus rivales en sus mismas gamas y tecnologías de fabricación equivalentes (si, incluso comparados con apple... sácalos de productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).
Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).
Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.
#2 Yo creo que la mejor explicacion sobre Risc-V que es y que implica, es esta serie de artiiculo. Por si alguien quiere ampliar informacion.
https://architecnologia.es/risc-v-introduccion-a-la-isa
#6 Basicamente libertad. Seguramente las ventajas se veran mas en el futuro que ahora. O el hecho de que haya una alternativa RISC-V puede evitar que lo fabricantes propietariios de las licencias abusen.
Explicacion Mas elaborada en #17
#14 Yo entiendo que no es obligatorio como se sepa como funciona el micro por dentro. Solo que como se interactua con él. Las instrucciones que se usan y qué hacen.
#22 Excelente artículo, muchas gracias.
#40 Sí, ya lo ví. Gracias!
#13 GPL vale, porque promueve que se comparta lo que se desarrolle (y ahí va tanto funcionalidades como parches de seguridad; la calidad y el alcance del código sube y todos salen beneficiados) .
El problema que apunta #8 es debido a la moda de usar licencias que permiten hacer lo que quieras con los fuentes. De ahí si que hay muchísima gente que se aprovecha del trabajo de los demás sin que el resto se beneficie.
Por otro lado, nadie evita que alguien pueda cobrar o enriquecerse usando software libre; de hecho, la GPL permite y anima a cobrar por el trabajo que se realiza.
#48 y cuando no, también. Con el tiempo se ha visto que el software libre no es la solución sino un parche. La solución es luchar contra las patentes de software y dar la propiedad a quien la haya copiado de manera que se pueda hacer lo que les dé la gana con la copia.
#52 Son cosas diferentes y atacan ámbitos diferentes. MS y otras han tenido que asociarse para permitir usar patentes en desarrollos de software libre porque se dieron cuenta de que estaban pisándose su propia prosperidad con eso (dado que las compañías propietarias hacen mucho dinero con el software libre y demandarse unas a otras por cosas que usan todas al final era una tontería).
#97 Precalcular siempre es más rápido porque una vez hechos los cálculos, nunca vas a tener que repetirlos (se guardan en disco o memoria y ya está). Y eso no implica hacerlo siempre o la primera vez que ejecutas el juego, lo haces "de fábrica". De hecho, algunos aspectos de todos los niveles son "precalculados" (las luces y sombras de los escenarios de juegos de la época se generan, se dibujan y se guardan, son estáticas, se cargan con el nivel y se añaden como una capa de dibujado más). De hecho, en el quake original y muchos otros juegos, los niveles se compilaban. Eso de lenguajes de scripting dinámicos donde las cosas de un juego se evalúan sobre la marcha llegaría más tarde (a partir del unreal, probablemente el quake 2 o poco antes).
#30 El copro hacía operaciones en coma flotante muy precisas, pero también de manera muy lenta (para los estándares actuales ya ni te cuento). No tanto las operaciones en si (si no hubieran sido rápidas, no tendría sentido) sino la comunicación con el procesador (el procesador se quedaba "bloqueado" a la espera, cedía el control de ejcución al coprocesador por así decirlo y luego lo recuperaba). Esto, como comprenderás, es un lastre muy grande para un juego que quiere mover muchísimas cosas por pantalla muchas veces por segundo.
"nother point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.
The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.
However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip."
#2 Seguiría tratándose los síntomas y no la causa. Pero claro, las guerras de la región y los intereses de segundos y terceros países en las materias primas, etc. son cosas mucho más complejas y delicadas de abordar porque implicaría cuestionar nuestro modelo económico, social y en parte nuestro modo de vida... eso para cualquier político es un suicidio (ya les cuesta ponerle freno a las corporaciones, incluso cuando se demuestra fehacientemente que están violando leyes, acuerdos y regulaciones...)
#4 Así es. Estos países no prosperan porque las multinacionales y los estados serviles a las mismas, no les dejan directa o indirectamente. Un país necesita una generación en paz como mínimo para comenzar a desarrollarse. Las migraciones son el trágico efecto secundario de nuestro bienestar.
#174 Hay juegos de windows que no funcionan en windows y si en linux...
De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).
Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).
#187 eso implicaría trabajo por parte de las desarrolladoras, y visto como está la industria acaba siendo complicado.
Pero sí, sería lo mejor.
#181 ¿Y qué tiene que ver el kernel con eso? justamente el kernel es la parte más conservadora de todo el sistema. Probablemente aún funcionarían cosas hechas incluso para kernels viejérrimos como los 2.4 o 2.6 en equipos actuales. ¿Qué pasa? las librerías... nadie programa a pelo sólo usando interfaces de kernel, todo el mundo echa mano de librerías, y estas mueren, cambian, se abandonan, mutan... es lo que hace que los programas dejen de funcionar en linux (o en windows... ¿o acaso cuando hay cambio de versión no hay cosas que dejan de funcionar?).
#164 Entonces en lugar de ir a por wine/proton, tira de codeweavers. Es wine/proton, pero de pago y orientado al software en general. Y con el soporte, tienes la potestad de hacer que los desarrolladores se centren en el software en concreto que necesites que funcione (evidentemente si valve les paga para desarrollar proton y parchear los juegos más recientes, ellos van a soportar los juegos más recientes en proton; si tú les pagas para que funcione X, pues buscarán qué es lo que falta o no está haciendo su trabajo y lo añadirán o modificarán). No es tanto que no haya interés, sino que son pocos desarrolladores y no pueden abarcar todo (y si hay empresas o particulares que les pagan para ciertas cosas particulares, evidentemente se enfocarán más en ellas).
NTFS3g llevaba mucho tiempo en desarrollo, pero no estaba lo suficientemente maduro como para permitir que la gente lo usara para el día a día (y por lo tanto, las distribuciones no lo añadían como herramienta por defecto). No es que saliera de la noche a la mañana, es que cuando se consideró usable y estable y que no se iba a comer tus datos, fue cuando se empezó a usar más masivamente.
#72 Si quieres de verdad comparar estas cosas, échale un ojo a los benchmarks que se cascan en phoronix.com
Por ejemplo...
Usa el mismo hardware y con sistemas linux "tal cual te lo descargas" y va actualizando cada cierto tiempo con comparativas de todo tipo.
Incluso si no te fías o tienes curiosidad por hacer pruebas tú mismo, puedes usar su sistema de benchmark y realizar las mismas pruebas en tu equipo (tiene perfiles para cada aplicación, normalmente aplicaciones libres y abiertas que pueden descargarse y ejecutarse sobre la marcha o juegos que tienen facilidades para obtener datos de rendimiento; no suelen ser lo último del mercado pero porque la gran mayoría no pueden lanzarse de manera automatizada o le dan los datos que necesita).
#38 Yo diría más las steam machines y cuando microsoft amenazó con vallar su windows y hacer que todas las aplicaciones fueran por su tienda. Valve le vio las orejas al lobo y quiso dinamizar y consolizar el mercado para ampliarlo y no depender de windows; el proyecto fue fallido, pero permitió poner en primer plano las limitaciones existentes y darles un toque a los fabricantes (amd estaba en plena transición de drivers y negocio sobre soluciones de software libre, sus drivers daban bastante pena y las cosas potentes y novedosas que se habían sacado de la chistera no les funcionaron por falta de soporte de desarrolladores y de sus propios equipos internos, les pilló en muy mal momento) y replantearse cómo animar a los desarrolladores
Eso es lo que ha llevado a donde estamos ahora: plataforma semiabierta con muchas ventejas y la más completa del mercado sobre SO completamente abierto y un hardware lo más abierto posible, que permite a la gente trastear y desarrollar un ecosistema de aplicaciones propias y optimizarlas sin ningún impedimento o cortapisas. Y eso sin forzar a nadie a elegir desarrollos nativos, con una capa de compatibilidad con windows que asegura que sea fácil y barato que tus juegos funcionen y que si quieres apoyar más directamente el hardware, tengas todas las facilidades para hacerlo (librerías, código, especificaciones abiertas, etc).
#169 en lo de que lo que hizo a Valve moverse fue el interés de Microsoft por empujar el uso de su tienda, totalmente de acuerdo.
Lo que me gusta de esa capa de compatibilidad, es que puede ser adaptada para juegos de hace 20 años, de hace 10, y actuales. Es una forma de mantener una biblioteca de juegos durante toda tu vida.
#174 Hay juegos de windows que no funcionan en windows y si en linux...
De todos modos, no es una bala mágica, muchos dependen de implementaciones específicas de ciertas cosas (o sea, se programaron con librerías que tenían bugs de forma que se aprovechaban de ellos o los ignoraban y seguían a sus cosas). Es imposible cubrir todos los posibles casos y hacer que todo funcione (en parte porque la solución sería parchear las aplicaciones que no funcionan bien, no poner mil excepciones en la emulación de esas librerías para cubrir todos los casos).
Fíjate la que se ha armado porque AMD en sus últimos drivers, para poder ampliar el número de juegos que soportan su FSR3 (que como los DLSS, necesita que sean incorporados dentro de los propios juegos, no son una simple "capa" de post procesado) se le ocurrió que los drivers podrían coger e inyectar ese código directamente en los juegos en tiempo de ejecución (así, sin necesidad de que los juegos soportaran FSR 3.0, podías tener FSR gratis). El problema es que ciertos medios y controles antipiratería validan que el ejecutable del juego sea íntegro y no haya sido modificado (para filtrar a los hackers que hacen trampas modificando el propio juego y demás) y esto ha cantado por todos lados y muchos han sido baneados... pero vamos, lo suyo sería eso, parchear el propio juego (algo así como lo que hace gog para que ciertos juegos antiguos puedan funcionar en equipos nuevos).
#187 eso implicaría trabajo por parte de las desarrolladoras, y visto como está la industria acaba siendo complicado.
Pero sí, sería lo mejor.
#35 Es complicado hacer métricas porque hay muchas cosas que valorar. No sólo influye la cantidad de frames, sino la latencia, el cómo se gestionan los recursos, temperaturas, consumo, etc.
Habrá juegos que vayan mejor en uno y otros que vayan mejor en otro SO. Tampoco es malo que haya competencia y los usuarios tengan elección. Al fin y al cabo, sony usa BSD por debajo de su playstation desde hace algunas generaciones, microsoft sigue con su windows capado en sus consolas y nintendo... sigue a lo suyo, como siempre.
#75 Eso es una aplicación, es (hasta cierto punto) independiente del sistema operativo. Y al final usa un protocolo llamado LDAP (que tiene una versión abierta llamada openldap y muchas derivadas) que puede usarse en linux también. Y también usa un protocolo llamado samba (que también puede usarse en linux). Al final, las funcionalidades del directorio activo pueden usarse en linux (y sospecho que el zenyal este no es más que un software que empaqueta e integra estas y otras cosas por debajo).
Linux tiene muchas facilidades para interconectarse y usar otros "directorios de usuarios y recursos" en su sistema de manera transparente...
#3 Si hubiese una distro enfocada y optimizada para juegos te daría la razón (lo más cercano sería el SO de la deck, pero aún así puedes salir del modo big picture y tienes el escritorio ahí, preparado y dispuesto para enchufarle un docker con pantalla, teclado y ratón y ya tienes un ordenador completo). Pero las distros más típicas y que usa la mayor parte de la gente son como windows: son sistemas de uso general, con un montón de servicios que quizá no necesites corriendo...
Si "Barbie Girl" fuera la canción más difícil de tocar del mundo
youtube.com¿Qué pasaría si te obligaran a tocar la canción más difícil de tocar del mundo? ¿y si te dijeran que se tratara de Barbie Girl de Aqua?
Muere a los 71 años David Boggs, coinventor de las redes Ethernet
engadget.comEl investigador pionero en computación del equipo Xerox PARC David Boggs ha muerto a los 71 años. Es conocido por ser el coinventor del estándar de interconexión de ordenadores en redes locales (cableadas o sin cables), impresoras e internet llamado ethernet. En dos años, él y Bob Metcalfe diseñaron la primera versión, un enlace que podía transmitir hasta 2,94 Mb/s sobre un cable coaxial. Metcalfe decía de David: "fue el compañero perfecto para mi. Yo era más como artista conceptual, mientras que él era el típico ingeniero de trastienda"
#1 Como todas las sociedades capitalistas. Y incluso diría que todas las sociedades, a la larga. El poder tiende a concentrarse en pocas manos, y el dinero es una forma de poder.