|
|
|
|
|
|
|
|
Erfinde einen neuen Witz. Den Studentenverteiler mit "Hey Kids!" anschreiben.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Paywall... 
|
|
|
|
|
|
|
|
|
|
|
Oh, gestern war er noch ohne.
Zusammenfassung: Google hat ein Paper eingereicht (bei Nature, wie es weiter geleaked ist), in dem sie angeben, sie hätten einen Quantencomputer gebaut mit dem sie ein Quantum Sampling Problem, dass auf den besten Computern 10000 Jahren benötigt hätte, in 3min20s gelöst haben. Der Quantencomputer hätte 53 Qubits. Der Preprint ist auf einer öffentlichen NASA Seite aufgetaucht, aber schnell wieder verschwunden. Scheinbar war das in der Quantencommunity aber bekannt. Dort sagt man sich auch, es hänge an Reviewer 3 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zu Q2 in dem Blog-Beitrag kann ich sagen, dass es bereits quantencomputer-stabile Krypto-Codes gibt, welche auf 20MHz Micro-Controllern laufen. Wir hatten kürzlich einen ThinkTank hierzu.
|
|
|
|
|
|
|
|
|
|
|
Schrieb der Blog das nicht auch? Btw, danke für die Links! 
|
|
|
|
|
|
|
|
|
|
|
Den Artikel habe ich auch gelesen. Ein Arbeitskollege von mir hat (angeblich) über Quantencomputing promoviert und als ich heute bei der Arbeit erzählte, dass das Problem, welches Google löst, ein Zufallsgenerator ist, meinte er im Brustton der Überzeugung: "Jaja, ein Spinglas!" Ich habe dann widersprochen, er war aber nicht davon abzubringen, dass die ein Spinglas simulieren und er habe ja mit D-Wave Kontakt gehabt etc etc.
D-Wave ist doch eine ganz andere Truppe, oder? Kann jemand von euch, der sich mit dem Thema auskennt, kommentieren ob Googles Algorithmus / Hamiltonian was mit Spingläsern zu tun hat?
|
|
|
|
|
|
|
|
|
|
|
|
AFAIK ist das Google Experiment doch, dass sie dem QC eine Random Quantenschaltung geben, den QC dann die Schaltung simulieren lassen, und dann mittels Vergleich der Ergebnisdistributionen (auf konventionellem Weg berechnet) zeigen, dass der QC das auch tatsächlich getan hat.
|
|
|
|
|
|
|
|
|
|
|
|
Ja, aber vielleicht lässt sich das ja wirklich als spin glas umschreiben oder so, keine Ahnung.
|
|
|
|
|
|
|
|
|
|
|
Ja, vieles davon ist mit Hamiltonians gelöst. Iirc bei D-Wave, keine Ahnung wie das bei Google ist. D-Wave hat eine sehr eigene Architektur (adiabatisch, iirc).
Mehr als die Begriffe weiß ich leider nicht. Mal unseren lokalen Doktoranden in dem Thema fragen.
|
|
|
|
|
|
|
|
|
|
|
Die quantenmechanische Beschreinbung eines Quantencomputers ist im Prinzip schon ein Spinglas:
Ein Qubit als (bosonisches) quantenmechanisches Zweizustandssystem kann man beschreiben als einen Spin-1/2. Die Eigenzustände  ,  der Pauli Matrix  stellen die 1 und 0 (bzw. 0 und 1) Zustände des Qubits dar. Koppelt man mehrere Qubits jetzt auf einem Chip, dann lässt sich das durch Terme der Form  beschreiben (in der Regel hat man Kopplungen nur zwischen maximal zwei Qubits).
Im Fall von D-Wave hat man jetzt irgendein grid in dem Qubits miteinander gekoppelt sind und die Strärke der Wechselwirkung kann individuel getuned werden. Lässt man dort ein quantum annealing laufen, könnte man schon irgendwie sagen, man simuliert dort ein Spinglas. Hier ist es zumindest ähnlich: Man bildet im Endeffekt die Lösung eines Optimierungsproblems darauf ab, dass man den Grundzustand eines Spinglases sucht.
Bei Gatterbasierten Simulationen wie im Fall von Google finde ich das aber weit hergeholt. Zwar ist der Schaltkreis schon formal ein Spinglas, aber da irgendwelche Gatter angewandt werden eines, bei dem die Kopplungen stark zeitabhängig sind (es werden immer nur kurz spezifische aktiviert, um ein Quantengatter durchzuführen) und zum Großteil der Zeit verschwinden. Auch die Problembeschreibung hat eigentlich nichts mit einem Spinglas zu tun.
Nur weil der Quantencomputer ansich formal so beschrieben wird, finde ich es etwas irreführend zu sagen, man simuliert da ein Spinglas. Auch wenn das im Endeffekt der Grund ist, warum es klassisch nicht effizient machbar ist: Man kann klassich nicht effizient Spingläser simulieren. Das trifft aber z. B. auch auf fermionische Probleme zu. Und diese kann man, wenn man will mit Jordan-Wigner- oder Bravyi Kitaev-Transfomationen etc. auch formal auf ein Spin-Problem mappen. Man würde aber nicht unbedingt sagen, man simuliert ein Spinglas, wenn man sich mit dem Fermi-Hubbard-Modell beschäftigt.
Quelle: Hab einen Doktor im Bereich Quantumcomputing gemacht und arbeite in dem Feld.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Robotronic am 01.10.2019 11:03]
|
|
|
|
|
|
|
|
|
Vielen Dank! Eigentlich hoffe ich nur, dass in Googles Paper das Wort Spinglas nicht (im Zusammenhang mit deren Experiment) auftaucht, und dann genieße ich meinen "in your face" Moment. Mein Kollege wird dann natürlich (wie üblich) ausholen und erklären, was er _eigentlich_ gemeint hat, was ich nicht verstehen werde und am Ende denken wir beide, wir hätten Recht gehabt.
#story-of-my-office
/e: Vor vielen Jahren habe ich auch mal die QC Grundlagen gelernt und halbwegs verstanden, aber mein Gedächtnis ist wie ein Sieb.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 01.10.2019 11:22]
|
|
|
|
|
|
|
|
|
Ich habe selbst die Grundlagen nicht gelernt und verstehe nur Bahnhof.
Gibt es einempfehlenswertes Einführungsbuch für Leute, die Mal Physik studiert haben?
Idealerweise werden ein paar QM Formalismus Grundlagen wiederholt. Wenn es direkt mit Bras und Kets losgeht, bin ich abgehängt...
Und das D-Wave Ding...ist das nun wirklich ein QC? Die haben das schon vor gut einem Jahrzehnt behauptet und die Fachwelt war skeptisch.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von horscht(i) am 02.10.2019 9:53]
|
|
|
|
|
|
|
|
|
Was der horscht(i) (arbeitet bei BuzzFeed) sagt!
|
|
|
|
|
|
|
|
|
|
|
Vielleicht habt ihr Ideen:
Ich will ein Programm schreiben, welches sich selbst baumförmig auf verschiedenen hosts aufruft und mit sich selbst kommuniziert. Also angenommen ich will ein Kommando auf node01 node02 und node03 ausführen, node02 wird aber nur über node01 erreicht, und node03 nur über node02.
Im Moment löse ich das so, dass sich das Programm per ssh selbst aufruft und dann in einer Loop auf stdin wartet, bzw. nach stdout schreibt und von seinen Kindern liest.
Also:
node01:
- Programm wird gestartet.
(- Programm wartet hier NICHT auf stdin)
- Programm ruft COMMAND lokal auf.
- Programm ruft sich selbst auf node02 auf
- Programm schreibt COMMAND nach stdin von node02.
- Programm wartet auf STDOUT von node02
- Programm schreibt STDOUT von node02 und beendet sich.
node02:
- Programm wird gestartet.
- Programm liest COMMAND von stdin.
- Programm ruft COMMAND lokal auf.
- Programm ruft sich selbst auf node03 auf
- Programm schreibt COMMAND nach stdin von node03.
- Programm wartet auf STDOUT von node03
- Programm schreibt STDOUT von node03 und beendet sich.
node03:
- Programm wird gestartet.
- Programm liest COMMAND von stdin.
- Programm ruft COMMAND lokal auf.
- Programm ruft sich selbst auf node04 auf
- Programm schreibt COMMAND nach stdin von node04.
- Programm wartet auf STDOUT von node04
- Programm schreibt STDOUT von node04 und beendet sich.
nodeNN:
- repeat
Das funktioniert auch. Nun frage ich mich, wie man am besten die Kommunikation löst. Im Mometn schicke ich JSON payloads hin und her, wobei eine Nachricht mehrere Zeilen haben kann und als "beendet" angesehen wird, sobald eine Zeile `\0` auftaucht.
Ich frage mich, wie man das am besten professionell löst. Ich will am Ende halt commands verschicken und ausführen lassen, und auch Dateien schicken. Ich werde als rohe bytes über stdin/stdout verschicken, deshalb fürchte ich mich vor hard gecodeten EOS und so.
- Welches Format würdet ihr zum Kommunizieren nutzen? JSON funktioniert für Messages, aber das müsste ich beim Dateien verschicken mit raw bytes mischen. Unschön.
- Würdet ihr alle Messages acknowledgen? Also nach jedem WRITE auf den stdin von einem Kindprozess wird auf ein ACK oder so gewartet, welches den Empfang bestätigt. Ist sauberer als einfach davon auszugehen, dass es geklappt hat, oder?
- Wenn ein Mittelsmann-Programm abstürzt, also beispielsweise auf node02, wie erkenne ich das auf den Kindern, damit da kein Prozess endlos wartet? Oder soll ich per timeout alles killen?
- Sollte ich Binärstrings (Dateien) b64 encoden? Besonders wenn ich bestimmte EOS codes definiere, ist doch immer die Gefahr, dass zufällig genau der code in meinem Binärstring vorkommt.
Nach einer kurzen Recherche macht scp es ähnlich, die haben einfach ein custom Protokoll erfunden.
/e: Ich kann natürlich auch jede Message mit der Länge der Nachricht beginnen und dann raw bytes schicken; der receiver liest dann genau so viele bytes wie vorher angekündigt...
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Oli am 02.10.2019 15:42]
|
|
|
|
|
|
|
|
|
|
Das klingt erstmal wie ein klassischer usecase von RPC.
|
|
|
|
|
|
|
|
|
|
|
| | | Welches Format würdet ihr zum Kommunizieren nutzen? JSON funktioniert für Messages, aber das müsste ich beim Dateien verschicken mit raw bytes mischen. Unschön. | |
Oder die raw bytes als string in json encoded schicken.
|
|
|
|
|
|
|
|
|
|
|
|
Hm, ein paar GB raw bytes mit Json drum herum, was ich erst wieder parsen muss und so, ich weiß ja nicht. Cooler wäre für file transfer, wenn ich am receiving end alles direkt in eine Datei schreiben könnte.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Das klingt erstmal wie ein klassischer usecase von MS08-067.
| |
|
|
|
|
|
|
|
|
|
|
|
Kannst du die Probleme voneinander trennen? In dem Sinne, dass der erste Node zuerst herausfindet, wie er mit allen kommunizieren kann und dann auf den ganzen Nodes getrennt die Prozesse aufruft (Mit sowas wie Puppet meinetwegen?)? Noch einen Schritt weiter zurück: Gibt es einen Grund, warum die Struktur so schräg ist und kannst du, als der Mensch mit Macht, vielleicht die ganzen Hosts in einer flachen Struktur wie einem VPN verwalten?
Gibt es einen bestimmten Grund, warum sich das Programm rekursiv verhalten muss? Für mich klingt das erstmal nach mehr Komplexität als Vorteil.
|
|
|
|
|
|
|
|
|
|
|
|
Es sind mehrere tausend nodes in clustern und racks organisiert und eine loop wäre zu langsam.
|
|
|
|
|
|
|
|
|
|
|
Hm, vielleicht verstehe ich dein Problem nicht genau, aber suchst du nicht "Peer-to-peer" oder vielleicht eine Command-Möglichkeit, wie es z. B. Botnetze machen?
Ich meine da gibt es doch vermutlich genug OpenSource für die man als professionell bezeichnen kann (ohne jetzt gesucht zu haben), die solche Probleme schon gelöst haben.
/e: ansonsten alle Nodes auf einen zentralen IRC Server verbinden lassen. Ging früher auch und kann auch Dateien 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [smith] am 02.10.2019 20:25]
|
|
|
|
|
|
|
|
|
Wenn du eh rawbytes verschickst, warum schreibst du nicht einfach komplett dein eigenes Packet Format? JSON wirkt etwas eigenartig wenn du auch große Dateien verschicken willst.
Dann könntest du auch parallel direkt weiterschicken an die nächste Node.
Parsen würde dann abgesehen vom Header ebenfalls wegfallen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Murica am 02.10.2019 22:06]
|
|
|
|
|
|
|
|
|
Hat hier schonmal jemand Zemax benutzt, die .zmx-files von Thorlabs, und vielleicht sogar versucht die mit Code V zu öffnen?
Bei manchen Dateien klappt das (dem Anschein nach), wenn man die leeren Zeilen und Leerzeichen am Zeilenanfang löscht.
Das geht aber nicht immer.
Da es sich um simple Linsen handelt, denkt sich der dumme Physiker also: "C&P der Radii aus der Datei in die Tabelle, done!"
Ich war überrascht, als ich die Zahlen nicht kopieren konnte. Also kopieren schon, aber nicht Pasten in dem Programm. Oder in LibreOffice Calc.
In Kate konnte ich Pasten. Wenn ich die Zahl dann kopiert habe, könnte ich sie aber nirgendwo anders einfügen.
Ich konnte aber eine Ziffer manuell einfügen, kopieren und woanders einfügen.
The Fuck?
Spoiler - markieren, um zu lesen:
Datei ist in UTF-16, BOM zeigt UTF-8
Was rauchen die?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rootsquash am 02.10.2019 22:30]
|
|
|
|
|
|
|
|
|
| | Zitat von Murica
Wenn du eh rawbytes verschickst, warum schreibst du nicht einfach komplett dein eigenes Packet Format? JSON wirkt etwas eigenartig wenn du auch große Dateien verschicken willst.
Dann könntest du auch parallel direkt weiterschicken an die nächste Node.
Parsen würde dann abgesehen vom Header ebenfalls wegfallen.
| |
Ja, das scheint mir auch am Sinnvollsten. Ich Kämpfe noch mit Pythons multiprocessing und so, aber mal gucken ob ich was Sauberes hinkriege.
@IRC: lustige Idee, aber sollte so wenig wie möglich auf den Servern machen, und schon mein Programm da hin zu legen ist eigentlich zu viel. Bin auch nicht root.
|
|
|
|
|
|
|
|
|
|
|
Hm, kannst du evtl mehr preis geben, was du genau erreichen willst eigentlich?
Also ich habe nur das Gefühl, dass du versuchst etwas mit der Brechstange zu erreichen, was vielleicht bewusst nicht erlaubt ist oder für das es eben die professionellen Tools gibt, etwa MapReduce oder andere spezielle Cluster-Algorithmen. Ich will dir da echt nicht ans Bein pinkeln, wenn wir sowas in unseren Clustern versuchen würden, würden vermutlich sofort entlassen. Du willst ja quasi einen Wurm schreiben, der alle Nodes findet und infiziert, und dabei mögliche Probleme wie SplitBrain oder anderer Schabernack quasi... ignoriert.
Bitte wirklich nicht übel nehmen, aber da gehen dann einige Alarmglocken an
Ansonsten haben wir im Moment gute Erfahrungen mit gzipped Protobuf gesammelt, besonders weil es sich schön weiterentwickeln lässt. Ansonsten such dir generell etwas Streaming-fähiges wenn du da mehr Performance brauchst. Und ja, bitte überall Timeouts verwenden, bevor das Ding Amok läuft.
Gäbe es sonst eine zentrale Logging-Instanz, mit der man Erfolge kontrollieren könnte?
Oder haben die Nodes Zugriff auf eine Paketverwaltung, dass du es als Software/Update verpacken könntest?
|
|
|
|
|
|
|
|
|
|
|
|
Dieses. Und Protobuf streaming ist Liebe.
|
|
|
|
|
|
|
|
|
|
|
Okay. Es geht um high performance computing. Wir haben drei Rechenzentren (in drei Ländern), in jedem Rechenzentrum mehrere Rechencluster (insgesamt 25), in jedem Rechencluster 1-7 Racks und in jedem Rack ca. 50 Rechenknoten. Alle Rechner sind mehr oder weniger ähnlich, zumindest soll das Dateisystem sehr ähnlich sein). Man kann sich von jedem Knoten auf jeden anderen Knoten passwortlos per SSH einloggen, es gibt einen Login Knoten (nennen wir ihn login1) über den man von außen rein kommt.
Wir (als Supporter) müssen häufig Dateien auf allen Knoten verteilen, meistens kleine Scripte, manchmal mehrere GB Binaries. Weil häufig, muss das ganze sehr schnell gehen. Am besten in Sekunden. Es gibt insgesamt an die 5000 Rechner.
Ansible & co gehen die Dinger stumpf in einer (parallelen) loop durch, da man aber keine 5000 ssh Verbindungen aufmachen kann, dauert das ewig. Es gibt auch spezielle tools wie pdsh, ClusterShell, o.ä., die aber alle ihre Drawbacks haben und eher für einzelne Cluster geeignet sind.
Ich habe mir das jetzt so vorgestellt: Ich kopiere eine Datei / ein command auf den login1 Knoten, von da aus auf den ersten Knoten eines jeden Clusters, von da aus auf den ersten Knoten eines jeden Racks und von da aus die anderen Knoten im Rack. Das ganze so parallel wie möglich. So werden auf jedem Knoten maximal 50 SSH Verbindungen aufgemacht (kann die ja auch als Fenster durchsweepen), und ich kopiere immer nur über die schnellste zur Verfügung stehende Verbindung. (Ich nehme an, die Knoten eines Racks sind über ein Switch verbunden etc.)
Ich darf natürlich scripte ausführen und auch scripte/Programme irgendwo auf den Knoten ablegen, aber neue Ports aufmachen oder daemons laufen lassen eher nicht. Dazu kommt, dass MapReduce & co meiner Meinung nach übertrieben sind. Siehe auch http://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html .
Wer Ideen hat, wie man es anders löse kann - her damit. Wichtig ist mir
- Über SSH im User kontext
- kein kompliziert zu installierendes Programm, am liebsten nur ein Script
- Der output aller Knoten soll konsolidiert werden (also nach dem Schema: node[001-236,238-400]: bla -- node237: blub
- Ich will command ausführen können und Dateien kopieren können.
- Es muss fuckin' schnell sein. Wenn es länger als 1m dauert, dann gibt es andere tools und ich muss nicht erst programmieren.
Danke
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXII ( Jetzt nehmen uns Computer schon die Memes weg! ) |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
