meneandro

#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.

#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.

#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 Doom no usa coprocesador de aquella época por eficiencia y portabilidad.

El coprocesador matemático del 486 era muy preciso pero extremadamente lento.

En esa época cuando necesitaba calcular trigonometria para demoscene utilizaba tablas de enteros precalculadas y ni me acercaba al copro.

#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."

#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.

#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.

#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...)

#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.

#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.

#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 Doom no usa coprocesador de aquella época por eficiencia y portabilidad.

El coprocesador matemático del 486 era muy preciso pero extremadamente lento.

En esa época cuando necesitaba calcular trigonometria para demoscene utilizaba tablas de enteros precalculadas y ni me acercaba al copro.

#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."