Pirámides son piedras sobre piedras.

Marcos 13:2 Y Jesús le dijo: ¿Ves estos grandes edificios? No quedará piedra sobre piedra que no sea derribada.

Lucas 21:6 Esto que veis, vendrán días que no quedará piedra sobre piedra que no sea derribada.


Todo el mundo sabe que las pirámides son grandes templos hechos de piedras sobre piedras, ¿por qué no están derribadas las pirámides?


Automáticamente se profetizará por Jesús que las pirámides serán también derribadas antes de la venida del mesías.


Si no fuera así entonces ¿cómo se cumplirán las profecías?

Lucas 21:22 porque estos son días de venganza, para que se cumplan todas las cosas que están escritas.

Logneper de dominio real.

Para todo x en Reales, logneper(x) =

• indefinido si x=0
• logneper(x) si x>0
• logneper(-1) + logneper(-x) si x<0

La demostración de que logneper(x) = logneper(-1) + logneper(-x) para todo x<0 es:

Para x<0, logneper(x) = logneper(1*x) = logneper((-1)*(-1)*x) = logneper((-1)) + logneper((-1)*x) = logneper(-1) + logneper(-x)  [c.q.d.]

Nota: se ha utilizado la ecuación logneper(a*b) = logneper(a) + logneper(b).

El Dólar Titánico se hundirá.

Las ratas son los primeros en escapar del gran buque del Dólar Titánico que esta yendo a hundirse,

¿quién se hará cargo del estimulo económico sobre la cubierta desierta del buque? Me temo que Bernanke también se escapará, xD.

Jajajaja, las ratas han ganado, xD.

------------------------------------------------------------

Me acabo de inventar una trampa económica artificial para la hecatombe económica mundial para el interés de EEUU:

"la oculta trampa de Bernanke-Goldman-Zoellick"

El trío sabrá cuándo ocurrirá el secreto día de la hecatombe.

1. Bernanke se ocupará de la corrección de la evaluación de la moneda del dólar hiperinflado al dólar hiperdesinflado.
2. Goldman se ocupará de hacer una bajada de precios de metales preciosos con respecto a la nueva referencia del dólar hiperdesinflado como las grandes cataratas.
3. Zoellick se ocupará de intentar que el mundo acepte la propuesta de la "Modificación del Gold Standard".
4. Y finalmente, los especuladores se aprovecharán de esta cepa de BGZ para recuperar el retorno de por ejemplo de 300% de la masa de Oro y co. pagando por menos dinero, es decir, pagando con dinero prestado de ayer el oro de hoy bajado de precio.

Podría ocurrir otros detalles más que no he explicitado, vamos, es una tontería detallarlo todo.

Ecuación de logneper(-1).

logneper(-1) = {pi (mod 2pi)}*i

Demostración: -1 = e^logneper(-1) = e^({pi (mod 2pi)}*i) = -1 c.q.d.

No a la ley machista de minifaldas.

He oido que unos machistas de algunos municipios imponen por ley unas multas de 500 lepiros a las que pasean en minifaldas por las calles y avenidas de los municipios.

¿es justa esta ley de multas por sólo mostrar una pierna natural de mujer?

¿cuántas chicas que van a las discotecas nocturnas llevan vestidas de minifaldas? Muchas.

Que vengan las chicas con minifaldas a las discotecas nocturnas, sin minifaltas, para pasarlo todo guay, xD

Un OPS que no tiene vectores.

¿por qué un OPS (Official Production System) no soporta el tipo vector además del tipo escalar en las ranuras de las plantillas?

Mi inteligencia viene a decir que tener una memoria de hechos de tamaños variables es simulada de I.A. mejor que con una de hechos de tamaños fijos.

Un ejemplo típico a simular en OPS podría ser el Block World del brazo de robot, en donde se apilan bloques en determinadas columnas.

Tales apilamientos necesitan el uso de vectores en las ranuras de los hechos mejor que hacer malabarismos con una expansión en horizontal de hechos con identificadores de posición de cada bloque.

Mi recomendación sería que un OPS soportase tipos vectores en las ranuras de las plantillas, sin importar las críticas de la ineficiencia del algoritmo de matching cuando se usa esta característica faltante.

Es decir, el tipo vector obliga a cambiar la implementación del algoritmo de matching, y no al revés, nunca hacer que el algoritmo de matching impida añadir esta característica muy funcional de I.A. de soportar tipos vectores además de tipos escalares.

En principio, irá a ser una versión muy simple, vector de escalares. Las complicaciones de las implementaciones de la característica de vectores de vectores se tendrán que esperar hacia más adelante según la necesidad pronta del ingeniero de conocimiento en determinadas áreas de I.A.

Faltando setters y getters en prototipos.

¿qué ocurre cuando un lenguaje de programación orientado a prototipos que está basado en slots no dispone de setters y getters que eran muy importantes en lenguajes de programación orientado a objetos puros?

Pues que sería un punto de inconveniente para los basados en prototipos y un punto de ventaja para los basados en objetos.

Ya veremos cómo arreglaremos esto, hay diferentes opiniones para arreglarlo, jajajaja.

Los futuros computadores ecológicos.

En el mundo de la computación actual, los actuales computadores que corren en Internet no están optimizados para una amplia gama de aplicaciones que consumen los humanos.

Actualmente hay muchos computadores que son de 32 bits y otros que son de 64 bits. Hay algunos que son de 16 bits, 8 bits y otros raros que no voy a comentar aquí.

La pregunta que viene a continuación es, ¿está optimizada la política de uso de los computadores en el mundo?.

Me viene a sospechar que no está optimizada dicha política, y he venido a publicar este blog ofreciendoles un buen camino global para el mundo. Soy un ingeniero informático muy excepcional que me he tirado la vida estudiando, leyendo y escribiendo para conseguir un fin común de la humanidad.

Muchas compañias de silicio han estado compitiendo en el mercado vendiendo computadores de 32 bits y de 64 bits a los clientes finales. Pero muchos clientes no encuentran la satisfacción de esos computadores del mercado. Muchos se quejan de que los computadores son muy limitados a menos de 4 GiB de memoria física por motivos de unos diseños arquitecturales de los fabricantes. Los fabricantes han estado haciendo remaches y más remaches empeorando aún más la arquitectura final del sistema.

Dichos remaches no han hecho nada más que crear nuevos problemas para los desarrolladores del software con su ineptitud de crear malabarismos en el desarrollo de aplicaciones y además tales remaches causan caidas notables de rendimiento y peores latencias de transferencias de memorias.

Los fabricantes, sabiendo los problemas de los desarrolladores de aplicaciones, han impulsado en seguir adelante con un nuevo diseño de computadores de 64 bits junto con la arquitectura previa de 32 bits integrada.

Pero los desarrolladores se han quejado de que muchos computadores de 64 bits hacen que las aplicaciones chupan mucha memoria, más del 50% usado en promedio con respecto a aplicaciones equivalentes de 32 bits.

Y yo como soy un ingeniero muy inteligente, os publico la tecnología de mi diseño arquitectural de los futuros procesadores ecológicos que durarán para varios siglos con el fin de que los desarrolladores de aplicaciones no tengan que crear malabarismos y a la vez que permitan correr aplicaciones de muy alto nivel de forma muy eficientes.

El computador es un híbrido combinado de 32 bits y de 64 bits, pero siguiendo con una distribución gausiana de las aplicaciones que se corren en el mundo, se asignará un peso de 0.99 a los procesos de 32 bits, y un peso de 0.01 a los de 64 bits.

Es decir, la política óptima y correcta debería ser la más ecológica, es la que debe seguir existiendo masivamente procesos de 32 bits y escasos procesos de 64 bits en todo el globo terrestre, y nunca al revés hasta pasados futuros siglos.

Se asignará ejemplarmente un 95% del área de silicio (o de puertas lógicas) dedicado a la computación de 32 bits, y 5% o menos a la de 64 bits. El motivo es que las aplicaciones de 64 bits son de uso "muy raro" en la mayor parte del tiempo, y con el fin de aprovechar al máximo los escasos y caros recursos de silicio y de electricidad, se le da la mayor parte de su queso a aplicaciones de 32 bits, reservando una ínfima parte de dicho queso para poder ejecutar aplicaciones de 64 bits según la necesidad del usuario.

Las aplicaciones de 64 bits que se ejecutan "raramente" podrían ser ensayos experimentales de cálculo de modelos matemáticos de matrices gigantescas, o exploración del algoritmo de A* que avalancha toda la memoria del computador, o simulación científica de la meteorología, o una consulta a bases de datos gigantescas.

Los detalles del computador híbrido de 32 bits y de 64 bits son:

• la unidad de la información será de una palabra de 32 bits en vez de un octeto de 8 bits (Ojo, para datos 32 bits, para código 8 bits). El formato de la dirección de código viene desplazada en 2 bits a la derecha con respecto al de datos.
• los procesos no tienen modo dual de "bitness" sino que los mismos tendrán instrucciones de 32 bits y de 64 bits
• los procesos de instrucciones 32 bits podrán direccionarse hasta 16 GiB de memoria virtual de espacio de usuario y 16 GiB de memoria virtual de espacio de kernel usando instrucciones extras de kernel para acceso a (y desde) memoria del kernel. Esto sería 16GiB+16GiB por proceso de instrucciones de 32 bits.
• otra variante podria ser de asignar 15 GiB al espacio de usuario y 1 GiB al espacio de kernel usando un selector de chequeo de 4 bits (1 de 16) en el nible más significativo de la palabra de dirección de 32 bits, o 15.5 GiB de usuario y 0.5 GiB de kernel usando un selector de chequeo de 5 bits (1 de 32). Así se ahorra del no tener que añadir instrucciones extras de kernel.
• los procesos de instrucciones de 64 bits podrán direccionar hasta 2^64 palabras de 32 bits o 2^63 palabras de 64 bits.
• la capacidad de memoria física es ilimitada ¡eureka, nada de malabarismos!, podría ser de varios cientos de GiB de memoria física aunque los procesos de 32 bits sólo direccionan hasta 16 GiB de memoria virtual. Es objetivo común ejecutar varios procesos de 32 bits chupando 16 GiB de memorias virtuales usando cientos de GiB de memoria física.
• en principio, el tipo de memoria dinámica que se usarán sería DDR3 o posterior, ya que la tensión de alimentación es de 1.5V, cuanto menos es, mejor será ya que menos electricidad se consumirá para más capacidad de memoria. La tendencia tecnológica de los voltajes es siempre hacia la baja para las futuras memorias de ahorro, similar a las bombillas de ahorro.
• los módulos de memoria DDR3 o posteriores se instalarán en los 8 vientos del procesador (de 3x3 excepto centro), tanto arriba como abajo. En total habrán 16 áreas espaciales para instalar los módulos y deben estar muy pegados al procesador al milímetro para conseguir latencias extremadamente muy bajas, y anchos de bandas muy altos.
• para instrucciones de 32 bits, se dispondrá un hardware dedicado de TLB y MMU de paginación de hasta 16 GiB + 16 GiB (o su variante) usando páginas de 16 KiB y sólo 2 niveles de paginación cuyo acceso se hará en hardware.
• para instrucciones de 64 bits, sólo se dispondrá un hardware dedicado de TLB, pero no de MMU de paginación, usando las mismas páginas de 16 KiB. Si la dirección de 64 bits está dentro del rango de 16 GiB (es decir, el valor de la palabra alta de 32 bits de dirección está a 0) entonces se utilizará el hardware de 32 bits para acceder a la palabra de 32 bits o de 64 bits. Pero si la dirección de 64 bits está fuera del rango de 16 GiB (es decir, el valor de la palabra alta de 32 bits de dirección es distinto de 0) entonces se activará la excepción y se accederá por software a través del manejo de memoria del hipervisor. En realidad hay dos hipervisores, uno en el espacio de usuario y otro en el espacio de kernel. La razón de este doble hipervisor es que un doble cambio de contexto usuario->kernel y kernel->usuario es siempre más lento que saltar a la subrutina de manejo de la excepción y volver de ella sin salir del espacio de usuario. El principal requisito es que el proceso de instrucciones de 64 bits debe tener cargado una librería de subrutinas de excepciones para el hipervisor en el espacio de usuario para poder manejar las excepciones "rápidas".
• una variante extra, para no ralentizar la paginación de 64 bits cuando se usan varios cientos de GiB de memoria virtual, podría ser añadiendo un tercer nivel de direccionamiento en el hardware, pero este añadido es el precio que se paga por añadir más silicio dedicado a la computación de 64 bits. Si se quisiera poner más niveles de direccionamiento en el hardware con menos silicio, mi recomendación sería que se aproveche el mismo demultiplexor en bucle en vez de varios demultiplexores replicados en pipeline, y quizás sea uno de los de 32 bits.
• la palabra de traducción de dirección de página de ambos modos de "bitness" será de 64 bits en vez de 32 bits con el fin de poder direccionar cientos de GiB de memoria física, y los bits que sobran de dicha palabra podrán ser usados para atributos de control del sistema operativo como podrían ser los contadores de acceso de páginas.
• la dirección de 32 bits se divide en 10 + 10 + 12 bits, y la de 64 bits en 32 + 10 + 10 + 12 bits sin contar el hardware añadido de tercer nivel. Los demultiplexadores serán pequeños, de 10 y 12 bits, pero los de 12 bits se pueden convertir a demultiplexadores de 10 bits junto con multiplexadores de 2 bits seleccionando 1 de 4 de palabras de 32 bits de 128 bits de la línea. Para el caso de 64 bits, si además de eso, también quiere acceder a palabra de 64 bits, sólo se necesitará un multiplexador de 1 bit seleccionando 1 de 2 de palabras de 64 bits de 128 bits de la línea. Usando sólo demultiplexadores de 10 bits (de 2^10 entradas) y no más, permitirán un acceso muy rápido de puertas de lógicas de silicio.
• como los demultiplexadores de 10 bits sólo pueden direccionar 2^10 entradas, y las entradas de traducción de dirección son de 64 bits entonces sería un bloque de 8 KiB que no coincide con el marco de página de 16 KiB. No hay problema, un marco de página de 16 KiB puede contener 2 bloques de 8 KiB de indireccionamiento, y aunque a veces sólo se usa un bloque en el marco, el otro bloque consecutivo sin usar sería un hueco que podría ser ocupado posteriormente.
• al ser un marco de página de 16 KiB grande, esto sería mejor para el TLB tener un mayor espacio de marcos reduciendo así la frecuencia de fallos de páginas.
• nunca querré páginas grandes de varios MiB como los usados en los procesadores actuales ya que son un malabarismo que no sirve para nada, y además quitan inutilmente espacio en el chip de silicio para tales funcionalidades.
• el tipo de autómata del computador es hibrido combinado y está basado en [1. pila y acumulador] y [2. banco de registros].
• El sub-autómata de pila y acumulador servirá para que las instrucciones sean muy compactas, sin operandos, ocupan pocos bytes de código con el fin de aprovechar la localidad espacial y temporal de cachés muy pequeñas de código. Sus importantes registros serán Stack Pointer, Base Pointer (of Stack), Accumulator (que contendrá el valor del tope de pila apuntado por SP) y el Secondary Accumulator (que es el penúltimo de la pila, como segundo operando en muchas instrucciones de operaciones binarias que existen actualmente). Un cambio de SP implica un movimiento de valores de Accumulator y Secondary Accumulator a/desde búffer ventana interna de pila que será automatizado por el hardware de silicio.
• El sub-autómata de banco de registros será de 16 registros y no más (32 registros ya es una presión inútil de más puertas lógicas de silicio en el núcleo), a saber que según la distribución gausiana, las subrutinas de muchas aplicaciones están muy conformes con tener un banco de 16 registros. De esos 16 registros, hay que descontarlos para los usados del sub-autómata de pila. No me interesa 32 ni más registros del banco porque muchas subrutinas de aplicaciones generalmente no llegan a usar 32 registros, y además, 32 registros significan que hay demasiada presión combinatoria de "registros renombrados" (Register Renaming) en el algoritmo Tomasulo en caso de ser implementado. Y tampoco quiero empeorar la latencia de cambio de contexto con un banco muy grande de registros.
• la versión más económica y habitual sería un banco compartido de 16 registros de 32 bits y 8 registros de 64 bits. Como dije antes, lo de 64 bits se usa raramente, y en caso de usarse, será por necesidad del usuario.
• los códigos para las instrucciones serán de clase CISC (en vez de RISC) aprovechando ventajas de una caché pequeña de código, y optimizados en función de la codificación Huffman y de la distribución gausiana de muchas aplicaciones óptimas, y van en unidades de 1 byte. Aunque el Instruction Pointer (IP) es de 32 bits (rara vez o no se usa el IP lento de 64 bits), el acceso a la instrucción es en unidades de bytes y no de palabras de 32-bit, eso significa que el rango de espacio de direcciones virtuales de código será de 4 GiB en vez de 16 GiB comúnmente usado para palabras de datos.
• las cachés de L1 serán como mínimo 8 KiB de I y 16 KiB de D, pero lo típico sería el doble o el cuadruple para conseguir más rendimiento. Esta asimetría en los tamaños de I y de D se debe a que no querré saturar a una mayor magnitud de IPC (Instructions Per Clock) de cada línea de palabras que se carga desde la caché de I al núcleo. Por eso relajo un poco el IPC y le quito espacio de caché de I para dar más espacio a la caché de D con el fin de reducir la frecuencia de fallos de acceso a datos (que se circulan masivamente) aunque raramente crece la frecuencia de fallos de acceso a códigos (aunque sean muy compactos y en bucles que nos importan mucho, a pesar de la maldad o bondad del Inlining de código creado por compiladores optimizadores).
• no voy a detallar cómo tienen que ser las cachés L2, L3 y L4, estas decisiones las tomarán los fabricantes. No hay muchos cambios en esta jerarquía de cachés con respecto a las actuales, pero sería buena idea tener un acceso exclusivo de cachés además de un probable acceso inclusivo de cachés.
• debido a la distribución gausiana de las aplicaciones óptimas, las instrucciones de 32 bits son muy cortas y de latencias mínimas de CPU, pero las instrucciones de 64 bits (que habitualmente se usan poco en la mayor parte del tiempo de computación en el globo terrestre) serán generalmente largas, prefijadas con un byte de escape de control, y de latencias mayores de CPU (más ciclos de reloj por instrucción de CPU frente a los 32 bits).
• Las ALUs (Arithmetic Logic Units) de 32 bits siempre son más pequeñas y rápidas que las de 64 bits. Más pequeñas implican menos puertas lógicas y menos área de silicio. Esto es un detalle muy importante a considerar cuando se diseña la arquitectura desde cero.
• Las unidades de coma flotante siempre serán de 64 bits, no se reservará espacio de silicio para los de 32 bits porque es un espacio extra inútil de silicio. Habiendo de 64 bits, ¿para qué querer de 32 bits con el inconveniente de peor acuracia con respecto de 64 bits?. En la distribución gausiana, muchas aplicaciones se conforman con sólo usar reales de 64 bits salvo raras excepciones que necesitan precisiones mayores, de 128 bit o mas.
• el banco de coma flotante será aparte y de 8 registros de 64 bits de reales. Es posible haber una variante de 16 registros de 64 bits de reales, pero no conozco mucho que se usa masivamente en las aplicaciones de computación numérica. Su autómata podría ser variado, de pila, de acceso directo al registro, o de movimiento circular de datos/resultados reales en el banco.
• Tampoco se reservará espacio de silicio para los reales de 128 bits porque se asume, según la distribución gausiana, que del 99.99% del tiempo las aplicaciones han ejecutado instrucciones de cálculo de reales de 64 bits, y 0.01% del tiempo de 128 bits. Para no despilfarrar inútilmente el silicio, se recomendará el uso de emulación en software de operaciones de reales de 128 bits, 256 bits, o mas, mejor que en hardware. Tampoco está nada mal seguir así este principio.
• con la evolución de los lenguajes de programación de muy alto nivel, se recomendaría mucho que se asociara a cada palabra de 32 bits un "tag" de 3 o 4 bits con el fin de hacer más eficiente la ejecución de programas desarrollados con dichos lenguajes de programación de muy alto nivel. Dicho "tag" sólo despilfarra un 9% o 11% de memoria, pero ofrece enormes ventajas de ejecución de programas de alto nivel que incluye capacidades de recolección de basura y chequeo de tipos. Deben haber instrucciones adicionales especiales para acceso eficiente de palabras tageadas en función de los valores de los tags. Aunque las palabras internamente son de 35 o 36 bits, las ALUs seguirán siendo de 32 bits y simuladamente de 64 bits.

Ya se ha detallado este computador ecológico del futuro, pero no está dedicado para aplicaciones que se ejecuten puramente de 64 bits (y ningún proceso de 32 bits) a la eficiencia extrema, aunque puede ejecutarlas a un rendimiento ejemplar del 33%. Por eso, debe tener su "computador hermano" aparte puro de 64 bits dedicado para aplicaciones puras de 64 bits, pero no hay mucha gente que usará mucho este tipo de computador.

En la balanza ejemplar, debe haber futuramente en el globo terrestre 99% de computadores ecológicos híbridos de 32 bits y 64 bits, y 1% de computadores hermanos puros de 64 bits.

Hace tiempo, había diseñado un precursor a éste como un computador abstracto para un intérprete y compilador de un lenguaje de programación de alto nivel que estaba desarrollando. Ahora coexisten juntos, este computador ecológico diseñado y mi intérprete-compilador de alto nivel. No tienen sentido irse por separado, los necesitan mutuamente.


Este diseño durará como mínimo siglos. No conozco un diseño ecológico mejor que el que he diseñado para los próximos siglos que se tenga en cuenta la distribución gausiana de las aplicaciones que corran sobre los computadores de dicho diseño.

En caso de que se salieran los computadores ecológicos de este diseño en el mercado entonces estaríamos contentos todos: los fabricantes, los desarrolladores de aplicaciones, los usuarios de tales computadores, los de Greenpeace, los políticos, la sociedad, la humanidad, etc.

Esta publicación ha sido redactada desde España para un mundo más ecológico y eficiente.