Libertonia || Comments || 64 bits, ¿para quién?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

64 bits, ¿para quién? | 36 comentarios (36 temáticos, editoriales, 0 ocultos)

Sobre la explicación "más correcta" (none / 0) (#24)
por shamkao a las Tue Nov 15th, 2005 at 05:24:40 PM CET
(Información Usuario)

No es por seguir echando leña al fuego, pero creo que jorginius también a cometido errores básicos de esos que te achacaba a tí.

[ Padre ]

Ahí voy (5.00 / 1) (#28)
por shamkao a las Tue Nov 15th, 2005 at 10:00:26 PM CET
(Información Usuario)

Antes no he puesto las cosas que consideraba que no estaban del todo correctas, porque estaba en el curro.

Con unos conocimientos a nivel de EGB se puede plantear un primer contacto con el problema. Si los transistores son cada vez más pequeños entonces los "cables" que los conectan entre sí tienen que ser más pequeños también. La resistencia de un conductor es inversamente proporcional a su sección, luego la resistencia en los cables según hacemos transistores más pequeños es mayor lo que se traduce en que la señal e propaga más lentamente por esos cables.

Podríamos pensar en, ya que tenemos que hacerlos estrechos, hagamos más grande la sección haciéndolos más altos. Esto tampoco funciona porque al final te encuentras con que tienes "placas" conductoras paralelas, es decir: hay efecto de capacidad (condensación) que además va a peor según aumentamos la frecuencia.

Esto es correcto, pero me gustaría ampliarlo. No sólo tienes esa capacidad, sino que aparecen capacidades parásitas entre las distintas patas del transistor, más molestas aún. Además de degradar la respuesta a altas frecuencias, disparan el consumo de los circuitos (Corrientes de fugas). Un objetivo de la miniaturización es que los transistores y por extensión los circuitos electrónicos consuman menos, pero a medida que vamos aumentando la frecuencia a la que trabajan, las corrientes de fuga debidas a las capacidades parásitas, son más importantes.

Otro problema importante es la propagación de la señal de reloj en un circuito complejo con varias unidades lógicas. Puesto que los circuitos en una CPU típica son síncronos, es importante que los flancos de reloj se den en todos los puntos del circuito al mismo tiempo, o, que al menos se haya tenido en cuenta este efecto.

No sólo la propagación de las señales limita la frecuencia máxima de funcionamiento de una CPU, también tenemos los tiempos de procesamiento de cada uno de los circuitos. Su efecto puede ser más o menos importante dependiendo del circuito, por ejemplo, una ALU con acarreo anticipado para sumas y multiplicaciones, puede ahorrar una cantidad de tiempo muy importante (aunque haya introducido más circuitería) respecto a una con un diseño básico y más simple en la que no hay circuitería adicional. Uno de los efectos positivos de la miniaturización, es el hecho de que nos permite insertar más circuitería en un sólo chip. Esta circuitería puede usarse para ahorrar tiempo (como en el caso de la ALU) y de este modo poder aumentar la frecuencia de reloj, o para realizar más operaciones en paralelo y así incrementar el número de instrucciones por ciclo de reloj (un ejemplo típico son las unidades de operaciones vectoriales).

La potencia consumida por un circuito es proporcional al voltaje utilizado , la capacidad, y la frecuencia de trabajo. La miniaturización favorece una reducción del voltaje, y si se diseñan bien las células lógicas, pueden disminuir las capacidades. Como efectos secundarios, pueden darse un aumento de la resistencia de los transistores (por lo tanto aumenta el calor por efecto Joule) y los efectos de las corrientes de fugas, además de que al estar más juntos, la disipación del calor es peor.

Hay que tener en cuenta, que la energía que consume un circuito, en su mayor parte, va destinada a mover los electrones de un lado a otro. En este movimiento de electrones, gran parte se transforma en calor. [opinión personal] Por eso, considero que las CPUs que priman en su diseño la eficiencia por ciclo de reloj para conseguir incrementar la capacidad de cómputo son mejores que los que centran en incrementar la potencia de procesamiento a base exclusivamente de incrementos de la frecuencia de reloj [/opinión personal]. Por eso, los 64 bits permiten conseguir un incremento de la capacidad de cálculo, puesto que se a añadido circuitería para aumentar la eficiencia por ciclo de reloj.

[ Padre ]

Puntualización sobre la velocidad (none / 0) (#29)
por jorginius ("jorginius" en Google Mail) a las Wed Nov 16th, 2005 at 02:25:07 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

La velocidad de propagación de una señal radioelectrica no depende de la resistencia total del cable.

Dicha velocidad es constante y sólo depende del tipo de material, ya que la velocidad de una onda electromagnética es igual a: 1/(conductividad * permeabilidad_magnética)

Bueno, si nos vamos a poner así... :-) La velocidad de propagación es proporcional a la raíz cuadrada inversa de la constante dieléctrica. La constante dieléctrica no sólo depende del material sino también de la frecuencia y de la temperatura.

Tienes razón en que es un poco columpiarse hablar aquí de resistencia pero las dimensiones sí que influyen en la velocidad de propagación. Según nos acercamos a las dimensiones críticas la resistividad crece exponencialmente por el descenso de la movilidad de los electrones debido, entre otros factores, a la dispersión superficial.

Si la resisitividad está aumentando y la capacitancia se mantiene entonces el retardo en los cables no hace más que aumentar a pesar de que cada vez sean más cortos.

Se me ocurrió tirar de la ley de Ohm para explicar de forma sencilla por la relación entre el tamaño y la resistencia y entre resistencia y resisitividad pero quizás fue un poco abusar. Perdón, perdón.

Sobre lo demás no hay nada que objetar.

Por cierto, cambiando de tema y viendo lo que ha pasado... Las versión de Scoop que usa kuro5hin permite ediciones en la cola de envíos. Estaría bien tener en libertonia para retocar los artículos "por consenso" antes de sacarlos X-). Ahora, si hay que cambiar algo, dependemos de algún BOFH buen samaritano.

Es más, yo no sigo el desarrollo de Scoop demasiado pero hace tiempo leí en alguna parte que estaban trabajando para permitir ediciones colaborativas, en plan wiki: el autor del artículo podía dar permisos de edición del mismo (mientras estuviese en la cola) a quien él quisiera. Eso estaría chulo: cada uno podría aportar algo a los artículos antes de sacarlos a portada.

Lo pondré en mi carta de los reyes magos, a ver si hay suerte :-)

[ Padre ]

Donde digo raíz cuadrada inversa... (none / 0) (#30)
por jorginius ("jorginius" en Google Mail) a las Wed Nov 16th, 2005 at 02:31:18 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Es inversa de la raíz cuadrada, que aquí hay que andarse con pies de plomo X-D

[ Padre ]

¡Ay pallo, ese BOFH buen samaritaaanoooo! (none / 0) (#31)
por iarenaza a las Wed Nov 16th, 2005 at 01:13:22 PM CET
(Información Usuario) http://www.escomposlinux.org/

Por cierto, cambiando de tema y viendo lo que ha pasado... Las versión de Scoop que usa kuro5hin permite ediciones en la cola de envíos. Estaría bien tener en libertonia para retocar los artículos "por consenso" antes de sacarlos X-). Ahora, si hay que cambiar algo, dependemos de algún BOFH buen samaritano.

Me temo que la política actual del sitio respecto al código de Scoop es la de deep freeze (o si se prefiere, completely frozen).

Este humilde administrador que escribe no tiene ni el tiempo ni el ánimo para meterle mano al bicho y saltar a la versión actual de Scoop. Primero (pero menos problemático) porque hemos hecho cambios locales que tendríamos que (posiblemente) portar a la versión actual. Y segundo, y más peliagudo y costoso en tiempo, porque migrar los datos de los usuarios, historias, comentarios y demás habría que hacerlo con lupa (la última vez que miré este tema, los chicos de kuro5hin.org no tenían herramientas para hacer todo eso de forma automatizada y confiable).

Claro que si algun valiente se anima y las mejoras realmene van a merecer la pena el esfuerzo...

Saludos. Iñaki.

[ Padre ]

Acabo de ver la falta de ortografía (none / 0) (#25)
por shamkao a las Tue Nov 15th, 2005 at 05:26:23 PM CET
(Información Usuario)

No tiene perdón ese ha cometido

[ Padre ]

¿Puedes corregirlos? (none / 0) (#26)
por man ls a las Tue Nov 15th, 2005 at 06:00:13 PM CET
(Información Usuario)

Estaría bien que dieras una explicación más correcta entonces. Es la única manera de enterarnos de si tienes razón.

[ Padre ]

Que yo vea... (none / 0) (#27)
por jorginius ("jorginius" en Google Mail) a las Tue Nov 15th, 2005 at 06:17:08 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hay un columpio con lo de TTL. Si hay otros corrígelos por favor.

[ Padre ]

64 bits, ¿para quién? | 36 comentarios (36 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda