El reciente fallo de uno de los dos ordenadores de Curiosity ha puesto de relieve el importante papel que juegan los microprocesadores en las misiones espaciales. El rover marciano incorpora dos RAD750 (PowerPC 750) a 200 MHz, ¿pero qué hay de otras naves espaciales? Con diferencia, el microprocesador más popular en la NASA es el RAD6000, una versión del PowerPC 601 desarrollado por IBM y actualmente construido por BAE Systems.
|
etiquetas: microprocesadores , naves espaciales , astronáutica , sistema solar 
bimg2.mlstatic.com/cpu-mac-apple-200-mhz-expandible-a-512-mb-ram-por-r
se pueden hacer todo tipo de tareas de edición gráfica, manejo de textos, etc... de hecho me parece un procesador colosal teniendo en cuenta que va dirigido a realizar calculote puro y duro, y sin duda programado de manera optima y eficiente...
Mira que ha avanzado el software en los ultimos años.
1.- Relojes de sistema de 1MHz -> 3GHz 3000/1
2.- Bus de datos: 8->64 8/1
3.- Memoria 1KB->3 GB 3M/1
4.- Almacenamiento 1MB-> 1TB 1M/1
Solo con estos datos podemos inferir una multiplicación de la potencia del hardware 24.000P/1, (24.000 petas)
¿Y el software mientras? no solo ha avanzado sino que en muchos casos hasta a retrocedido, los programas son cada vez mas monstruosamente grandes, mucho mas lentos,menos eficientes y con mas fallos que nunca.
Y sobre el rendimiento... una aplicación pequeña… » ver todo el comentario
En cuanto a lo de hacer los programas en ensamblador, se puede usar un método intermedio (que casi nadie usa): Forth. Está en un punto intermedio entre ensamblador y C.
#29 No digo que esté a medio camino. Me refiero a que es más portable que ensamblador y de aún más bajo nivel que C (RPN entre otras cosas).
#9 El otro día salio ese tema de conversación durante una cena: El software está retrocediendo respecto al hardware. Mientras que el hardware es cada vez más y más potente, nos comemos esa potencia con software cada vez más amigables al programador y más costosos para las CPU.
Se empezó programando en ensamblador, se paso a C, y poco a poco se han ido imponiendo las "maquinas virtuales" (Java, C#, Flash?) corriendo bytecodes y ahora el "futuro" parece que será javascript, que es puro texto en ascii/unicode.
Cada vez se necesita más CPU para conseguir los mismos resultados que hace años.
Al precio que esta el hard, resulta mas barato comprar un par de gigas de RAM que dedicar un equipo a reducir el consumo.
Sí, lo está, siempre, a no ser que haga SOLO lo que quieres que haga, y eso no ocurre nunca (a no ser que la hagas tu y puedas eliminar partes innecesarias), otro tema es que no sepas hacerlo mejor de como lo hace la librería, ese es otro tema.
Pero mi problema principal es otro, y es el tema de los requisitos, ejemplo.
Quiero hacer un "hola mundo", y me apetece hacerlo en .NET
¡SORPRESA! Obtienes un "Hola… » ver todo el comentario
Como comenté antes, tienes que mirar los requisitos que quieres cumplir al hacer un programa y elegir cómo hacerlo. Un engine gráfico no está hecho ni en Java ni en C#, sino en C++, y un hola mundo se puede hacer con un .bat en el que pongas "@echo Hola, Mundo", te ocupará lo mínimo que puede ocupar un fichero y será retrocompatible hasta con el MS-DOS de los 80.
#43 Si no saben que hay alternativas es que ni se molestan en mirar, ya no es un tema tecnológico sino de pura vagancia, porque sale en cualquier catálogo de Phone House o de cualquier operadora.
Luego te descargas cualquier chorrada, un cliente de correo, un juego de damas, o algo que no tiene porque requerir nada, y te encuentras que te hace falta el .NET, y si no tienes 512MB de ram no puedes usarlo.
El programador dirá que el cliente no tiene los requisitos mínimos, ¡mentira! ¡el software esta mal diseñado!
La librerías gráficas tres cuartos de lo mismo, muchos juegos y… » ver todo el comentario
En general, la filosofía en el desarrollo para Amiga ha sido siempre ha sido siempre la de exprimir las capacidades del hardware al máximo, dado que nunca se ha podido contar con actualizaciones periódicas de CPUs. No te queda otra que apañarte con lo que tienes, sacándole todo el partido posible, a base de optimizar el software hasta sus límites.
No he oído a nadie quejarse de la librería stdio ni hay errores en dicha librería. Se pueden utilizar librerías y programar eficientemente y sin errores.
Es que han retrocedido.
Que los móviles ahora se cuelguen, sean lentos, tarden en cargar software, la batería les dure un día en vez de una semana y que encima sean tan grandes que parece que llevas de paseo el mando a distancia de la TV, me parece un retraso muy grave para hacer cosas no muy alejadas de lo que ya podíamos hacer con móviles menos potentes hace 10 años.
No, no lo reclaman: Es que es lo que les venden. No saben que hay alternativas.
Cuantas veces habré oído voces de incredulidad y admiración cuando saco el Xperia Mini para mandar un whassap. No saben que existen móviles pequeños que hacen lo mismo.
De todas formas, aunque sean pequeños siguen teniendo los mismos problemas que los grandes: Lentos, toscos, tienen que cargarse todos los días, etc...
No acabo de entender el cálculo que propones.
-la mejora de la CPU la mides por su velocidad de reloj
-la del bus de datos, por su tamaño de palabra (no por su velocidad de reloj). (*)
-la de memoria, por su capacidad de almacenamiento (no por su velocidad de reloj ni su tamaño de palabra)
-y el almacenamiento como la memoria, por su capacidad.
(*) Y no tengo claro en qué influye el bus de datos para multiplicar la potencia más allá de no ser un cuello de botella, pero bueno.
Entonces coges, multiplicas todo eso entre sí, y de ahí infieres un factor de "multiplicación de la potencia del hardware" de 24exa.
Sin ánimo de ofender, o estoy un poco espeso o esto no tiene ni pies ni cabeza.
2^8/1
Existen motores de software avanzadísimos: ahí está el PHP, realizando interpretacion y compilacion de lenguaje en tiempo real -cosa impensable hace años - , o el interprete Java en los Android.
O los sistemas de reconocimiento facial , filtrado de voz...
O el codec H.264, que hace maravillas comprimiendo videos de alta resolución.
La NASA es especialista en la investigación del desarrollo de código tolerante a fallos.
El esquema básico es desarrollar los módulos mediante varios grupos independientes. Cada uno de ellos desarrolla el módulo sin contacto con el resto, cumpliendo con estándares de calidad y con una especificación muy clara y detallada.
Luego, hay dos estrategias básicas en tiempo de ejecución:
-Ejecutar todos los módulos y luego decidir cual o cuales de ellos dan resultados razonables (votación, tests estadísticos, validación lógica de resultados...)
-Ejecutar un módulo, y si éste falla (analizando sus resultados con uno de los métodos mencionados en el anterior punto), seguir con el siguiente hasta encontrar uno que de resultados válidos.
Además, deben ser chips fiables y altamente probados en el momento de empezar el diseño de la sonda o nave.
porque las misiones Viking, que ya han salido de nuestro sistema solar,
siguen funcionando y enviando datos. Entonces han contratado a muchos
ingenieros… » ver todo el comentario
#8, tu primer enlace no se yo si... amos a ver, las Viking fueron las sondas que aterrizaron en Marte. Las únicas que han salido del sistema solar son las Pioneer y las Voyager, y estas últimas funcionan aún. Las Pioneer es posible que funcionen, pero la señal era ya muy débil hace década y pico y se dejó de intentar contactar con ellas.
Siempre digo en plan de coña que llegamos con la tecnología del Spectrum, pero me gustaría saberlo