Den Flaschenhals in einer langsamen Pipe optimieren durch Parallelisierung
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45595 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Parallel programming modelsedSoftwareXMLUMLComputer animation
00:42
LeadInternetSmartphoneProviderGastropod shellOpen sourceComputer animationEngineering drawing
01:30
Particle detectorSoftwareDebuggerPrint <4->Computer hardwareKommunikationPositionComputer animation
02:40
Scalable Coherent InterfaceSerial portVorverarbeitungComputer hardwareOnline chatCodesedSource codeComputer animation
03:42
Java native interfaceUser interfaceScripting languageLogarithmsedSoftware developerBefehlsprozessorBitIP addressoutputComputer hardwareCore dumpSoftware testingComputer animation
07:08
LeadScalable Coherent InterfaceMainframe computerWindows RegistrysedGastropod shellAtomic nucleusServer (computing)Core dumpComputer animation
08:39
FlagProviderOpen sourceLeadsedComputer animation
09:19
eMuleLeadScalable Coherent Interface9 (number)Menu (computing)Magnetoresistive random-access memoryAMOS <Software>Cellular automatonCore dumpContent (media)SoftwareoutputsedFirefox <Programm>Gastropod shellBenchmarkBefehlsprozessorIP addressParameter (computer programming)YES <Computer>Mobile appComputer animation
15:33
LeadWorld Wide WebsedComputer animation
16:24
LINUXHospital information systemSimulationLeadsedComputer animation
17:00
LeadsedBus (computing)ZahlGastropod shelloutputProbability distributionBlu-ray DiscPAPComputer fileAtomic nucleusReading (process)Network socketSeries (mathematics)Computer animation
23:14
MAX <Programm>ERNA <Programm>Reading (process)Social classsedComputer fileTerminal equipmentVirtueller SpeicherXMLComputer animation
25:05
CountingSet (mathematics)sedoutputBlock (periodic table)Pointer (computer programming)Propositional formulaSpacetimeTape driveBinary filePhysical quantityComputer animation
28:06
World Wide WebNetwork switching subsystemMenu (computing)sedGastropod shelloutputSeries (mathematics)NullEnde <Graphentheorie>Abstract machineTransmitterProcess (computing)Computer animation
34:16
LeadWorld Wide WebQuotePlatteGastropod shellsedRAMComputer fileoutputSimilarity (geometry)Data bufferSingle-precision floating-point formatMach's principleParalleler ProzessXMLComputer animation
40:26
GNU <Software>Scripting languageGastropod shelloutputComputer fileParallelenComputer animation
41:01
Windows RegistryUniform resource locatorGNU <Software>Carry (arithmetic)InterprozesskommunikationMIKE <Programm>TOUR <Programm>Trans-European NetworksScripting languageComa BerenicesHardy spaceBefehlsprozessorLink (knot theory)LeadProcess (computing)Computer animation
41:36
LeadHash functionError messageQuoteLengthVideo game consolesedBefehlsprozessorXML
44:05
LeadsedBefehlsprozessorBenchmarkoutputNumberXML
46:26
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:08
Es geht um SED. Ich erzähle immer so Storys, was mir neulich passiert ist, eigentlich schon viele Jahre her. Achso, da fehlt eigentlich eine Folie. Ist egal. Ich glaube, ich habe hier auch schon mal Vortrag gehalten, ich mache seit 2012 eigentlich.
00:26
Tut, tut nicht. Software. Also der Klinkenstecker wäre fürs Notebook, den brauche ich nicht. Software für einen Pico-Laser-Projekt. Ach doch, das will ich doch vielleicht zeigen. Wo habe ich hier?
00:43
Da müsste irgendwo vorhin für ganz viel Werbung. Irgendwo habe ich das gesehen, was ich mache. Hier. Also was es heute alles so an Sensoren gibt mit Magnet, und wir haben ganz tolle Eigenzettel, das ist immer Marketing für alle möglichen Sensoren. Das ist mein Sensor, da ist so. Kann jetzt jemand erkennen, was es macht? Wahrscheinlich nicht.
01:09
Nein. Ist die Marketingfolie doch nicht so schlecht. Hier. Das ist ein kleines Wackel, ein Mems-Spiegel, Mikroelektronenmechanischer Spiegel. Und da ist ein Laserstrahl, der rein rauskommt. Mit so einem Laserstrahl kann man dann so links rum wackeln und so rum wackeln.
01:24
Mit X und Y, wie früher Braunschirröhre für Elektronen, machen wir das heute für Photonen und machen einen Laserprojekt da. Und dieser Laserprojekt, da irgendwo war ein Bild. Ja, das sind so die Sensoren. Also das, was ich hier so sehe, ist so Kantenlänge. Früher mal die großen, zwei mal zwei Millimeter und fast einen Millimeter hoch.
01:41
Aber das passt heute in kein Handy mehr rein. Das ist jetzt also mehr so ein Millimeter Kantenlänge und 1,6 Millimeter hoch, damit es ans Handy passt. Und das da ist so das Produkt von unserem Team. Also das passt noch in eine Smartwatch rein. Also das ist nicht maßstäblich, aber da vorne aus dem Loch, da kommt dann so ein Laserstrahl raus, man kann Bilder projizieren, irgendwo hin. Und da habe ich viel Software für gemacht.
02:04
Und das muss der ASIC angesteuert werden und so was. Mit dem reden wir mit einer Serienschnittstelle, mit der Hardware. Und wenn das mal nicht tut, muss das auch debugged werden. Und zum Debuggen kann man diese serielle Schnittstellenkommunikation mit einem
02:23
kleinen Logic Analyzer mit einem Logic Analyzer mitloggen und dann angucken. So ähnlich wie TCP auf dem Netzwerk und sich das dann angucken und schauen, was hatten die Software gemacht, weil das alles in Echtzeit passieren muss. Da kann man nicht mal Prints reinmachen, dann ist es zu langsam, weil das alles nicht richtig tut.
02:42
Und für einen Logic Analyzer, das sieht dann im Output zum Beispiel irgendwie so aus. Da ist irgendwo SPI, serielle Schnittstellenmaster, out. Wir schieben dieses Hex 32bit raus und kriegen dieses Hex 32bit zurück und so was.
03:00
Und das ist das, was jetzt passiert ist, wenn wir unseren Projekter starten. Und da sich das aber ziemlich blöd lesen lässt, also da ist schon ein bisschen Vorverarbeitung drin, möchte man das gerne anders haben. Und da habe ich mir so ein kleines SED-Regelwerk geschrieben, also ein Shellscript geschrieben, das aus den Registerbeschreibungen, wo unser ganzer Hardware beschrieben ist, wo auch der Code automatisch draus generiert wird, alles mal gemacht.
03:25
Und wenn man weiß, wie das geht, dann kann man so ein Regelwerk machen, mach mal aus den Hexwerten wieder, gehen wir ins richtige Verzeichnis rein, mach doch mal aus den Hexwerten wieder Register und Werte und sonst irgendwas. Und dann kann man sich das angucken und dann kann man gucken, was mache ich
03:42
mit der Hardware und wo war das in meinem Source Code und kann das machen. Das ist total toll und schön. Und das Script gibt es schon seit vielen Jahren, seit ich die Logic Analyzer-Sachen verwende und dachte, das will ich mal richtig lesen können. Das Blöde dabei ist, diese Logs wurden immer länger und länger, am Anfang hat es immer zu 5 Sekunden gebraucht, 10 Sekunden zum sowas mal kurz konvertieren.
04:02
Das hier braucht jetzt für diese kleine Sequenz einmal, das System starten schon 20 Sekunden, da warte ich ja schon noch drauf. Also das ist jetzt wirklich live, so schnell es geht, das Ding am Konvertieren, das ist total blöd. 20 Sekunden, flimmen wir das also durch und dann haben wir irgendwann mal Testzyklen
04:20
gebraucht, die ein bisschen länger sind und dann hat es mal eine Minute gebraucht. Und bei den letzten Tests vor einem halben Jahr, Jahr, Jahr, Jahr, Jahr, Jahr hat eine so eine Auswerte-Ding zum einfach das Ding lesbar machen, 20 CPU-Minuten gebraucht. Und was glaube ich, das richtige Script dabei? Nee, gibt es nicht. Also das ist ein Shell-Script mit, ich mache ganz viel Vorverarbeitung, das braucht ein paar Sekunden, ich mache ganz viel Nachverarbeitung, damit es noch schöner und lesbarer wird.
04:43
Und zwischendrin sitzt ein SED, wer kennt SED nicht? So ein Stream-Editor ist allenweg, also wo man so einfache Regeln suchen ersetzt. Ich mache da nichts Kompliziertes, obwohl das total programmierbar wäre, angeblich.
05:00
Aber, kommt gleich, so viel für all das schon. Aber einfach ist es, nimm dieses Regelmärk, das da irgendwie rumliegt, also nimm die Regeln und tu diesen Hex-Input bearbeiten und mach da den richtigen Output raus. Und was steht in diesen Rules drin? Der sieht jetzt irgendwie so aus. Such mir, Master Out, alles, was mit Hex 8000 ist und das ist dieses Register und es ist ein Read-Commando, das ist richtig lesbar.
05:26
Das gleiche mit vorne dem obersten Bit nicht gesetzt, das ist das gleiche Register mit einem Write. Und das heißt, suche das über die ersten 16 Bits in die Adresse und die zweiten 16 Bits in die Daten, die werden dann da irgendwie hinten hin gefuddelt. Und das macht das halt jetzt irgendwie 4.000 Mal.
05:42
Such die erste Adresse, ist es das, such die zweite Adresse. Das ging immer so in vernünftig bis zu einer Minute und da wirst du nicht ungeduldig. Die 20 Minuten oder das dann etliche Male 20 Minuten warten müssen noch richtig plöt. Die Frage war, wäre Perl oder Rubi schneller, weiß ich nicht.
06:02
Also das war alles schon da und ich kann ja nur SED und solche Sachen. Und da ging es natürlich wieder mal ein Hardware-Problem, das sofort analysiert und gelöst werden musste. Und das hat dann auch mit ein paar mal 20 Minuten, haben wir dann irgendwann verstanden, was die Hardware macht. Und dass es ein Hardware-Problem ist, wo die Spezifikation nicht so ganz klar war und die nicht damit gerechnet haben, was die Softwareer mit dem chip anstellen.
06:22
Jetzt weiß ich, wie das gemacht, gedacht war und was ich nicht machen darf, wenn man mit den Entwicklern im Haus redet. Jetzt können wir das auch anders und Problem gelöst. Und nachdem das Problem gelöst ist, kann man jetzt mal gucken, warum hat das 20 Minuten gedauert. Darum geht es jetzt. Also das ist wirklich so eine lange Pipe, die ich jetzt blödweise gerade so nicht zeigen kann. Aber der Pipe, Pipe, Pipe und dann ist ein Prozess in der Mitte, genau dieses SED-Kommando, das macht 20 Minuten und hinten raus.
06:45
Und warum braucht das 20 Minuten? Vor allem selbst mein Arbeitsnotebook hat heute vier Cores und acht CPUs. Warum sind da sieben CPUs leer, wenn die eine sich da 20 Minuten abmüht? War so ein Gedanke, das können wir doch total toll parallelisieren, weil genau diese Regeln, die ich gerade gezeigt habe, die werden auf jede einzelne Zeile angewendet.
07:07
Also nun mal zeigen, wie der Input aussah. Der Input ist zeilenweise für sich und der Output ist zeilenweise und die Regeln sind auch irgendwie, das muss doch irgendwie parallel gehen. Und deswegen jetzt ein bisschen zeigen, warum das gar nicht so einfach ist, das mal
07:21
geschwind in der Shell parallel zu machen und wie man es dann vielleicht doch hinkriegen kann. Ein Nachteil davon ist, also mein Privatnotebook hier, das hat nur vier Kerne, also eigentlich nur zwei Kerne. Und diese vier Hyperthreads, die gar nicht so schnell sind wie vier CPUs. Mein Notebook in der Arbeit hat wenigstens vier Cores und acht Kerne, die dann so schnell sind wie drei CPUs oder sowas.
07:41
Ich habe noch einen richtigen Server mit 24 CPUs und würde es sich schon lohnen, das ein bisschen zu parallelisieren. Den Vortrag, der hier nicht eingenommen wurde, war, es gibt eine zweite Lösung für das Problem, indem man über die Regeln nachdenkt. Ja, man muss halt alles, also kann ich das parallelisieren? Ja, schwierig, aber man kann da auch für andere Probleme lernen. Also es gibt Dinge, die sich nicht mehr optimieren lassen und dann ist ganz toll, man kann so eine Pipe parallelisieren.
08:05
Deswegen lohnt sich der Vortrag trotzdem. Hier lohnt es sich aber vielleicht, dann morgen in den Workshop zu gehen und zu überlegen, wie man dieses SED-Zeug durch ein bisschen nachdenken und wirklich über seine Daten und was man bisher so gemacht hat, so zu optimieren, dass man gar nicht 20 Minuten warten muss. Das SED-Ding geht auch in 20 Sekunden oder 10 Sekunden mit ein kleines bisschen Nachdenken in manchen Fällen für meine Daten und so.
08:28
Aber dazu dann vielleicht morgen eventuell was. Ja, jetzt geht es ums Parallelisieren. Da ich das jetzt nicht mehr in den Originaldaten machen kann und will, weder noch eigentlich.
08:43
Ist das die richtige Folie? Nein. Habe ich jetzt so ein Mini-Use-Beispiel, dass man das auch selber nachgucken kann, gemacht. Das hier ist das SED-Kommando, um das es geht. Und ich generiere mir jetzt einen Input-Stream mit ganz vielen Zeilen. Ich zeige das gleich, was da alles kommt, und es geht hinten raus um. Ich lasse da das SED durchlaufen und dann gucke ich, wie da was rauskommt.
09:03
Warum und wie das Ganze hoch? Ach so, vielleicht das SED, kann ich das abmausen, ich glaube. Also um eine einfache Regel zu haben und das mal testen zu können, war das mal ein tolles SED-Regelwerk. Also genau eine Regel.
09:21
Und jetzt muss ich mir irgendwie mal schnell ganz viel Input zaubern. Mein Input, um den es eigentlich ging, waren nur 7600 Zeilen. 7600 serielle Kommandos und dann läuft unser Projekter. Die Rules dazu sind aber auch 4.000 Zeilen, weil er eben 4.000 Mal sucht die Adresse, sucht hier eine Adresse und macht das mal.
09:46
Für 16-Bit-Adressen haben wir nur 4.000 von denen genutzt. Das ist eigentlich gar nicht so schlecht. Das könnte doch viel länger und viel schlimmer sein. Und aber da ihr weder den Input kriegt, noch das Regelwerk und sowas, und auch das zum Testen für so einen Benchmark und überlegen, wie optimier ich das,
10:01
weil das alles ziemlich sperrig ist, habe ich mir jetzt einfach, aber ich brauche halt Input-Zeilen, die irgendwie gehen, und dafür ist Yes total toll. Der liefert ganz, ganz viele Output-Zeilen. Und dann sag ich immer, ja. Oder wenn man den Parameter übergibt auch, kann er ganz oft Hallo sagen. Und wenn ich das jetzt so mache und irgendwas mitmache, dann weiß ich gar nicht, ist das erste Hallo, zweite Hallo irgendwie.
10:21
Und in meinem Input, deswegen ist das gar nicht so abwegig, ist auch vorne steht immer eine Zeit in Nanosekunden drin. Und da ist sogar ein Pikosekunden. Was total praktisch ist, weil man kann sogar mehrere von diesen Testdingern zusammenmischen und merchen und einfach über die Zeit, über die erste Spalte sortieren und sowas. Und wenn die in irgendeiner lustigen Reihenfolge auskommen,
10:40
werden ja jetzt viele Sachen parallel für etwas machen. Und ich wissen möchte, ob die nachher in der richtigen Reihenfolge rauskommen. Machen wir das mit unserem Yes jetzt auch. Und eins der ganz tollen Unix-Commando ist Cut. Wenn man den Output von Yes haben möchte, kann man den Cut reinpeilen. Was total blöd ist. Hat aber die schöne Option Minus N. Da kriegt man Zeilnummern.
11:02
Und schon habe ich einen Output, wo ich jede Zeile genauer erkennen kann und merke, ob die eindeutig sind. Und jetzt kann ich mal damit irgendwas machen und gucken, ob es hinten raus genauso rauskommt, wie ich mir das vorgestellt habe. Und dann kann ich das aber in mein tolles SED-Commando reinpeilen. Das da.
11:20
Was macht dieses wunderbare SED-Commando? Jetzt muss ich jetzt irgendwas machen, damit ich auch merke, ob es was gemacht hat. Es ist ein Suchen und Ersetzen von Punkt Stern von allem. Und ist von Joker für alles, was er gerade gefunden hat. Das heißt, der macht jetzt einfach... Das sind die falschen Gänsefüßchen aus dem Akrobat irgendwie raus.
11:40
Und der nimmt das und klebt es nochmal hinten dran. Nicht richtig aufregend. Aber das ist relativ praktisch. Ich sehe, ob da was passiert und wie das so passiert. So, sind wir eigentlich fertig. Das ist das Originalproblem gewesen. Und um da dann... Das ist das, was so typischerweise läuft. Jetzt ziemlich lange. Also jetzt habe ich nicht den Original Input.
12:01
Lass noch nebenher mal so ein Top laufen. Ein Top. Einfach zum Gucken. Wir haben da jetzt einen SED-Prozess, der kriegt eine CPU. Und bei mir sind da da oben dann so typisch 75 oder ein bisschen weniger Prozent eitel. Weil eine von vier CPUs oder Cores macht was. Wir wollen jetzt keine Software updaten.
12:25
Und wir sind zu 65 von so einem noch eitel. Da geht doch mehr. In der Shell ist es ja total einfach, so was parallel zu machen. Weil man kann ja so Hintergrundprozesse machen. Man kann sagen, ich schlafe mal drei Sekunden.
12:42
Dann schläft er drei Sekunden. Und dann sage ich noch mal, schlafe mal drei Sekunden. Das ist so sequenziell, seriell. Wenn ich so was sage, leg dich mal nach hinten und schlafe mal drei Sekunden. Ich habe vier CPUs. Ich kann jetzt vier Mal drei Sekunden parallel schlafen. Und nach drei Sekunden sind alle drei fertig.
13:01
Total toll. Was man auch daran sieht, dass da hinten nichts passiert auf meiner CPU. Das Web-Gedün stört. Content heißen die, glaube ich.
13:22
Und Kill-All hat symmetrische L-Verteilung. Irgendetwas macht Firefox in letzter Zeit immer wieder, mein, da stundenlang Fonds neu zählen zu müssen. Nur, da ich sehr viele Fonds habe, ist er da sehr lange mit beschäftigt. Das heißt, da habe ich jetzt parallel vier Mal geschlafen.
13:41
Das ist total toll. Und was es lief kann, kann SED natürlich auch. Ich kann jetzt eigentlich hergehen und sagen, ich will da jetzt mehrere Sachen gleichzeitig laufen haben, deswegen machen wir das in so einer Klammer-Sub-Shell. Danke schön. Ich versuche immer oben zu tippen, aber manchmal denke ich nicht dran.
14:01
Sofort melden. Auch wenn es Fragen gibt, immer sofort melden. Und zwar laut, weil ich sehe euch nicht so gut. Das ist jetzt das SED-Beispiel, das wir hatten und das mich schön vollploppt. Das ist alles total toll. Und jetzt tue ich in der Shell halt nicht ein SED laufen lassen, sondern tue das doch mal in den Hintergrund und mache davon noch einen zweiten.
14:27
Die Frage war, wenn ich die Klammer öffne, was heißt Klammer öffnen? Ah, okay, ich verstand.
14:42
Genau dazu kommen wir jetzt. Also die Frage war, ob, wenn ich die Klammer öffne, der Input für alle da ist und was da überhaupt passiert. Da habe ich ja noch gar nichts dazu gesagt. Die Idee ist einfach, ich lasse da jetzt mehrere SEDs laufen und was da dann so passiert und so. Denn das ist genau das Thema. Und ob das gut ist oder noch nicht gut ist, einfach erst mal gucken. Also es ist immer so, so eine Pipe macht von dem ersten Prozess
15:02
in den zweiten Prozess in den dritten Prozess. Und was da jetzt läuft, zur Klammer aufmacht, eine Sub-Shell, also das könnte man im Prinzip auch irgendwie einigermaßen. Das ist so ziemlich das Gleiche wie, ich mache Bash minus dieses Kommando und in der Shell laufen jetzt diese vier SEDs im Hintergrund. Die Bash hat die gestartet und diese SEDs, wie sich der Input verteilt,
15:22
kommen wir gleich, aber der Input wird mal in die Bash und ihre Kinder, die Klammer macht auch so, Kindprozesse, das ist eigentlich, müsste äquivalent das Gleiche sein. Können wir mal laufen lassen? Da kommt Output raus. Wo ist denn mein Abs? Den wieder haben und meinen Top. Wenn wir jetzt Glück haben.
15:45
Jetzt sehe ich, dass mein X-Term ganz viel Zebium kriegt und ich sehe nur einen einzigen SED. Das irritiert ein bisschen, aber das ist nicht so wahnsinnig schlimm. Wie viele SEDs laufen denn wirklich? Einer. Also ich kann das einmal ein bisschen größer machen, ein Hoch von größer wenigstens.
16:03
Obwohl ich da eigentlich vier gestartet habe. Mal anhalten. Habe ich zwei? Mal gucken. Drei, vier irgendwie. Ein SED, zwei SED, drei SED. Ach so, oh. Okay. Ich habe zwei gestartet und einen sehen wir.
16:22
Das ist jetzt nicht überraschend, wenn man das oft genug gemacht hat. Das ist sehr überraschend, wenn man überlegt, was man erwarten würde. Jetzt machen wir da vier hin. Dann den Top wieder. Jetzt lasse ich den mit vier laufen. Jetzt würde ich mir wünschen, dass ich vier SEDs sehen würde.
16:41
Ich kann schon sagen, das wird man wahrscheinlich auch wieder nicht sehen. Ich kann den Output von dem X-Term mal... Eigentlich sollten es drei sein. Ich habe das schon so oft gemacht, da sind immer N minus eins SEDs. Ich habe noch nicht rausgekriegt, warum. Das gibt dann auch mal noch irgendeinen Vortrag. Aber egal.
17:01
Wenn ich dann vier CPUs habe, dann habe ich halt fünf SEDs. Man sollte immer ein bisschen mehr Arbeit zur Verfügung stellen, damit die CPUs was zu tun haben. Und jetzt kann man das mal irgendwie in... Das ist die erste Seite von dem Output.
17:21
Das ging los mit Zeile 1, 2, 3, 4, 5. Und der erste Output, der da kommt, ist Zeile 456. Und die ist gar nicht mehr so richtig eingerückt. Das sieht alles komisch anders aus. Wenn ich da jetzt mal durchgucke und runterscroll, ups. Das geht dann bis Zeile 600 Schlagwichtung. Da kommt die Zeile 1, 2, 3.
17:41
Und dann kommen da die Zeilen 100 bis was weiß ich wohin. Ja. Ah. Der Punkt war, bei Perl könnte man die Prozess-ID mit ausgeben. Ja. Wollte ich gerade sagen, ja, kann ich auch machen.
18:04
Zurückgehen. Hilft uns für das eigentliche Problem. Ich habe es kurz gezeigt. In SED habe ich keine Möglichkeit, auf mein $$ Direct zuzugreffen. Das hätte ich jetzt in Shell gemacht. So meine Shell. Und ich zeige gleich, warum das eine blöde Idee ist. Aber ich könnte was anderes. Doch noch eine Shell weiß. Wo soll Perl das $$ her haben?
18:21
Wenn nicht von der Shell. Wenn ich das mache, dann kriege ich ... Ja, das ist jetzt die Prozess-ID 3600. Immer noch. Weil das ist jetzt das $$ von meiner lokalen Shell. Das ist genau ... SED hat das noch nicht. Aber was ich natürlich machen kann, ist ... Um das kurz zu zeigen.
18:40
Ich kann jetzt hier sagen, ich bin SED 1. Ich hänge hinten einfach eine 1 dran. 2 dran. Aber es ist interessant. Dann wissen wir auch mal, welcher SED nicht kommt. Wir fangen an mit SED Nummer 2. Ganz hinten. Guter Punkt. Dann kommt irgendwie der SED Nummer 3.
19:00
Was Output liefert, da kommt dann die 4. Dann kommt die 3. Und die 4 und die 3 irgendwie. Und das geht so ein bisschen kunderbunt durcheinander. Da ich das jetzt ziemlich spannend finde. Wenn wir wissen, welcher das ist, jetzt machen wir ein Pipe ein bisschen. Wir schnippeln die Zeile an den Ys auseinander. An den Ys auseinander.
19:21
Ganz langsam. Und nehmen die 3. Spalte. Also Y sind die Trennzeichen. Dann ist die 1. Spalte vorne. Und die 3. Spalte. Danke schön. Und dann kriege ich nur noch hinten im Wesentlichen die Nummer. Das läuft so durch. Und wenn man das ein bisschen zusammengefasst haben möchte, da gibt es das tolle Commando Unique-Ziel, das in keinem Vortrag fehlen darf.
19:41
Und dann sieht man immer die Anzahl. Und welche Zahl ist. Da kam 185 mal der SED Nummer 3 und Nummer 2. Und zwischendurch kam immer mal so ein Störenfried mit irgendwas anderem. Also da passieren ganz viele Dinge, die nicht so aussehen, wie man das richtig tut. Deswegen jetzt die Frage, was passiert mit dem ganzen Input? Ja.
20:01
Dafür. Das habe ich es ja damit. Aber wir sehen, es laufen die SEDs 2, 3 und 4. Warum 1 nicht läuft? Wie gesagt, das muss ich mal noch ergründen. Ich habe da so Ideen. Es sind immer n-1 in den Fällen, wo ich das mal ausprobiert habe. Wo kommt denn der Input hin?
20:22
War die Frage. Die ist durchaus sehr berechtigt. Was die Bash macht, ist, die startet jetzt mehrere Kindprozesse. Ich habe hier einen SED, der liest halt von Standard-Input, vom Falldeskriptor 0. Und das machen die auch im Hintergrund alle. Und das heißt, ich habe da nachher 4 Prozesse, die lesen alle von dem gleichen
20:40
Falldeskriptor, der durch diese Pipe angelegt wird. Also das Verteil schreibt irgendwie in so eine Pipe rein. Das ist so ein IODevice, wo der Kern dafür sorgt, dass das irgendwie richtig tut. Und alle wollen was lesen. Und das tut jetzt nur so in Unix, dass wenn auch genau von einer Datei oder einem Socket irgendwas, wenn da mehrere einen Read machen,
21:00
dann kriegt der zuerst, der zuerst das Read aufgesetzt hat, meistens zumindest. Das sind alle im Lesen und einer davon kriegt. Also ein bisschen random, aber wenn die sagen, ich will was haben, und einer kriegt halt so einen Happen hingeworfen, wie im großen Vogelnest. Und während der am Verdauen, und der macht ja dann was mit und macht wieder einen Read und wartet wieder. Aber bis dahin sind die anderen drei ja noch übrig geblieben. Das heißt, wenn dann wer's kommt,
21:21
dann kriegt einer von den anderen. Also das geht eigentlich schön der Reihe nach durch. Das würde eigentlich im groben und ganzen genau das machen, was man gerne haben würde. In welcher Reihenfolge das passiert, ist mir ja egal, weil ja alle, bis auf jetzt diese SED-Nummern hinten dran, genau das Gleiche machen. Die sollen ja immer genau das gleiche Regelwerk bearbeiten. Von daher ist das gar nicht schlimm. Aber,
21:41
also um den einen rum und um, wie gesagt, das ist ein unabhängiges Problem, aber wir haben gesehen, das ist irgendwie gar nicht, das ist irgendwie kaputt. Oh, jetzt fängt er mit Zelle 1 an. Und wieder mit Zelle 1. Ist das durch das Regelwerk anders geworden? Weiß ich nicht. Interessant. Aber wir haben gesehen, also mit dem Rollstuhl von der hinteren Nummer, da geht auch so einiges schief.
22:04
Und nachher so ein Test wird sein, ich gehe hinten her, ich nehme zum Beispiel mal die ersten 1000 Zellen und ich bilde einfach die Quersumme. Das soll ja immer das Gleiche machen. Ich lasse das Thema laufen, dann kommt das Thema gleich. Und das würde ich jetzt vergleichen wollen mit, ich mache das, also,
22:20
wie? Also wenn es richtig läuft, soll ein oder mehrere SEDs immer das gleiche machen. Und ich sehe schon, also erstens sich die Zellen kutteln, muddeln und so was. Und es kommt jedes Mal eine andere Prüfsumme raus. Das heißt, der Inhalt ist jedes Mal was anderes. Das tut noch nicht so richtig reproduzierbar, ist blöd. Warum ist das so? Ja, einen Teil habe ich schon verraten.
22:41
Alle die SEDs warten jetzt und lesen was. Machen das da rein nach. Und wenn man das genau wissen möchte, da gab es mal hier vor vielen, vielen Jahren einen Vortrag über S3s. Und da gibt es noch zwei schöne, da habe ich noch Papers geschrieben. Mit S3s kann man einfach gucken, lass mal so ein Prozess wie jetzt dieses Bash und alle Kindprozesse, deswegen Minus F,
23:02
und guck denen zu und zeig alle Systemcalls und sowas an, was die machen. Das Blu wird ein unendlich voll. Aber wenn man genau hinguckt, kann man da schon ein paar schöne Sachen sehen. Weil ich kann jetzt natürlich so erzählen, was da passiert. Und man sieht in verschiedenen Prozessen, der eine macht einen Read und Write und irgendwas.
23:23
Und da vorne stehen die Prozess-IDs. Das Spannende ist, man kann gucken, wer sieht einen Read? Hier kommt ein Read. Irgendeiner, wenn man das jetzt reinschreibt, kann man gucken, welcher SID ist, was und irgendwie. Aber irgendein Prozess, der 18033 geht jetzt her und sagt,
23:40
ich will was lesen können. Das hat er da oben gesagt, 18033. Ich hätte jetzt gerne mal was zum Lesen. Anfinished, oder jetzt muss er warten, bis er irgendwann mal Daten kriegt. Und wir sehen, was er an Daten kriegt. Er kriegt ein Y, Zeilenende. Und wir sehen ein bisschen mehr. Der Read hat gesagt, ich hätte gerne 4096 Byte. Und das System sagt,
24:01
du kriegst jetzt 4096 Byte. Weil diese ganzen I.O. Sachen, wenn sie nicht auf ein Terminal passieren, Terminals sind spezieller Klasse von Geräten, da tut es mit dem I.O. ein bisschen anders. Wenn ich von Files, auch von Sockensocken was lese und sage, ich will Read, da gibt es irgendeine generische Blockgröße, die gut ist, die das System vielleicht vorhält, dass es performant und so ist. Bei Pipes im Normalfall 4K,
24:21
bei Files eventuell auch. Und dann gibt mir also 4096 Bytes so eine Page, eine Hardware-Seite, die auch für den virtuellen Speicher verwaltet werden kann. Und er liest eben genau 4096 Byte rein. Das heißt, das erste SED, das da kommt und zuerst Read geschrien hat und den Schnabel aufreißt, kriegt die ersten 4096 Byte.
24:40
Und dann kommt das nächste Read und kriegt die nächsten 4096 Byte. Wenn wir jetzt angucken, wie die ersten 4096 Byte angucken, dafür gibt es auch ganz tolle Commando-Tools. Nimm den Input-File mit einer ganz guten Suntags, nimm eine Block-Size von 4K und zeig mir mal genau einen an. Und nimm die richtige Datei.
25:00
Das ist der originale Input-File. Da sieht man es im Prinzip nicht so richtig gut. Wir wollen unser Yes-Tingens haben. Yes-Totty. Also das ist das, was in diese ganze SED-Kiste reingeht. Ohne Input-File jetzt. Zeig mir mal den ersten Block in dieser Pipe.
25:22
Mach da hinten mal noch einen Echo oder zwei. Dass wir sehen, wo das aufhört. Das ist ein blödes Beispiel gewesen. Man muss sehr genau hingucken, dann stellt man fest, hier ist noch ein Space übrig. Also der hat die ganzen Zeilen ausgegeben und noch ein Space. Das Problem im Allgemeinen ist eben,
25:42
dass er jetzt immer unabhängig, der SED liest nicht Zeilenweise, wie er das so intern nachher tut, sondern er liest immer 4 Kilobyte rein und guckt sich dann die Zeilen danach an. Das heißt, der erste SED hackt halt irgendeine Zeile bei 4K, kriegt die erste Hälfte, und der nächste kriegt so einen Brocken mitten in der Zeile. Das ist das, was wir dann eben auch hier sehen.
26:01
Dass da immer ganz viel kaputt ging. Ein schönes Beispiel. Da ist halt jetzt irgendwo die Zeile mit 365. Das hat der SED davor noch gekriegt und dann fängt das ein bisschen weiter hinten. Deswegen fängt er Spaces und irgendwann hächelt er sich hier so durch die ganze Zeile durch. Da fällt jetzt halt noch mehr. Da ist so die halbe erste Zeile nach hinten verschwunden.
26:21
Und deswegen geht das alles nicht richtig gut. Und dann könnte auch sowas passieren. Da hat der ein SED noch ein bisschen was ausgegeben. Dann kommt der andere SED und schmeißt dann den Output von 525 dahinter und so Zeugs. Ups. Der SED 4 hat bis hierhin ausgegeben, ganz offensichtlich. Seine letzten Worte hören irgendwo hier auf.
26:40
Und dann kommt der SED Nummer 2 und sagt ich hab doch da mal vorher und solche Sachen. Also dadurch, dass die ganzen 3 Aussagen geblockt kommen und immer in 4K in Binär blöcken, wie das total verquem ist, ist weder der Input so richtig gut, noch der Output so richtig gut.
27:11
Also der Kommentar war in anderem programmiert. Also ich mach jetzt nur so Kommandozeile und Pipes, weil das ja total einfach geht. Da ist das zunächst mal einfach so. Und man kann das dann, wenn man den C wirklich programmiert, man kann sagen, ich will diesen IO
27:22
wirklich line buffert haben, was immer das dann im Einzelnen genau macht. Weil in so einem Stream oder irgendwie, da weiß ich ja gar nicht, wie viel weit müsste ich den lesen, um genau einen, also er muss dann jedes Zeichen einzeln lesen. Aber ich kann das umstellen, ich kann dem IO-System sagen, mach mal dies oder jenes für mich oder mach die Buffer-Size größer. Buffer-Size alleine hilft in dem Fall nicht, weil ich ja gar nicht weiß, wie lang die Zellen sind.
27:42
Nehmen wir zum Beispiel diesen Unterschiedlichlang. Das heißt, wenn ich überlege, was da jetzt passieren muss, ist, ich müsste tatsächlich jedes Zeichen einzeln lesen und ich muss sofort aufhören mit Lesen, wenn das Zeilenende kommt, weil dann habe ich ja jetzt meine Zelle für meinen SED zum Beispiel. Ja, aber wenn jetzt viele parallel immer genau ein Zeichen lesen oder das Zeilenende, da kommt das erste Zeichen in den ersten Leser,
28:00
es geht auch nicht. Also es sind da eine Menge Probleme drin, ist schwierig. Und deswegen ist das da irgendwie komplizierter. Also so einfach paralysieren geht einfach, das ist blöd. Aber irgendwie muss es ja gehen und nicht so krübeln und machen und tun. Boah, und die Zeit ist ähm, wieviel Stunden darf ich überziehen?
28:22
Es gibt jetzt eine Reihe von Lösungen, wie man das angehen kann. Also eine ist die Brutal-Methode, die ist jetzt natürlich mal erstens, ich nehme den, also wenn jeder SED seinen eigenen Input hätte, dann wäre das ja gut und die nicht immer so häppchenweise von irgendwo lesen.
28:41
Richtig elegante, einfache Lösungen, nur mit der Shell sind mir erst mal nur eingefallen, ich mache da jetzt mal, ich nehme nur noch die ersten 100.000 Zeilen oder so was und tue die mal in irgendein Input-File. Wie klein ist das? Das ist zu wenig, oder? Null dran. Noch ein paar Zeilen, so.
29:00
Jetzt haben wir die ersten, das was ich will, 1000 Zeilen. Und jetzt können wir mit denen mal rumüben und lassen das. Und jetzt kann ich natürlich hergehen und dafür sorgen, das ist jetzt nur als Beispiel, weil wir gleich sind, das ist alles supermühsam. SED kann noch viele andere tolle Sachen und dann kann man sagen,
29:22
minus 1, wie viel sind das? 10.000 Zeilen? 10, damit ich die richtige Anzahl von Nullen habe. Geh mal nur her, gib die Zeilen, minus N gibt nichts aus und von 1 bis Zeile 2 und irgendwas, gib mal genau die Zeilen aus.
29:42
Und nur die. Und das packe ich in so einen ersten SED rein. Das macht man dann mit einer Vorschleife und guckt sich das an, wie das geht. Und der zweite kommt her und sagt, die richtigen Anzahl von von 2,5 zu 1 bis
30:01
4.000 und packe das in den SED Nummer 2 rein. Ihr kriegt die Idee und dann mache ich von 4 irgendwas bis 6 irgendwas. Das Schöne an dem ist jetzt, der erste SED macht die ersten 2 Millionen oder irgendwas, die nächsten 2 Millionen und macht das alles.
30:23
Das heißt, ich habe kein Inputproblem an der Inputseite mehr und dann kommt das an. Wenn ich das dann angucke, was da rauskommt, dann dauert das erstmal. Hab ich was falsch gemacht? Die brauchen noch Input-Dateien vielleicht. Wie ist Kipping?
30:48
Wen muss ich denn killen? Jetzt sind es zu viele L2, waren es zu wenig. Oh, da sind noch ein paar SEDs übrig.
31:03
Schon gestorben. Die Frage war, kann man die Falldiskripturen duplizieren? Ja, das macht die Pipe Automatik. Es gibt einen Standard Input und die Shell durch diese Pipe. Geht in den Hintergrund.
31:21
Aber der muss jetzt natürlich wissen, von wo her. Dafür hatte ich da mein Inputfile 1. Der soll auch vom Inputfile 1 lesen. Also diese Zwischendatei. Jetzt müsste es besser gehen. Und jetzt kommt Output irgendwas raus. Das Blöde an dem Beispiel ist jetzt natürlich, wenn ich Glück habe, komme ich sogar noch in der
31:40
richtigen Reihenfolge, aber ich habe da auch keine Garantie. Das ist aber nicht ganz so schlimm. Ja, jetzt könnte es passieren, dass der hier hinten zuerst den Output liefert, weil das jetzt eher zufällig ist, in welche Reihenfolge die ausgeführt werden, weil die ja wirklich parallel laufen. Das ist aber eigentlich nicht schlimm. Dafür gibt es die tollen Zellen auch. Und dann kann ich einfach sagen, sortieren wir das mal wieder nach der Zeit oder der Zellnummer vorne dran. Und dann passt das dann schon
32:01
irgendwie. Ich komme mal nach vorne und dann sieht man schon, dass im Wesentlichen das jetzt richtig sortiert ist. Aber das Sortieren, was ein toller Test für solche Sachen ist, macht das mal irgendwie zusammen, zeigt auch, ja, es gibt Ausnahmen. Obwohl ich da jetzt den Input alles richtig gemacht habe. Jeder hat wirklich,
32:21
also wenn ich das angucke, was da rauskommt, wie testet man sowas? Das ist doch, also ich habe behauptet, hier ist alles gut. Dann kann man sagen, T-Output eins. So T ist so ein T-Stück in so einer Pfeife, in einer Röhre, in einer Pfeife. Da wird es dupliciert. Dann schreibt das immer in den Output-File. Also ich kann das erstmal einfach so machen, wie die Brutalversion ist.
32:40
Schreibt mir den Output in O1 rein. Schreibt mir den Output in O2 rein. Und, oh, danke. Ich dachte gerade, wo muss ich so weit rüberschreiten? Schreibt diesen Output in O2 rein. Zum Angucken, warum geht das nicht so, wie ich mir das denke. Schreibt mir den Output in O3 rein.
33:01
Dann kann ich jetzt noch, jetzt gibt es halt nichts mehr zu sortieren, aber ich habe dann Dankeschön. Jetzt haben wir auch noch einen O3. Und wenn ich mir die angucke, die Anfänge oder irgendwas, das sieht alles schön aus. Die Enden sind schön. Der einzelne SED-Prozess ist gar nicht das Problem. Die lesen jetzt richtig, was sie sollen und machen genau das Richtige.
33:22
Und trotzdem kommt hinten Müll raus. Warum? Weil genau das, was ich für den Input gesagt habe, mit diesen 4K-Blöcken, das gilt natürlich für den Output genauso. Wenn man Konzepte hat, dann macht man die immer wieder. Jeder SED macht jetzt so viele Prozesse. Und wenn man 4K hat, dann wird die ausgegeben.
33:40
Das heißt, im Ausgang von diesen vielen Parallelprozessen, den Kindprozessen, ich habe wieder 4K-Output. Und die hören natürlich wieder mitten in einer Zeile auf und es geht wieder schief. Das heißt, da ist Problem Nr. 2, wobei, wir haben jetzt schon die Lösung von Problem Nr. 2 gesehen. Wir lassen das so mehrmals im Hintergrund laufen.
34:00
Wir brauchen die ganzen Sortpipes sonst, irgendwas nicht. Und jetzt muss ich nur noch die Sender danach ausgeben. Dafür haben wir ein Kommando. Das ist dann eigentlich Cut. Da können wir gleich hinten hinschreiben. Sortiert die mal alle irgendwie. Und dann machen wir Cut. Und dann gucken wir uns die... Das Geniale daran
34:21
ist jetzt sogar, wenn der in der richtigen Reihenfolge nimmt, das erste N-Häppchen, also ich kann das mit 8 CPUs machen. Ich gucke mir einmal an, wie viele Zeilen habe ich denn. Dann tue ich Zeilenzahl durch 8 teilen. Mache dem ersten das erste Achtel, das zweite Achtel, das kann man alles in der Reihenfolge machen. Wenn ich das mehrmals mache,
34:44
dann hätte ich jetzt, eigentlich war das immer das gleiche. Ah, sehr gut. Da ist der schon fertig. Muss ich da noch ein Wait machen. Weil jetzt alles im Hintergrund läuft. Die Schrift ist zu groß und man sieht das gar nicht mehr gut. Wo geht's her?
35:00
Das ist eine Shell, die macht jetzt alles im Hintergrund und die laufen da auch weiter. Während das Zeug im Hintergrund noch bröselt, machen wir wieder ein Time Minus C statt der Klammern. Dann sehen wir, wie lange das läuft.
35:21
So. Das läuft ja im Hintergrund trotzdem noch. Dann können wir A sehen. Ach, da waren auch noch Single Quotes. Dann nehmen wir da weg. Wir haben ja ganz viele Quotes. Also, ich gucke mir an, wie lange diese Sub-Shell mit irgendwas läuft. Die lasse ich jetzt auch im Hintergrund noch mal laufen und mache dann so lange schon mal den Output von irgendwas.
35:43
Und dann sieht man halt, also das MD5 ist zuerst fertig, wenn man Glück hat und oder nicht ganz, aber er schreibt jedes Mal noch rein und ist verschieden weit. Weil halt dieses Bash-Kommando, die ganzen SEDs auch 0,1 eine hundertstel Sekunde brauchen. Und das Cut fängt schon vorher an, deswegen sind die, ah, dann sehen wir das
36:02
natürlich auch so. Jetzt wo wir verstanden haben, dann gucken wir einfach an, wie viele Zeilen sind da jetzt in den drei Dateien drin. Null oder 2000 Zeilen oder 2000. Je nachdem, wie viel er schon reingeschrieben hat, weil er im Hintergrund noch macht. Und deswegen, also wenn man so Hintergrundprozesse, Kindprozesse in der Shell hat, gibt es einen Kommando-Weight in der Shell.
36:20
Da kann man sagen, warte mal bis ein ganz bestimmter Prozess fertig ist oder warte einfach bis alle Kindlein fertig sind. Dann habe ich wieder irgendwas falsch gemacht. Und vor den Klammern sollten wir noch ein Semikolon setzen. Und Semikolon. Und das Semikolon ist zu viel. Alle in den Hintergrund stellen und dann das Weight, warte mal bis alles fertig ist.
36:42
Und dann kommt tatsächlich das Cut und WC erst, wenn alle 600.000 Zeilen durch sind. Und dann kann man auch glauben, ah, ah Gott, nicht zu viel. Wenn ich das dann mache,
37:01
kommt immer das Gleiche raus. Der Output ist jetzt tatsächlich immer das Gleiche und reproduzierbar. Und das, jetzt brauchen wir mehr Output. Ah, das geht. Jetzt muss man im Top sehr schnell, also ihr seht, wenn ihr da drauf guckt, seht ihr wirklich, ist ja eigentlich auch klar, ich habe die drei O-Files und so. Der macht das jetzt schön parallel, total toll.
37:20
Großer Nachteil ist, ich muss erst die ganzen Dateien abspeichern. Das heißt, wenn da mal, also mein Original Input war ein 190 Gigabyte Lokfall. Das heißt, ich brauche nochmal 190 Gigabyte Zwischendatei. Dann teile ich die auf und sortiere die, dann komme ich in kleinen Häppchen, die SED-Files sind ja nochmal 190 Gigabyte. Das heißt, aus meinem Input, der eigentlich nur eine Pipe war und eventuell
37:42
gar nicht auf der Platte lag, liegen jetzt plötzlich zwei Kopien rum, den Inputzeugs und den Outputzeugs, bis ich das dann machen kann. Ist ziemlich blöd. Und dann lasse ich vielleicht noch die Kopien liegen. Aber so würde es tun, da drum umzukommen. Ich habe den Vortrag vor kurzem in Tübingen gehalten und da war, ich habe schon länger so eine Idee,
38:00
man kann da jetzt mit Perl und Pytons was machen oder auch ich mache sonst AWK. Ich werde irgendwann hergehen. So was Ähnliches treiben, dass man mehrere SEDs als AWK-Sub-Shels macht und da dann immer eine Zeile reinschreibt. Also das Aufteilen, was ich da gemacht habe mit SED, das geht auch mit AWK total toll. Ach nee. 1, irgendwas.
38:22
Ja, danke. Also solche SEDs, AWK kann man schönes sagen. Und dann sagen, na, ich tu die Das ist das erste SED, die zweite ist das zweite oder so und handelt das mit Puffern. Wenn ich aber das Zeilenweise auf mehrere Parallelprozesse verteile, dann habe ich wieder das Problem, dass ich die am Schluss zusammensortieren muss und sagen, okay, die müssen jetzt irgendwie in der richtigen
38:40
Reihenfolge zusammenkommen, weil die es irgendwie rausmachen. Weil dann der SED die ersten 10 Zeilen und der zweite SED die zweiten 10 Zeilen macht, aber die haben die Zeilen 1, 2, 3, 4, 5, 6, 7, 8. Da kann man dann sort machen und dann wird man ganz schnell feststellen, so bei ein paar Millionen und 100 Millionen Zeilen ist sort das große Problem. Das fängt eigentlich schon viel, viel früher an.
39:01
Weil sort also durchaus viel Zeug hat. Wenn man die Sortman-Page durchliest, da gibt es dann eine Option, wie viel Memory ernehmen kann. Und wenn man genug speichert, dann kann man sagen, nimm mal 10 GB und pack das ins RAM rein. Das hilft. Aber auch wenn er alles ins RAM packt, tut er immer noch eine Kopie auf Temps schreiben. Also eine Kopie macht er immer, ich hab keine Ahnung warum. Das mit dem Zusammensort hier ist auch nicht so richtig.
39:20
Aber ich kann mit dem AWK auch hergehen und sagen, nimm mal die ersten 1 Millionen Zeilen, tu sie in den ersten SED, tu die zweite Millionen in den zweiten SED. Dann ist das Problem, dass ich die auf der Platte zusammen puffe und geh dann her und tu auf der Platte das Zeug wieder nacheinander serialisieren und machen und die Dateien auseinanderlesen.
39:41
Auch blöd. Das kann ich dann, wenn ich genug speichere, wieder sagen, ok, ich lese mal das erste Gigabyte in irgendeinen RAM-Puffer, dafür gibt es DD, dem kann man sagen, mach mal genau Block-Size ein Gigabyte und tu das mal da rein und puffe das mal im Speicher und schieb das durch den ersten SED durch und der erste SED pipe das wieder rein in ein DD, der wieder einen Gigabyte
40:00
RAM hat und sich das mal aufsammelt. Und das Gigabyte muss so groß sein, dass der gesamte Output reinkommt. Nicht, dass ich nach einem Gigabyte wieder so ein Block-Problem habe. Kann man machen. Da werde ich sicher noch weiter experimentieren, aber irgendwann, wo ich so einen Vortrag gehalten habe, wie man das macht, da kam dann einer bei uns in Tübingen am Stammtisch und hat gesagt, da gibt es ein Tool für.
40:20
Und das Tool kenne ich eigentlich auch schon, aber es seit wirklich wenig in Jahren und wenn man das parallelisieren möchte, gibt es ein Tool, das nennt sich Parallel. Und mit dem kann man eben sagen, aber meistens macht man damit was anderes, nehme ich, ich habe da ein Programm und mache da mal das Programm auf ganz viele Dateien. Also zum Beispiel, wenn ich 10.000 Urlaubsbilder habe, dann kann ich sagen Parallel, irgendein JPEG-Tool,
40:41
Standpunkt JPEG und dann die Zeit umsetzen, die Sachen konvertieren, das ist total, früher habe ich immer Makefiles fürgeschrieben und das Makefile, lass mal so viele C-Views, wie ich habe, magische Make-Rules, die kann man richtig verstehen, total toll. Und das Parallel mussten sie irgendwie auch können. Dann haben wir dann angefangen Pipe-Namen zu lesen, ja, da ist sogar was mit Pipe drin und bla, und ganz viel Pipe, aber das Problem
41:02
an Parallel ist, und dann, mannpeitsch ist lang und wenn man guckt, wie das da so durchgeht, überall flitzen mal so schwarze Kästchen mit Pipe hier, Pipe da, Pipe irgendwas auf, aber wir haben es an diesem Abend nicht geschafft, das mit Parallel richtig hinzukriegen, aber das hat mich nicht losgelassen, wo ich dann daheim war, bin ich hergegangen, habe dann weiter die Mannpeitsch gelesen
41:22
und wenn man die Mannpeitsch lange genug liest und alle Optionen mal so ungefähr durchprobiert hat, dann findet man diesen wunderbaren String, Parallel, mach mal 8 Prozesse linebar vorbei, brown, brown, die sind alle irgendwie wichtig und die sorgen dann dafür, dass das genau das Richtige tut. Jetzt sind wir wieder irgendwo hin.
41:42
Nehmen wir mal die ersten Zeilen davon. Jetzt können wir gleich mal noch eine Null mehr spendieren. Jetzt sind wir ganz toll parallel. Und der Test kommt da immer das Gleiche raus. A kommt immer in P5, ja genau.
42:00
Es kommt zumindest immer das Gleiche raus, das kann ja jetzt immer noch jeder sagen, also der richtige Test wäre natürlich wir nehmen einmal das Original SED, das ist ja das, da glauben wir alle dran, dass zumindest das ist, was reproduziert wird. Ob das das ist, was ich haben wollte, ist ein ganz anderes Thema. Und irgendwo ist ein und so viel.
42:20
Warum ist das dann gerade eben gegangen? Das müssen wir nochmal genauer. Genau, wer kennt die Hash? MD5, ich dachte doch, das habe ich schon mal gesehen. Wir müssen so langsam. Das ist die Hash von Null Bytes.
42:44
Der andere A, da machen wir doch wieder eine Null weniger. Fehlt da was? Das kann der MD5 natürlich aus dem Pipe. Also das war der eine SED, ok, jetzt müssen wir das wieder parallel machen. Und dann ist es nur deswegen so schnell gegangen,
43:01
weil hier die Quotes natürlich auch falsch sind und irgendwo eine Fehlermeldung im Wärmen nach verschwindet. Weil aus diesem Akrobad mit Cut und Paste die falschen Quotes rauskommen. Spannend. Kommt noch was Falsches raus. Und jedenfalls anderes. Das ist jetzt gemein. Wenn man es richtig macht, das tut tatsächlich.
43:22
Ich glaube, das ist das zweite Thema von Workshop morgen, falls es jemand interessiert. Langer Rede, kurzer Sinn. Man kann das hinkriegen, also das ist tatsächlich dann mit CPU-Minute pro SED mal ausprobiert. Warum es jetzt hier nicht tut, kann ich tatsächlich nicht sagen.
43:42
Ah, ich habe hinten den Sort weggelassen. Ich war der Meinung, über den Raum drauf ... Das Time ist noch drin, das ist kein Problem. Time kommt immer auf Standard Output und blubbelt mir über die Konsole. Das ist jetzt immer hoffentlich die richtige Anzahl von SED. Aber das Sort kann wirklich fehlen.
44:01
Das lassen wir noch probieren. Und jetzt war das Sort Minus. Steht das in der Folie drin? Nein. Minus groß, G ein Gigabyte, glaube ich. Oder M? Irgendwo. Memory. Groß S.
44:21
So. Macht, dass das gleich herauskommt. Also, tut tatsächlich, ist getestet. Das Sort ist tatsächlich ... Das sind jetzt lächerlich wenige Zahlen. Wenn das mehr zahlt, ist das auch ein Problem. Kann man machen. Ich wollte einen Benchmark machen mit den echten Daten. Also mit dem echten SED,
44:40
der so ganz lange braucht für die echten Sachen. Und da sind ganz überraschende Dinge passiert, weil dann, egal, was ich mit dem Parallel anstelle, kommt nur noch ein SED-Prozess zum Laufen. Das ganze Parallel ist in Perl geschrieben. Mit ganz viel Perl. Und ich kann keinen Perl.
45:01
Und ich hab da länger reingeguckt. Also es hat was mit Buffering und so zu tun. Es ist so, wenn ich ... Ich hab das versucht, auf meine 24 CPU-Maschine mit 24 Jobs zu machen, oder auch mit 8. Wenn ich 16 Mal mehr Input reinschiebe, dann fängt er wieder an, 8 SED-Prozesse zu machen. Das ist eine Sache. Wie viel Input ich da liefere, damit er genug Arbeit hat.
45:21
Dann braucht er aber pro SED-Prozess wieder mehrere CPU-Minuten. Und ich konnte nicht schnell meinen Benchmark machen. Das SED puffert irgendwie mehr. Es scheint zu gehen, aber nicht für die Sachen, die ich haben möchte, dass das gut parallel ist. Das Parallel ist an der Stelle ein bisschen schwierig. Deswegen nur noch der Hinweis auf, man kann das auch ganz anders machen.
45:40
Und zwar darüber nachdenken, dass diese Rules, die so vollautomatisch und einfach hingezaubert sind, ich gehe auf jede einzelne Zelle her und tue alle 4.000 Regeln, anwenden, suchen, ersetzen, suchen, ersetzen, suchen, ersetzen. Ich mache das auch, wenn ich schon was gefunden habe. Und da können wir morgen vielleicht drüber unterhalten, ein bisschen drüber nachdenken, wenn irgendwas lange dauert. Was mache ich denn eigentlich, was sind denn meine Daten,
46:01
was wollte ich denn wirklich haben? Dann kann man das nicht viel einfacher machen und dann sind es keine 20 Minuten, sondern 20 oder 10 Sekunden geworden. Wer noch Fragen oder Anregungen sonst hat, dann könnt ihr gleich gerne auch draußen. Und heute Abend beim ... Nein, nicht beim Schnitzel, beim Pult Fork habe ich gerade gelernt. Ja, und erst mal noch viel Spaß heute und morgen auf der Frostcon. Dankeschön für eure Geduld.