Hace 8 años | Por enjoyingbreatht... a xataka.com
Publicado hace 8 años por enjoyingbreathtaking a xataka.com

La arquitectura NAND es la que hace posible el uso de la memoria Flash en tarjetas de memoria, así como en unidades SSD. Este tipo de memoria ofrece muchas ventajas y su precio sigue disminuyendo con el paso del tiempo, el problema es que aun con estas ventajas, es mucho más lenta que la DRAM, que es actualmente la más veloz del mercado, pero también la más cara, además de que es volátil.

Comentarios

Ze7eN

Toranks

La de mi exnovia es 2000 veces más rápida y nadie dice ná

prejudice

#8 Y encima no es nada volatil.

inar

#12 ¿Cómo que no? Si cambia de ánimo cada 2 minutos y salta por los aires a la mínima

sifou

#8 Es que su memoria tiene sectores defectuosos, y sólo conserva los que tú no quieres que se guarde

Lito

Es muy interesante lo que comenta al final del vídeo. Una aplicación práctica de estas memorias es funcionar de manera única como sistema de almacenamiento y como memoria de sistema. Osea, que desaparecerán las RAM como tal y el propio disco ya ofrecerá parte de su capacidad para esta tarea de memoria del sistema. Lo que viene siendo la SWAP pero a un rendimiento de RAM.

Esto lógicamente "obliga" a nuevos sistemas de placas, procesadores? y conectores, pero creo que es una revolución en toda regla.

woodecker

#16 adiós a los tiempos de carga en los videojuegos!

borteixo

Si esto llegase a hacerse viable directamente habria que cambiar la arquitectura de los pc y eliminar la ram

Trigonometrico

#24 Entiendo que los dos decís lo mismo. Ahora habrá una memoria RAM que ya no es sólo RAM, sino que también es almacenamiento. Realmente no se elimina la RAM, pero sí se elimina la RAM clásica.

apetor

#36 Sea la carga de programas, datos o paginación de respaldo ( swap, pagefile, concepto "cache de RAM" en OSX,... ), todos siguen estos cauces:

con disco duro:

- el programa pide al SO, este al sistema de ficheros y este mira si esta en su cache ( RAM ), si no es así se pide al driver de disco y este mira en su cache ( RAM ) y si no esta así se acaba hablando con el canal DMA para preparar la lectura. El hilo queda esperando o si no es una lectura bloqueante sigue haciendo sus cosas y hay una rutina callback a la que se le llamará al completar la lectura.
- el canal DMA ( procesador(es) dedicado(s) ) habla con el disco y va moviendo trocitos ( sectores ) a RAM. Cuando acaba genera una interrupción ( IRQ, sea compartida o no ) que el procesador enruta y despacha y acaba ejecutando la rutina de servicio correspondiente ( ISR que esta ligada o ES DE el driver de disco ).
- la rutina ISR identifica el "fence" o el ID de operación que se ha completado y recorre su lista de lecturas/escrituras pendientes y habla con el driver del sistema de ficheros, llamando a callbacks/etc. del mismo.
- la rutina del driver del sistema de ficheros identifica de que bloques leídos/escritos se trata y procesa los bloques de datos leídos por el canal DMA que están en RAM, compone el stream de datos contiguos y los deja en RAM ( donde el sistema operativo o el propio programa pidió leerlos, depende ). Después completa una operación pendiente o señaliza mediante callbacks, etc. al sistema operativo.
- el sistema operativo recibe esa señal o ejecuta la callback e identifica de que operación se trata y despierta al hilo que quedo esperando o utiliza su mecanismo de llamar a callbacks de modo usuario para notificar al programa que pidió la lectura.

sin disco duro:

- el programa pide al SO, este al sistema de ficheros y este mira si esta en su cache ( RAM ), si no es así se pide al driver de disco y este mira en su cache ( RAM ) y si no esta así se acaba hablando con el canal DMA para preparar la lectura. El hilo queda esperando o si no es una lectura bloqueante sigue haciendo sus cosas y hay una rutina callback a la que se le llamará al completar la lectura.
- el canal DMA ( procesador(es) dedicado(s) ) habla con el disco y va moviendo trocitos ( sectores ) a RAM. Cuando acaba genera una interrupción ( IRQ, sea compartida o no ) que el procesador enruta y despacha y acaba ejecutando la rutina de servicio correspondiente ( ISR que esta ligada o ES DE el driver de disco ).
- la rutina ISR identifica el "fence" o el ID de operación que se ha completado y recorre su lista de lecturas/escrituras pendientes y habla con el driver del sistema de ficheros, llamando a callbacks/etc. del mismo.
- la rutina del driver del sistema de ficheros identifica de que bloques leídos/escritos se trata y procesa los bloques de datos leídos por el canal DMA que están en RAM, compone el stream de datos contiguos y los deja en RAM ( donde el sistema operativo o el propio programa pidió leerlos, depende ). Después completa una operación pendiente o señaliza mediante callbacks, etc. al sistema operativo.

>>> el sistema de ficheros mira la tabla ( copia en RAM ) de control donde tiene las direcciones en RAM donde esta la partición, va ese punto y lee los sectores que antes hubiese pedido al driver de disco pero que ahora solo lee de la RAM, procesa los bloques de datos y compone en otro buffer de la RAM ( que puede ser el buffer del programa que pidió leer los datos u otro buffer intermedio del SO ) el stream contiguo con los datos del fichero.
- el sistema operativo recibe esa señal o ejecuta la callback e identifica de que operación se trata y despierta al hilo que quedo esperando o utiliza su mecanismo de llamar a callbacks de modo usuario para notificar al programa que pidió la lectura.

>>> basta con retornar. Aún se pueden tener mecanismos de dormir el hilo o usar callbacks y hacer las lecturas no bloqueantes, pero empieza a ser absurdo, salvo que la labor de composición del stream lógico del fichero sea complicado... pero es raro. En tal caso podría hacerse con un pool de worker threads trabajando en paralelo.

Quitamos disco. La RAM seguiría funcionando IGUAL IGUAL, sería LA MISMA. Ya que los datos siempre pasan por y a la RAM.

editado:
Si se quiere, por desacoplar capas, se puede tener un driver de disco "sobre RAM", que mantendría la tabla de particiones, puntos de montaje, poco más...

apetor

#39 Existen desde la época de MS-DOS las famosas ramdrives, tipicos de discos de arranque de MS-DOS, Linux o incluso Windows. El matiz ahora es que al usarlas, habría que tener en cuenta desde que dirección de RAM física empezar a mapear los sectores de esa ramdrive, no como antes que se reservaba memoria dinámica sin importar donde. Al desmontar la unidad podría decidirse si descartar cambios o no; en caso de descartar cambios podría dejarse una marca o simplemente no dejar la información de comienzo de la ramdrive en ningún lado o, si la no persistencia de los datos es importante por razones de seguridad, escribir 00s en esos sectores...

La seguridad sí tendría que tener ciertas cosas en cuenta en todo esto, básicamente controlar zonas de memoria... no por que nada cambie en realidad, sino por que los accidentes de acceso a RAM "a la virulé" pueden ser fatales Con no tener los bloques de datos mapeados en memoria virtual ya es mucho. Que sólo el driver de sistema de ficheros o driver de disco "sobre RAM" sepa donde está cada cosa en memoria física y mapee cosas en memoria virtual "on demand" o con ventanas temporales. Si el rendimiento es muy muy muy exigente, se puede tener un proceso o imagen de paginación aislado de todos los demás y hacer la lectura/escritura por IPC ( aunque igual es más caro el caldo que el pollo... ).

E

#36 En realidad, si nos remontamos al origen de la arquitectura, tiene razón.

RAM es la "memoria principal", el direccionamiento directo de la CPU.
El disco es "almacenamiento secundario", necesario por la tecnología pero opcional en la arquitectura: disquetes, compactos, discos duros y SSDs son "secundarios", solo se necesitan por su alta capacidad y por no ser volátiles. Si la RAM fuese no volátil y de alta capacidad perderían su función.

Osea, el prescindible es el disco.

De todas formas, nos estamos dejando llevar por la ciencia ficción, primero que enseñen un prototipo funcionando, luego a ver cual es la tasa de transferencia/latencia/problemática en un escenario real. Ya luego nos hacemos las pajas si acaso.

Trigonometrico

#45 No tengo la intención de corregirte, sino de puntualizar y ver si soy yo el que está equivocado. Si usamos una memoria no volátil SSD muy rápida como SWAP o memoria de intercambio, entiendo que estamos aumentando la RAM del equipo. ¿Puede ser?

E

#58 mmm... diría que no, el efecto práctico hoy día hace que simplifiquemos el "swap" como "RAM extra", pero por debajo no son realmente lo mismo. La diferencia es que lo almacenado en swap necesita recuperarse a RAM (memoria principal) antes de ser utilizado.

Si se usara un SSD muy rápido directamente como memoria del procesador seria exactamente lo que es hoy la RAM y dejaría de comportarse como lo hace hoy un disco.

Refiriéndome por comportamiento al flujo e interacción. La memoria principal "pertenece" a la CPU y esta conectada directamente. La memoria secundaria se comunica a través de buses y no esta en el direccionamiento del procesador.

Por intentar explicarme, si el procesador quiere sumar dos enteros de las celdas 123 y 987, esas celdas tienen correspondencia directa con la RAM (actualmente). Están ahí los dos valores y los suma directamente. En cambio, para hacerlo sobre datos en disco, estos tienen que ser leídos a través de un bus que los pone en las celdas de RAM que el programa reserve, una vez ahí la CPU puede usarlos, y luego enviarlos al bus de nuevo para la escritura a disco.

Si el disco fuese suficientemente rápido, ese paso intermedio con el bus debería ser evitado, haciendo que el procesador maneje sus daros directamente. Tendría entonces el comportamiento de la memoria RAM: dejaría de ser almacenamiento secundario.

De todos modos, como es algo que aún no existe... en funcionamiento si que cambiaría respecto a la RAM actual por no ser volátil. Y estoy obviando todo este tiempo el problema de direccionamiento, ya que las direcciones de CPU tienen precisión de byte no hay direcciones suficientes hoy en día para mover el disco a memoria principal.

Así que, a saber que se haría, un híbrido supongo.

apetor

#60 el problema de direccionamiento existe en x86 ( 32 bits ), pero en x64 no habría problema ( y eso que no puedes direccionar 64 bits, no ya por direccionamiento físico, sino por direccionamiento virtual o ya mapeados para acceder con instrucciones, aún así serían suficientes, de sobra de momento y ampliables en un futuro... ver canonical addresses en x64 ).

E

#62 Cierto, es curioso como se comportan las secuencias exponenciales, hay direcciones de sobra en 64 bits. Pero las CPU comunes aún no utilizan todos los bits de direccionamiento (incluyendo los de dir. virtual). Si saliese hoy esa tecnología y fuese compatible con equipos existentes más de uno se iba a llevar una desilusión con su "procesador de 64 bits".

E

#62 Me está costando encontrar el espacio de direccionamiento físico de los Intel modernos, por lo que ví los primeros x64 (AMD) tenían tan solo 40 bits (1TiB, osea que sumando zonas reservadas o asignadas al hardware si que habría problema).

Sin embargo, para los Intel modernos me está costando encontrar la cifra, sospecho que estarán en 48 todavía, como hace un par de años (256 PiB, no tendrán motivos para ampliarlo todavía y si bastantes problemas)

apetor

#62 Ahora mismo el límite de direccionamiento físico son son 256TB, 48 bits de bus de direcciones, pero... esto es a nivel de arquitectura o procesador, luego hay otros limites en el chipset. Si te fijas en el formato de las tablas de paginas de long mode o x64 normal, PAE64, las entradas son de 64bits de las cuales 12bits son espacio para flags como siempre, eso nos deja posibilidad de crecer desde esos 48 bits hasta 52 bits, 4 bits mas o 16 veces mas >>> 2^4*2^48 = 2^52 = 16*256TB = 4096TB = 4PB, si no me equivoco.

Tenemos para rato, incluso con 256TB, contando requisitos de RAM y sobre todo de "disco" o almacenamiento.

E

#65 El fallo es mío, que puse "direccionamiento físico" cuando quise decir "virtual" (Aunque siempre me pregunté que validez tiene hablar de un espacio de direcciones físico más grande que el virtual).

Tenemos para rato con 256TB pero, como dices, aún queda que realmente las placas soporten tal.

Volviendo al tema de la noticia, quisiera dejar constancia de que un anuncio como "hasta 1000 veces más rápido que la memoria NAND" suele querer decir "casi 1000 veces más rápido que la peor NAND que hemos encontrado", lo cual no es más rápido que la RAM actual como muchos están dando por hecho. Aún queda para la extinción del disco duro (la fusión con memoria principal), si es que se llega a dar.

apetor

#67 Un espacio de direcciones físicas más grande que el espacio de direccionamiento virtual es algo relativamente normal o típico. En realidad en x86, 32 bits, ya ha existido, tanto con paginación antigua o NO PAE con la extensión PSE-36 como con PAE. A nivel de uso normal o para programas y demás, esto se traduce al "address windowing"; Un programa ( bases de datos o programas de simulacion, etc. ) pide memoria al kernel del SO y este, con PSE-36 ( usando big pages de 4MB con una base direccionada con 36 bits, un poco triquiñuela/ñapa ) o con PAE ( ya en condiciones, ya que las entradas de paginación con PAE son de 64 bits y pueden poner más bits de direccionamiento para apuntar a la base de la página ), mapea memoria en una "ventana" donde el programa lo usa por un tiempo y luego puede desmapearlo y mapear otro banco de memoria en ese espacio de direcciones virtuales. En NT se conoce por las APIs de AWE ( address windowing extensions ).

E

#68 Sé que es típico, la pregunta es "qué sentido tiene". Luego pasas a explicar el funcionamiento de la memoria paginada y las ventanas, que está bien pero no me explica qué validez tiene tener un espacio físico más amplio que el virtual.

Para que nos entendamos, eso quiere decir que el procesador puede tener un millón de direcciones y la memoria cuatro. No lo veo, como mucho el procesador podrá diferenciar direcciones según si son kernel o usuario (un bit), pero el número de direcciones físicas utilizadas (el número de páginas/segmentos físicas) no pueden ser mayores que las virtuales que ve el sistema operativo, porque no puede hacer referencia a ellas.

[Bueno, el modo visual no sirve en menéame, que no veo como poner texto monoespaciado, puedes copiártelo a un programa de texto para verlo]
Fís: |-kern-|------|--1--|----3|----|-2-|-------
Vir: |-kern-||--1--3||-2-|----*espacio perdido* (en el espacio perdido no se puede guardar nada, porque no hay direcciones virtuales para él, entonces da igual tener más direcciones físicas).

Hace tiempo que estudié y vi como era todo eso, supongo que me estoy confundiendo en algo.

apetor

#69 Sí que sirve. Si estas usando, por un decir, un rango de direcciones de 256MB en tu proceso y en ese rango mapeas en un momento dado 256MB de memoria física, las usas un tiempo y después mapeas otros 256MB de memoria física, y así.

El caso es que, vale, sólo tienes 256MB mapeados en cada momento, pero puedes acceder a 256MB*N, por ejemplo 4GBs, mapeando 256MB cada vez. Rara vez se requiere acceso a todos los datos en todo momento y todo o casi todo escenario/necesidad es solucionable programáticamente, con una buena librería que te lo abstraiga, funcione como cache, etc. y el rendimiento no se degrada demasiado.

La idea es seguir con arquitectura de 32 bits ( poco a poco se migra todo a x64, pero hay mucho software cuya compatibilidad hay que mantener y cuesta tiempo/dinero adaptar todo a x64 ) y cambiar lo justo en cierto software de gran demanda de memoria para que maneje mucha RAM, aunque sea con windowing.

apetor

#62, perdón, no ha sido una explicación correcta del todo O:D Lo pongo aquí por que me ha dado un error al editar y ya no me deja editarlo:

editado:
No he sido muy certero, o no muy riguroso. esos 48 a 52 bits en realidad no están limitados por los 12 bits de flags de siempre, ya que como siempre se apunta a celdas de 4K ( o mayores si son big pages, etc. ) esos 12bits no se pierden, se concatenan 12 bits a 0 en los bits mas bajos. De ahí tenemos que son del bit 12 ( 0 a 11 son flags ) hasta el bit 51 están reservados para dirección física, recordando que apuntamos concatenando 12 bits a 0s debajo, serian 52 bits de dirección física, con los 12 bits de menos peso forzados a 0, de ahí que se apunte siempre a direcciones alineadas a 4K. Bien, esos 52bits son el límite fijado por AMD64 o límite arquitectural, pero como decimos ahora se usan menos, hasta 48. En realidad tendríamos del bit 52 al 63 para meter más bits de dirección, peeero, esta el bit NX ( para marcar páginas como no ejecutables, para defendernos contra buffer overflows... ) en ese bit 63, así que tendríamos de 52 a 62, 10 bits más, vamos, direcciones físicas de hasta 63 bits, aunque AMD fijo el límite en 52 y ese es el tope. Probablemente AMD penso que 52 bits ya era la hostia padre de direccionamiento físico y prefirió marcarlo así y dejar los bits altos para futuros flags/indices/uso para el SO/...

borteixo

#24 qué quisquillosos estamos..

anv

La tecnología que usa 3D Xpoint es posible gracias a que omite el uso de transistores, basándose exclusivamente en un material que es capaz de cambiar los bits de baja resistencia a un estado de alta resistencia.

Hace años que se habla de los memristores. Lo que más me interesa es cuándo tendrán algo funcional a la venta y qué precio le pondrán. Ya sabemos que será barato fabricarlos pero también sabemos que no cobran por lo que cuesta fabricarlos sino por la novedad, por las patentes, etc.

sorrillo

#13 Cobran también para financiar la inversión que han hecho en investigación y desarrollo.

anv

#15 Sí, sí. Ya se... el resultado final es que tienen un producto que cuesta fabricarlo 0,1 y se vende por 1000, y con los años cuando tienen productos nuevos el precio va bajando poco a poco hasta los 10.

Yo con gusto en lugar de darle 150 mil millones a los bancos, le daría mil millones a Intel para pagarles lo que les haya costado la investigación, a cambio de que desde el primer día vendieran a 10 en lugar a 1000. ¿Te imaginas el empujón que daría al desarrollo tecnológico el tener a nuestra disposición una tecnología revolucionaria sin pagarla a precio sólo accesible a los ricos? A demás, Intel recuperaría su inversión toda de golpe en lugar de tener que esperar décadas, y podría invertir ese dinero en desarrollar otro producto revolucionario.

sorrillo

#17 Aunque no queda duda que regalarles 150 mil millones les ayudaría no es menos cierto que hay partes del proceso que no mejoran con inyecciones de dinero, si no que requieren tiempo y experiencia. Con las primeras versiones que pongan en venta seguirán optimizando los procesos de producción y el producto. Lo que ahora son retos de máximo nivel necesita de ciertos años de experiencia para que pasen a ser procesos comunes y que no requieran mayor atención. Y por lo tanto más eficientes económicamente.

PythonMan8

#17 Bueno, eso no va a pasar, pero Intel continua necesitando dinero para seguir evolucionando. De momento les puedes financiar comprándote un disco SSD para tu PC y ya de paso te haces un favor a ti mismo. (O si no es de Intel, de Samsung o cualquier otro).

http://www.amazon.es/s/ref=nb_sb_ss_c_0_9?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&url=search-alias%3Delectronics&field-keywords=intel+ssd&sprefix=Intel+SSD%2Caps%2C492

anv

#29 Lamentablemente a mi no me sobra el dinero para pagar cosas caras. El día que un disco SSD tenga una capacidad razonable y un precio razonable, seguramente no dudaré en comprarlo. Y seguramente en ese momento ya tendrán discos con memristores mucho más rápidos y duraderos, pero que tampoco podré comprar por su elevado precio... En fin, es lo que tiene ser pobre...

difusion

#13 The Machine: A new kind of computer 🔗 http://www.hpl.hp.com/research/systems-research/themachine/

D

Esto va a ser un cambio de paradigma importante. El diseño es fascinantemente sencillo, lo cual es la causa de esa enorme rapidez. Por fin vamos a disponer de ordenadores y móviles en los que cargue el sistema operativo al segundo de pulsar el botón de inicio. Es probable que tengan menos calentamiento, que faciliten mayor autonomía de baterías y el funcionamiento general de los dispositivos va a ser mucho más fluido. Al ser mucho más fáciles de construir los costes de la memoria bajarán muchísimo.

D

#30 "1000 veces más rápida" es el tope, no significa que tengas que utilizarla necesariamente a esa velocidad.

PythonMan8

#30 Toma, pues allí va el mio, para que tengas una batallita que contar a tus nietos.

D

#31 hahaha gracias men... que dios te lo pague con memorias 1000 veces mas rapidas!

D

#11 Quienes hacen estos desarrollos precisamente lo hacen pensando en tecnologías futuras, es gracias a ellos que va mejorando la tecnología, sino no tendríamos ssd, seguiríamos usando dims, no existiría el pci express, los sata, tecnologías inalámbricas, etc. Además como ya dijeron este desarrollo disminuye los costos, con lo que la mejora en los equipos puede que se vean más pronto que tarde.

kesar

La de mi novia

D

Ya era hora de ponernos las pilas con la velocidad de almacenamiento, que no todo van a ser gigas. Hasta los ssd las alternativas eran prehistóricos tocadiscos magnéticos. Pon un ssd en tu vida ;D

Maki_

#20 Ahora a los SSD les falta... capacidad de almacenamiento. Y que se abaraten.

Nova6K0

Mientras no tenga las limitaciones (del número de veces de lectura/escritura en cada celda) de la memoria Flash, todo va bien...

Salu2

A

#51 Tienes razón. Estaba empecinado en sacarlo de la esquina.

Gracias por compensar el negativo

A

#47 Te vas por las ramas.

Las DDR que usan las gráficas de las PCI-E también eran chips distintos a las DDR que usaban los AGP. Como superaban el máximo ancho de banda se tuvieron que mudar a una nueva arquitectura igual que, cuando esté desarrollado a nivel comercial, tendrán que hacer con estos chips.

De lo que parece que no te enteras es de que primero va la investigación, que es de lo que habla el artículo, y luego va el desarrollo comercial, que es en lo que estás atascado tú.

Lo del "zas" denota tu edad (mental, al menos) y no me molesta, pero lo del negativo no lo entiendo.

D

#50 Don't feed the cuñao.

No deja de decir chorradas que ni siquiera vienen a cuento y encima se marca el rollito masterclass...

borteixo

Están muy bien estas meadas fuera del tiesto para subir la cotización en bolsa

A

#30 Ni una arquitectura que aprovechase las memorias más rápidas valdría para nada sin dichas memorias.

Una vez metidos en la pescadilla que se muerde la cola, o lo inventamos todo a la vez o nos quedamos como estamos, ¿no?

D

#38 Hombre lo normal es que la technologia venga con soporte. No hubo graficas PCI-e hasta que el mismo puerto fue integrado en las placas base. Intenta enchufar esas memorias en un SATA y me cuentas.

A

#44 Debe ser eso, que hasta que no vieron una placa con un PCI-E en la tienda, a los de Nvidia y ATI/AMD no se les ocurrió sacar una tarjeta que lo aprovechara.

Estos de Intel es que van de listos y se les ocurre investigar en cosas que no puede uno poner en ninguna placa del pccomponentes...

Perdón por la ironía.

D

#46 La ironia sobraba, pero te la acepto.
De lo que no te das cuenta q han desarrollado un chip de memoria mas rapido, no un interface como SATA.

Perdon por el... ZaS! En toda la boca!

ermegabait

Vale perfecto, pero aun sigo esperando tener un ordenador que planche, limpie y cocine por mi

rednoise

Y cuando la hagan de grafeno te vas a cagar.

D

Decir que es más rápida aunque no tanto como una DRAM es como decir que un Ferrari es más rápido aunque no tanto como un avión a reacción. El objetivo y medios de cada uno son diferentes.

D

Hoy en dia no necesitamos mas velocidad, necesitmaos mas capacidad.

D

#2 El problema esta en los cuellos de botella. Una memoria 1000 veces mas rapida seria inviable en los sistemas actuales.

Campechano

#4 Cierto. Obviamente la velocidad de un sistema va a ser la de su componente más lento

ccguy

#1 Alguien habrá a quien le se ocurra que hacer con memorias mil veces más rápidas aunque no seas tú

D

#10 Si yo no he dicho que no sean utiles. Solo que no se pueden aplicar a los equipamientos actuales. Vamos que no las disfrutaremos hasta dentro de bastante.
Por otro lado es un hecho que estamos consumiendo mas memoria de la que seremos capaces de producir en un futuro con las tecnologias actuales.

PythonMan8

#1 Se nota que no trabajas con Java.

D

#27 Dios! me estan cosiendo a negativos solo por decir una obviedad. Una memoria 1000 veces mas rapida no sirve de nada en las placas bases actuales.

difusion

#1 Más MTBF, más seguridad y mayor capacidad; la velocidad tampoco está de más.

E

#1 Hay equipos que utilizan unidades SSD redundantes para aumentar la velocidad y aún así el almacenamiento supone un gran cuello de botella para sus requerimientos.

Y de todas formas, no se que necesidad hay de valorar esta noticia frente a la arquitectura PC actual. Si no es aún ni un prototipo anunciado.

D

#1 Precisamente el mayor problema al que se enfrenta cualquier sistema hoy en día, por pequeño que sea, es la bajísima velocidad del almacenamiento. Hasta para montar un pequeño blog hay que estar haciendo mil viguerías con compresiones y cachés, y ahora resulta que "no necesitamos más velocidad".

PD: Cuentale eso a cualquier proveedor de servicios SaaS o a cualquiera que alquile servidores, a ver que cara pone. Que no dan a basto con la demanda de servidores con 60GB en SSD y los que tienen con 2TB en discos duros muertos de risa porque la gente no los quiere para nada...

nergeia

#1 Increible la cantidad de negativos que te han caido por expresar una opinión válida... En fin.

D

#1 Creo que te equivocas enormemente. Quizá tu no sepas aprovechar la velocidad ni la capacidad. KVM, OpenVZ, VDS, Live Streaming, Casting....

D

#71 jejej parece que estoy hablando con un foro lleno de administradores de servidores... a nivel de usuario, un chip para almacenamiento (no ramdon access) de mas velocidad no tiene cabida en las placas bases actuales. En cambio se sabe que si no conseguimos mayor almacenamiento dentro de poco estaremos usando mas de el que somo capaces de producir.

Eso era lo unico que queria expresar, la gente se vuelve como loca por una opinion... Cerca de 19 negativos, que tonteria!

Esta noticia tiene ya mas de 2 meses...