Hace 6 años | Por un_tardigrado a nmas1.org
Publicado hace 6 años por un_tardigrado a nmas1.org

Un ordenador cuántico capaz de superar la performance de las computadoras clásicas para resolver una gran cantidad de problemas sigue siendo el mayor objetivo de ingenieros, investigadores y programadores en todo el mundo. En esa carrera, dos grupos de científicos han dado sólidos pasos al lograr algunos de los más grandes y potentes simuladores cuánticos nunca antes construidos.

Comentarios

D

#1
la gente normalmente entiende por perfomance una acción artística
Espectáculo.

D

#1 #3 La verdad es que según quien, la suelen usar para lo que mejor les parece. No digo que sea el caso de #0 , pero normalmente la usan por no pararse 2 segundos a buscar la palabra correcta en castellano.

m

#1: Teniendo en cuenta que muchas de estas noticias son fantasmadas... mal empleada no está.

w

#6 -... son carne de Consultant Manager .....les sueltas unas siglas y unos cuantos terminos en imperial...y ya estan contentos

Saludos

TarekJor

#9 Cuando escucho consultant, manager, o "advisor", me pongo en modo alerta...
Como cuando escucho abogado, banquero o "notario".

Cuando escucho "performance" en vez de Rendimiento, por desgracia, pienso que la redacción no es seria.

Los Anglicismos en algún contexto, son "tolerables" por poner un ejemplo:

"petición de cambio" (pull request) en Git, Control de Versiones etc

O "cloud cluster" (racimo-nube) (puff)

"términos en imperial" => De Cyrodill o de "Star Wars"? lol

w

#10 "términos en imperial" => De Cyrodill o de "Star Wars"? De Ingles a secas

Saludos

TarekJor

#13 lol jajaja no estuve fino
Imperial, con Acento British, de Londres, área pija, barbilla ligeramente "alta"

garnok

#10 millas pies y galones

TarekJor

#18 Pies sin duda lol

D

#1 La gente en general no tiene ni puta idea de casi nada, performance esta bien.

F

#11 Me gustaría saber más sobre computación cuántica, pero la verdad es que no tengo ni idea. Y eso que trabajo en arquitectura de computadores, pero llega un momento que uno no puede abarcar tantas cosas lol.

Que la computación cuántica llegará al usuario, no lo dudo, pero soy bastante escéptico con los plazos tan optimistas que dan algunas compañías como IBM.

Entre otras razones, por la programación del sistema. Por mucha potencia de cómputo que ofrezca tu ordenador, de nada sirve si no tienes gente que sepa programar bien en esa arquitectura y te pueda ofrecer un software con un mínimo de calidad.

Eso le paso al chip Cell (orientado a HPC y que empleaba la PS3) de IBM, por ejemplo. Ofrecía una gran potencia de cómputo, pero debido a su arquitectura era muy difícil de programar. Y por eso fue un fiasco en el mercado HPC. Era preferible adquirir multiprocesadores x86-64/amd64 para tu servidor, aunque fueran menos potentes que Cell, porque los programadores desarrollarían un software con mas rendimiento en una arquitectura bien conocida que programando en una arquitectura mas potente con la que nunca han trabajado.

Por eso creo que Sony se ha dejado de experimentos y en su PS4 han apostado por una arquitectura x86-64 lol.

Ahora, esto es mi humilde opinión. La computación cuántica es un cambio de paradigma muy grande y que desconozco por completo, por lo que igual mi opinión es totalmente erronea.

TarekJor

#c-21" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2868438/order/21">#21 estoy en una situación parecida próximo a Computación, más de la parte de Programación, IA y demás pero estoy pez en este tema (por lo mismo, no se puede abarcar todo), y quiero hacerlo bien.

Sobre IBM, tienen a grandes mentes contratadas, pero no me fío tampoco, el celo con el que llevan a IBM Watson lol (uff) ese Big Data Centralizado (El Gran Dato Orwelliano), la IA distribuída y transparente "hoygan" (paranoias a parte molaría)

Cierto sobre "no tienes gente que sepa programar bien en esa arquitectura."

Yo me dedico "a alto nivel" porque en IA, manejamos "ontología" objetos y demás, de hecho programo casi en pseudocódigo, en realidad en IA no se necesita tanto rendimiento "per se", aunque hay de todo (depende el grado de Aprendizaje automático), utilizo Programación Funcional, y Orientada a Objetos (Scala, Prolog, Haskell, y F# y luego los típicos), me mola Rust, y Go (algo he probado)

Me interesa arquitectura, ahora que lo comentas para clústers, distribución, Escalabilidad, pero sería para correr código a bastante alto nivel, obviamente una IA necesita mucha abstracción (y eso es muy bueno para el Programador humano)

Por ejemplo para "cosas muy formales" utilizo C++ o F# combinado con C#, pero Python, Perl, menos ma que soy bastante "Orden en Caos" por relación, porque tendría un "guirigay" flipante.

Gracias por el comentario, es muy interesante conocer a alguien que esté estudiando Arquitecturas (yo en Realidad soy Ingeniero Industrial, Automática-Mecánica-Energía, pero me mola mucho la Programación de IA, Ciencias de la Información (aprendizaje automático, Conocimiento etc)

ARM por ejemplo tiene menor "consumo" (TDP) que x86 he visto algún "clúster" trabajando bastante bien.

Como ves a AMD con Ryzen y sus nuevas APU con Ryzen + GPU Vega? (creo que se presentan antes de finales de año, tienen buena pinta, Intel lleva "sola" muchos años, y sacando refritos.

Otra cosa es la "famosa" ley de Moore, yo con intuición (quizas equivocado), pienso que empieza a haber un problema en x86 (con la Durabilidad de Componentes ante Miniaturización) y que a menos nm (Nanómetros), menor "distancia" hay para disipar luego "hay algún tipo de límite rendimiento-eficiencia y pérdida de calor, menos durabilidad de componentes)

Eso y que las memorias flash (SSD, eMMC, UFS, tienen ciclos de lecturas escrituras) que en mi caso son 3-4 años como muchos (móviles que mueren de viejos, por Obsolescencia Programada, o no pero imagino que sí)

No me he metido a bajo nivel (jamás) os considero magos-prestidigitadores (algún día me molaría aprender arquitecturas igual tengo una idea feliz de esas jajaja) lol los que manejáis C, y otros (sinceramente), y eso que he manejado C, o detalles para firmware, sois "magos", yo necesito mis objetos y mis abstracciones ^^

A nivel de arquitectura crees que la Miniaturización en x86 o en ARM (tiene un límite físico cercano?), de momento en consumo estamos en 14nm, 10nm, lo que se está investigando y probando debe ir por 5nm ( o así) que opinas sobre eso...

Y sobre servidores, por ejemplo, mi idea es conseguir un clúster con baja latencia 128GB de RAM como cache de datos, y varios TB de SSD ( el procesador sería un entorno virtual con varios Xeon )

Sería para "IA" y Software como Servicio, la cuestión es la siguiente, de momento hago pruebas con VPS (reguleros" porque no hay "necesidad", pero en el futuro tendría que disponer de "alta Escalabilidad" para más recursos (obviamente es un servicio con usuarios), se pagaría "sobre la marcha", pero que tipo de servidor necesito, no "se mucho de la parte Hardware-server" y tendría que poder gestionar picos de CPU y IOPs (para evitar el colapso), que "empresas" se dedican a ofrecer un hosting muy serio para aplicaciones web "en tiempo real" y muy baja latencia, y su seriedad (sistema anti DDoS, copias de Seguridad)

He mirado bastante y aparecen las grandes (pero buff, la Neutralidad de la Red, y eso), imaginate que dependo de Amazon AWS, o de Google Cloud (y saco algo "sospechoso") como les pasó a los de ProtonMail...

Si conoces alguna recomendación de servidores también me podría plantear "comprarlo directamente" e intalarlo en una "granja de terceros" (da igual el dinero, es una hipótesis ).

Un saludo

F

#22 woo, wooo, wooo, madre mía, no esperaba tantas preguntas.

Tenía que haber sido más especifico: llevo años trabajando en arquitecturas y hasta tengo un doctorado... el problema es que mi especialidad son las arquitecturas de switches de altas prestaciones. De eso te puedo hablar largo y tendido, pero de arquitectura de procesadores, mis conocimientos son bastante normales. Aunque podría tirarme el rollo y seguramente nadie me descubriría .

Si no recuerdo mal, ahora mismo se están comercializando chips de 22 y 14nm... Si Intel ya esta comercializando hardware de 10nm, debe ser algo muy, muy reciente. Al final, los límites los impondrá los límites físicos de la materia. La disipación de calor es un problema importante, pero poco a poco se van solventando esos problemas, ya sea por mejoras en la tecnología, nuevas soluciones arquitectónicas, nuevos sistemas de refrigeración, etc. De nuevo, este campo está a más bajo nivel de mi especialidad. Es la putada del doctorado, que sueles acabar sabiendo mucho de una sola cosa, pero fuera de ahí, pues normalito lol.

De programación, no me saques de C, que me pierdo. De hecho, has nombrado lenguajes que ni siquiera sabía que existían.

Sobre los servidores, no me atrevería a decir nada sin tener una buena especificación del software que vas a ejecutar. Y más viendo, en base a tu comentario, que estaría dedicado a ejecutar un software en exclusiva. Si no he entendido mal, debería estar más orientado a data-center que a cluster HPC (de nuevo, fuera de mi campo de trabajo , aunque están estrechamente relacionados). De todas formas, lo que comentas sobre gestionar picos de CPU y IOPS, influirá mucho el software que utilices, como el repartidor de carga. Aunque evidentemente, si empleas soluciones cutres, no se, por ejemplo, usar un NFS sobre Fast-Ethernet (o incluso GigaEthernet), pues el repartidor de carga no puede hacer milagros lol.

En fin, siento no se el especialista que necesitas cry .

TarekJor

#23 #22 woo, wooo, wooo, madre mía, no esperaba tantas preguntas.
LO siento, son las Locuras que llevo a veces , al contrario, gracias por responder.

Sobre el Doctorado (quizás haga máster en Energía, porque voy por otros derroteros), y veo que "a lo autodidacta" voy sacando cosas (y eso me motiva mucho), (Rebelde JAAA!!!)

Sobre esto "son las arquitecturas de switches de altas prestaciones" es muy muy interesante por aclarar con switches te refieres a Escalabilidad de Redes (Rendimiento en Transferencia de info vamos), lo que sería más de Telecomunicaciones que de Ingeniería Informática (que están totalmente relacionados eso sí)

Si sobre la Miniaturización, yo pienso que (al menos por lo que veo), en x86 (no tienen mucha prisa por quemar cartuchos), en lo "casero" tiro de ARM o APU x86, para server mío (digamos poca concurrencia, virtualización, y pruebas, me basta y me sobra, la verdad, LAN por Ethernet al máximo con un buen router Asus (con firmware libre), que si bien no es el mejor, he comparado y buscado y por lo que me costo va de lujo, además tiene muchos firmwares y soporte (porque lo tiene bastante gente); eso seguro que es más tu campo...

En plan amateur, pero bastante serio lol

Pero como jamás osaría abusar, de la asesoría, cualquier día que tengas tiempo, intercambiamos unos comentarios concretos, sin fallo (y si no no pasa nada), que tendrás mejores cosas que hacer que "hacer de consultor" para un "usuario medio" lol

Puff, a mi al contrario, C, es como (Dios, dadme algo de Asúcar, (sintáctico), no, asúcar no), es como muy "oscuro" tienes que controlar muchas cosas (que en otros no tienes) (cosas de Optimización a nivel de arquitectura, compilador, algoritmos y rendimiento)...

En C++ algo he hecho o con MatLab, pero sobre "sintaxis" utilizo preProcesadores para Java (que utilizan simplificación por árbol, para ahorrarse corchetes y cosas que se pueden abstraer como "sangrías" (la llamada "indentation"), pero vamos me molo el tema de los Lenguajes, porque me moló Wolfram Alpha Language, y mi idea es terminar Programando casi en Lenguaje Natural (en plan Jarvis y Iron Man), co IA y Ontologías se puede (pero bueno no me fliparé... todavía) la cosa marcha bien eso sí.

Me he dado cuenta que una vez "abstraído" el Algoritmo, en un Lenguaje de "alto nivel", puedo refactorizarlo y llevarlo a C++ o incluso a Erlang (que estoy aprendiendo por el tema de Concurrencia (Ricardo Galli, uno de los fundadores de Menéame, tiene un libro en español, sobre Concurrencia, me lo pillé lo tengo en pendientes, WhatsApp se programó en Erlang (no sé ahora), pero me parece un buen Lenguaje para según que cosas, por lo que he visto, y es similar a otros.

Sobre el último párrafo (es más tu campo sin duda), ahí voy algo pez

... Especificación del software que vas a ejecutar:
(no lo tengo totalmente decidido, porque todavía me falta un tiempo, y aprender más)

- Pues sería por una parte un servidor de "estáticos" muy pequeños pero de gran carga de trabajo (1mb como mucho cada uno)

- Un servidor sólo para el "Data Mining", en tiempo real (que pueden ser tranquilamente flujos de 5-10GB/s, y una base de datos de 50-60GB en RAMdisk

- Lo que sería la cache del Data Mining (la salida, output) iría en ramDisk, serían unos 10-20GB , de ahí unas "vistas" web (html, archivos de 10-50mb), a un grid-RAID SSD por PCI-Express... de varios TB (5-10TB en principio) (el almacenamiento persistente)

Software en exclusiva, una base de un "Linux muy ligero" o un sistema basado en Unix personalizado ad hoc (que me permita soporte de herramientas de ejecución de código y alto rendimiento...

Sería ejecutar C++, R y alguna cosa más (como Gran procesamiento), R compila a C, C++ (creo) (eso lo gordo)
Luego Python, Perl, y algún lenguaje para cosas concretas de IA (que en realidad no son tanto), lo más gordo es lo que va en C++ y R, que es lo que necesita digamos más "movida".

- Orientado a data-center que a cluster HPC (esto si en otro momento pudieras desarrollarlo lo agradecería, supongo que te refieres a una "infraestructura dedicada" en un cluster virtualizado (pero con garantías), igual no (no domino la jerga y lo tipos, en temas de computación en la nube)

- Lo que comentas sobre gestionar picos de CPU y IOPS influirá mucho el software que utilices, como el repartidor de carga (sin duda).

Siempre me fijo en el tema Escalabilidad en todos los cuellos-de-botella (bottlenecks dichosos) desde hace ya un año o dos sigo HighScalability (un blog que supongo conocerás, muy bueno, hay arquitecturas de alta Escalabilidad de los grandes (obviamente se reservarán sus trucos, pero se aprenden cosas) y ando de rondador nocturno por StackExchange y por varios sitios como el de Servidores, eso y la curiosidad qu tengo que me hace buscar y rebusca

si empleas soluciones cutres, no se, por ejemplo, usar un NFS sobre Fast-Ethernet (o incluso GigaEthernet), pues el repartidor de carga no puede hacer milagros, claro hay cuellos de botella

A nivel de sistema de archivos y "interfaces" en clúster o data-center que solución es la que da más ancho de banda teórico (porque al final necesito rapidez de transferencia entre equipos, "velocidad neuronal")

Por tanto mi "proyecto" no requiere tanto "almacenamiento" unos cuantos TB y además luego con un CDN, se puede servir "lo persistente" sin problema... pero el "Procesamiento" y la Rapidez que luego salta a la caché en ramDisk (necesita varios GB/s de ancho de banda), varios 5-10GB/s como pico 10GB/s

A nivel de ramDisk o SSD en RAID (no habría mucho problema, a nivel de conexión de red?

TarekJor

#24 Ah y perdona por el tocho lol, espero no molestarte.

Se me olvidaba que en un punto necesito "comprimir" archivos de texto de GB a lo bestia (ahí seguro que utilizo una solución que ya exista lo más bajo nivel y rápida posible (no sé mucho sobre ello), tiene que ser un equilibrio que maximice "compresión" en el mínimo tiempo, recursos, con el Algoritmo y herramienta que sea, por si te suena o conoces algo

Un saludo y muchas gracias por tu tiempo
A darle caña a esos switches.

F

#24 no te preocupes, me alegra que alguien se interese por estos temas lol. Ya me gustaría poder contestarte correctamente a todo lo que planteas, pero bueno... ahora voy con la parte más didáctica, la parte chunga me lo reservo para mas tarde.

Cuando digo switch, diga router. Son cosas diferentes (que nadie me fusile por esto), pero igual te ayuda a entenderlo (1).
Existen diferentes tipos de redes de interconexión. Desde la red que debería desplegar un proveedor de internet, la red que encontramos interconectando los tiles de un GPU, la red que comunica los cores de un multiprocesador (NoC, Network on-chip) o la red que comunica los nodos en un supercomputador (HPC, High-Performance Computing). Todas tienen sus puntos en común, pero también tienen requisitos de diseño diferentes. Yo he trabajo principalmente en redes HPC y también un poco en NoCs.

La escalablidad (2) es un factor importante, pero tendrá mayor o menor peso en el diseño dependiendo del tipo de red. Consideremos un Noc. Si estás trabajando en el diseño de una red de un multiprocesador de 16 cores, podrías considerar el aplicar técnicas que no escalen. Está técnica podría ofrecer muy buenas prestaciones a un costo razonable en una red con 16 routers. Y sin embargo, aplicar esta técnica en una red HPC, que puede llegar a conectar decenas de miles de switches, es totalmente inviable. Otro ejemplo: en una NoC, la superficie ocupada por los transistores es un factor crítico, ya que la superficie en un multiprocesador está muy limitada. En cambio, no es un factor tan critico en un switch HPC, donde dispones de mucha más superficie. Es decir, mi trabajo en se centra en el diseño de la arquitectura hardware de los switches en un red de un supercomputador.

Sobre cluster HPC / data center: aunque presentan muchas similitudes en su diseño, sus objetivos son totalmente diferentes. El objetivo de un datacenter es el proveer servicios (ej. las granjas de servideres de Google), mientras que el cluster HPC está orientado al cálculo, habitualmente aplicaciones de ámbito científico que necesitan (ej, el Marenostrum en el Barcelona Supercomputing Center, en su momento llego a ser el tercer supercomputador más potente del mundo).

En cuanto a red de interconexión, la verdad es que podrías desplegar la misma red HPC para un datacenter que para un cluster. Pero como te digo, los requisitos del sistema completo son muy diferentes. Por ejemplo, sería inaceptable si un datacenter de Google necesitara varios minutos para contestar a una petición. Pero un cluster, pondrás tu trabajo en la cola, y se ejecutará cuando llegue tu turno. Por otra parte, según Google (podría hasta buscarte el paper lol), sus granjas de servidores, en media, están trabajando al 15% de su capacidad. Eso en un cluster sería bastante absurdo. Si tu cluster solo se usa al 15%... igual tenías que haber comprado el 15% de hardware lol.

Saludos!

(1) ¿Conoces el modelo TCP/IP o el modelo OSI? Si los conoces no tendrás problema en entender la diferencia. Si no puedo intentar explicarlo más adelante, aunque es un tema muy trillado. La diferencia entre un router y un switch es que trabajan en diferentes capas del modelo, un router trabaja en la capa red/trasporte, mientras que un switch trabaja a nivel de enlace de datos.

(2) Entiéndase por escalabilidad, la capacidad de la red para mantener sus prestaciones conforme aumenta el número de nodos que interconecta. Aclaro esto, porque creo que tu te refieres a escalabilidad como la capacidad de un servidor web para mantener sus prestaciones conforme aumenta el numero de peticiones. Además, he visto el blog de High Scalability, y he visto que va de desarrollo web, lo que confirma mis sospechas. A decir verdad, no tengo ni idea de desarollo web (3).

(3) Volviendo a la capa TCP/IP. Creo que estás refiriendote a la capa de aplicación. Yo trabajo a nivel de enlace de datos.

TarekJor

#27 Muchas gracias ^^ por tomarte el tiempo, de responder tan detallado (he aprendido cosas, que me servirán para tirar por caminos concretos)

Sobre el primer párrafo (es muy interesante, y apasionante)

Ahí mis Conocimientos son intuitivos (no se puede saber de todo), pero sin duda me interesa

Sobre cluster HPC vs "Data Center" => Muy buen matiz, supongo que en la superComputación se utilizan Algoritmos lo más próximos al nivel-máqina (aunqe quiero pensar que algo de C, R o C++ (por sus capacidades)

Desconozco si existe algún Lenguaje específico, está claro que cuanto más cercano al "máquina" más se puede optimizar (intuición que tengo)

Sobre "modelo TCP/IP o el modelo OSI?" => Sin duda, es lo primero que vi cuando me puse con ese maravilloso mundo (que me queda mucho por descubrir) de Redes.

" un router trabaja en la capa red/trasporte, mientras que un switch trabaja a nivel de enlace de datos. "

Con eso es suficiente, lo has explicado perfectamente.

Sobre "tiempo de respuesta" => Tengo claro que en mi caso una parte (respuesta a Humano) tiene que estr medida en todo el proceso en milisegundos (con un máximo pico de 1s como fallo no tolerable), si el datacenter de Google necesitara varios minutos para contestar a una petición (buff , te entiendo perfectamente)

En las Búsquedas y "Motores de Búsqueda" el tiempo de respuesta es fundamental (también la Calidad eso sí) que a veces la última deja que desear (pero es otro tema)

En el cluster, que supongo puede ser (por colas, stack, etc) o "asíncrono" (según carga de trabajo) tiene todo el sentido, porque lo que importa es el resultado (en una parte de mi "servicio" algo así sería con MatLab, R o C++ como ejecución de scripts (eso si todavía tengo que ver, esa parte a nivel de Optimización, y si hay alguna otra forma o Lenguaje de que sea "mejor" sin incurrir en "dolores de cabeza" jajaja

Creo que lo has explicado perfectamente "digamos lo que sería un centro de datos orientado a Inmediatez" vs "un cluster orientado a "Procesamiento puro de datos"

Sobre los papers, tengo varios, de varias empresas (y lo que voy encontando o en libros), aquello de aprender "de los que saben o de los que parece que van por camino de saber"

" según Google (podría hasta buscarte el paper lol), sus granjas de servidores, en media, están trabajando al 15% de su capacidad. Eso en un cluster sería bastante absurdo. Si tu cluster solo se usa al 15%... igual tenías que haber comprado el 15% de Hardware "

Totalmente de acuerdo, en el caso de Google supongo que será para Escalabilidad futura, o los "Picos máximos" en condiciones de "alto estrés" ataques o migraaciones rápidas.

En lo que es el Data Center (clásico) orientado a servidor de (servir datos en tiempo real, inmediato), creo que tengo bastante info...

Sobre cluster, me falta a nivel de implementación y Escalabilidad o Programación específica...

Quiero suponer que con C++, MatLab o R (o similares) podría llegar a tener "bastante rendimiento", pero puede ser "UN error de ignorante".

Dicho esto, lo dicho muchas gracias por tu Tiempo, de verdad a veces "pinceladas sobre matices" ayudana enfocar las cosas y tirar "mucho mejor" hacia los temas "que nos son desconocidos"

R

#11 Te respondo con lo poco que se.
1- No. De hecho requiere poquísima porque trata a nivel atómico. El problema energético reside en que algunos superconductores necesarios requieren temperaturas cercanas al cero absoluto.
2- El procesador en si, no. El escalado de un ordenador cuántico corresponde a la cantidad de qbits que puedas entrelazar. Es decir, se escala metiendo más qbits. Lo que se puede miniaturizar es el mecanismo para la generación de qbits que es extremadamente sensible (una mínima vibración o décima de grado hará que todo falle)
3- Sí. Los más caros y precisos que puede hacer ahora el ser humano.
4- No. Quizás en un futuro que no veremos nosotros salvo otro salto tecnológico paralelo. Son máquinas enormes de extrema sensibilidad (están midiendo el spin de un electrón. UN electrón). El objetivo de los ordenadores cuánticos que no funcionan como los normales no es que tú tengas uno en cada terminal sino que a través de la red hagas peticiones y te devuelva el resultado. Los ordenadores cuánticos no están para sustituir a los clásicos sino para complementarlos. Imaginate que en vez de tener un chip para el cálculo de una IA tienes un ordenador cuántico online al que le entregas el estado y te da un resultado. Esto es tan importante que se está evaluando tener los ordenadores cuánticos en órbita para evitar cualquier mínima vibración que pueda producirse a su alrededor.
5- La computación cuántica puede hacer tantos cálculos de una sola tacada como qbits al cuadrado tenga. Por lo tanto, la seguridad por encriptación está condenada a desaparecer pues cualquier ordenador cuántico podrá descifrarlo en momentos. Necesitarás la raiz cuadrada de operaciones cosa que podrá hacer sencillamente. Ahora, la computación cuántica viene con su propia seguridad. La función de onda colapsa al medirse haciendo que cualquier intento de interceptar el dato "avise" automáticamente de que los datos se han intentado leer por un tercero.

TarekJor

#26 Entiendo, muchas gracias por el comentario (alguna intuición tenía), has tocado cosas (que se entienden bien, y entran dentro de una Lógica, que aunque ignorante en el tema, sigo, gracias

Digamos que el "montaje" necesario "es complejo", lo bastante y con los materiales implicados (emperaturas) y condiciones, como para que se tenga que montar en plan "Ordenador Central-Mainframe" en un lugar concreto centralizado a lo grande.

Ordenador Cuántico como servicio (eso podría molar sí)

"seguridad por encriptación está condenada a desaparecer" Esto me ha llamado mucho la atención (por fuerza bruta supongo)

La cuestión es, como será la Seguridad entonces?.

R

#28 Explicar la nueva seguridad es "sencillo". Básicamente los qbits pueden ser 0, 1 o una superposición de ambos estados (imagínatelo como un a probabilidad de que sea 0 o 1). Sin embargo tú no puedes medir esa probabilidad sino que permanece en ese estado superpuesto hasta que se mide. En el momento de medirlo la función colapsa a 0 o 1 por lo tanto tú no puedes nunca saber cual era el estado superpuesto, sólo puedes saber en qué colapsó.

Entonces, tenemos una secuencia de datos que queremos enviar. Esta secuencia la codificamos con una base que básicamente indica cómo se ha codificado (una clave). Como al medir los qbits superpuestos estos colapsan es fácil saber si alguien ha interceptado la clave. Por lo tanto si nadie la ha interceptado es seguro enviar los datos porque sabes que la base no ha sido escuchada.

Si intentas interceptar los datos y colapsarlos sin la clave adecuada, colapsará en datos aleatorios. Como los datos superpuestos no se pueden duplicar (porque al intentar leerlos sólo lees en lo que ha colapsado) entonces básicamente tienes un solo intento. Salvo que seas capaz de violar las leyes de la mecánica cuántica, cosa que de momento no parece posible.

TarekJor

#30 Gracias por la respuesta, (tengo que darle algunas vueltas, en este tema tengo que profundizar mucho)

Me recomiendas alguna Lectura, artículos, libro para profundizar (sobre qBits y teoría de Computación, de Hardware no me interesa tanto, de momento), tengo varios libros de x86, ARM, no soy "novato" del todo (aunque tiene poco que ver)

La cuestión que surje, es si habrá Hardware de Computación Cuántica en miniatura "en el usuario doméstico", no en un "mainframe", que seguro que sí, porque de lo contrario...

Eso es lo que me preocupa, porque lo que he visto es que "no es tan fácil" miniaturizar o no les va a interesar.

Eso abre la puerta, para que el Cifrado, y la Criptografía clásica "sea violada a lo bestia"?, vamos que toda la Seguridad que vaya "fuera de la Computación Cuántica" se podría destrozar con Fuerza Bruta en tiempo ínfimo (aunque hubiera otros niveles, de protección no?)

R

#31 Desgraciadamente no tengo bibliografía al respecto y me documento a base de artículos de divulgación que voy viendo según me entran. En tal caso te recomiendo que le eches un vistazo a la página de IBM Q experience donde te explican a grandes rasgos cómo es un ordenador cuántico, te enseñan cómo programar para ello y lo mejor es que puedes hacer requests a su ordenador cuántico de 5 qbits.
https://quantumexperience.ng.bluemix.net/qx/experience

La criptografía clásica va a serlo pero muy en breves. Digamos que un ordenador cuántico al superponer 1 y 0 a la vez, tienes todas las posibles contraseñas. Básicamente puedes decirle al ordenador que pruebe todas las superposiciones de 1's y 0's en una única operación. Es decir, en vez de decirle pruebame la contraseña 0001, prueba ahora 0010, ahora 0011, le dices directamente prueba las contraseñas que salgan de (01)(01)(01)(01). Así que, si miras la noticia, han conseguido controlar 50 qbits. Queda poder entrelazar esos 50. Pero el día en el que sean capaces de controlar y entrelazar 256 qbits se habrán violado todas las contraseñas de 256 bit.

En realidad no es así, y sé que necesitas la raiz del total de operaciones para poder descifrarlo, pero es un poco para que te imagines a grandes rasgos cómo funciona (es lo que me ayudó a entenderlo en su momento).

TarekJor

#32 "Desgraciadamente no tengo bibliografía al respecto y me documento a base de artículos de divulgación."

Es normal, es lo que he ido mirando (es un tema muy reciente), me pasaba hasta no hace mucho con alguno de los temas que me ocupan... "Procesamiento del Lenguaje Natural", que eran todo tesis, artículos y fragmentación (para tema de IAs), mejor (que así es que hay campo para maniobra y crear lol), sobretodo desde una perspectiva distribuída no centralizada, y más formal que "Big Data".

"En realidad no es así, y sé que necesitas la raiz del total de operaciones para poder descifrarlo, pero es un poco para que te imagines a grandes rasgos cómo funciona (es lo que me ayudó a entenderlo en su momento)."

Si al elevar la exponenciación (combinatoria) y todas las operaciones simultáneas de la fuerza bruta se parten por todos los lados. lo de n^n

gracias, por la info (y a seguir aprendiendo), parece un tema alucinante (me imagino las aplicaciones para IA (con razonamientos en grafos en n dimensiones instantáneos, una capacidad de relación brutal, en cuestión de segundos o milisegundos, evaluar problemas muy complejos... con millones de datos como relaciones (no sólo numéricos sino "cualitativos" vinculados a (que eso hoy día es un cristo)

Por eso me parece importante que no se lo queden sólo las Corporaciones (que al final tienen Conflictos de Intereses)

Sobre esto:

"Pero el día en el que sean capaces de controlar y entrelazar 256 qbits se habrán violado todas las contraseñas de 256 bit."

Con 50qbits no podrían violar ese protección en unos días o semanas? (pregunto)

R

#33 Pues no lo sé, la verdad. También leí ahí que en realidad los ordenadores cuánticos son bastante más lentos que los tradicionales. Que su potencia está en la capacidad de hacer este tipo de taréas permitirán hacer cálculos que con ordenadores tradicionales son lentos por la cantidad de cálculos o directamente imposibles.

Pero la verdad es que no lo sé. Es todo especulación por mi parte.

TarekJor

#34 Puede ser que sean a "bajo nivel" para tareas de Algoritmos concretos implementados de una forma concreta (también estoy en la Especulación), desde luego será para cálculos-operaciones muy concretos (no de propósito general, pienso)

Bueno, muchas gracias por tu tiempo, y saludos, suerte con los aprendizajes sanos.

OZYMANDIAS

#5 creo haber leído que es la cantidad necesaria para montar un ordenador cuántico. A ver si encuentro el artículo y lo enlazo. Lo de los cubatas también es válido.

D

#5 porque más no entran en el vaso de un cubata, evidentemente

Peazo_galgo

#12 hai mi hamijo, tiene hustec algun poblema con la z? rese a la birjensita de guadalupe que seguro le halluda y yena de congratulasiones! un abraso de hantebraso

D

#17 grasias vendisiones para uste tambien

OZYMANDIAS

Más cerca de los 90 cubits. Por el buen camino.

D

#2 Desde la ignorancia, ¿por qué el hito de los 90?

D

cuando puedan minar bitcoins que me llamen...

D

#8 jajaja para que iba a haser algo asi nadie, si eres capas de minar todos los bitcoins restantes en un minuto, en ese mismo minuto los bitcoins pasaran a valer sero euros jajajajajjaj si quieres benefisios aber estudiao