06:55:31 Schrompf joined the channel
08:08:41 xq: moin
08:09:05 xq: kennt jemand von euch ne günstige industrie-immobilie bis zu 400m² in Stuttgart? :D
08:21:26 Schrompf: das stadion
08:21:27 Schrompf: moin
08:23:20 xq: das sind mehr als 400m²
08:23:24 xq: aber folgendes problem:
08:23:37 xq: dem shackspace werden die räumlichkeiten gekündigt, weil das gebäude abgerissen wird
08:24:03 Schrompf: och shit
08:24:13 Schrompf: die gentrifizierung schlägt zu
08:25:41 xq: das war seit 10 jahren absehbar
08:25:58 xq: Quasi "Wenn die S21-Baustelle fertig ist, verschwindet das Gebäude"
08:26:28 xq: wir sind auch weit weit unter mietspiegel (schnitt sind so 10-12€/m², wir zahlen weniger als 4€/m²)
08:28:06 Schrompf: ist halt schade. mit all geschniegelten hochglanz investment portfolio bleiben halt so kleine nischenanwendungen auf der strecke
08:34:04 Schrompf: xq
08:34:07 Schrompf: du kennst dich doch aus
08:34:24 xq: yo
08:34:41 Schrompf: ich hab ne aufgabe. die rechnet eigentlich immer das gleiche
08:34:57 Schrompf: ich feuere die ab, und sie dauert 45s
08:35:14 Schrompf: ich feuere zwei davon parallel ab und sie dauert leicht länger
08:35:42 Schrompf: obwohl keine sync, keine dependencies, quasi instant networking und scheduling
08:36:00 Schrompf: hab einen schicken graph gemacht, von 1x bis 31x parallel
08:36:23 Schrompf: natürlich sieht man nen heftigen sprung bei 17x, da kickt das hyperthreading
08:36:44 Schrompf: aber auch vorher sieht man nen leichten konstanten anstieg. von 45s bei 1x bis 53s bei 16x
08:36:55 Schrompf: wo kommt der her? kann ich dem irgendwie auf die schliche kommen?
08:37:18 xq: was tut das ding (also resourcenmäßig)
08:37:24 xq: nutzt es threads?
08:37:25 Schrompf: rechnen
08:37:27 Schrompf: ja
08:37:30 xq: also quasi kein I/O?
08:37:43 Schrompf: ja, nur einmal am anfang ein paar kb tcp
08:37:49 Schrompf: und am ende, um die ergebnisse zu verschicken
08:38:02 Schrompf: aber das dauert doch sicher keine 8s
08:38:17 xq: welche cpu utilization?
08:38:27 xq: wahrscheinlich 0.99 something, oder?
08:38:46 Schrompf: ja
08:38:53 Schrompf: also 0.99, 1.99, 2.99 usw
08:39:21 xq: okay
08:39:28 Schrompf: kannst den grafana-screenshot kriegen, wenn du willst. ab 17x gibt's einen fancy HT-hüpfer, für den ich ein bissl brauchte, um ihn zu kapieren
08:39:32 xq: du hast 16 kerne?
08:39:41 Schrompf: ja, 16 physische kerne
08:39:46 xq: also 32 SMT?
08:39:52 Schrompf: 32 HW-threads
08:39:54 xq: okay
08:40:01 xq: starte mal 15 stück pinned zu jeweils einer CPU
08:41:26 Schrompf: du meinst 15 prozesse anstatt einem prozess mit 15 threads?
08:42:03 xq: oh, das war ein prozess?
08:42:07 Schrompf: ja
08:42:11 xq: ah
08:42:16 xq: kannst du die threads an CPUs pinnen?
08:42:27 xq: aber ja, wenn du sowieso keine shared data hast
08:42:31 xq: mach prozesse
08:42:49 xq: weil dann versucht der scheduler nicht, die threads auf die selbe CPU zu schedulen
08:42:59 Schrompf: das ding hat ein read-only shared data. könnte sein, dass 15 davon gar nicht in den ram passen
08:43:12 xq: ah
08:43:24 xq: ja, dann pin mal die threads
08:43:40 Schrompf: mift. haben wir vor äonen mal ausgebaut
08:45:21 Schrompf: erstmal daily
09:04:23 Schrompf: ach scheiße
09:04:36 Schrompf: kann keine code-änderungen vornehmen
09:04:40 Schrompf: dann läd das image nicht mehr
09:04:58 Schrompf: wir importieren doch gigantische daten
09:05:20 Schrompf: und dabei generieren wir hunderte millionen kleiner funktionen, die wir in ein bündel SOs kompilieren
09:06:04 Schrompf: und das ding wiederrum zieht ne interne SO an, die exakt von der engine-version stammen muss, die beim import verwendet wurde
09:06:17 Schrompf: sonst kriegst du lustige datenfehler, wenn du die regeln auszuführen versuchst
09:07:56 xq: the heck?
09:08:02 xq: muss das hash-identisch sein oder wie?
09:13:01 Schrompf: ne, nur "soll halt laufen"-identisch. details habe ich nie nachgeforscht, nur einmal zu oft seltsame crashes erlebt, wenn ich versucht habe, ein anderes binary mit dem datensatz zu betreieb
09:13:42 Schrompf: moment, für's pinnen jedenfalls gibt's noch ne uralte command line option. vielleicht läuft die ja noch
09:14:28 Magister joined the channel
09:22:13 Schrompf: ok, core-pinnen macht es *drastisch* schlechter
09:22:21 Schrompf: das ist echt spannend im htop zu beobachten
09:22:36 Schrompf: das ding pinnt die 31 worker threads auf core 0-31
09:23:01 Schrompf: und wenn jetzt ein bündel requests ankommt, nehmen sich random die ersten worker, die aufwachen, jeweils einen
09:23:32 Schrompf: wenn jetzt zufällig zwei benachbarte worker sich jeweils einen job greifen, rechnen die 60% länger
09:23:36 Schrompf: weil: hyperthreading
09:24:12 Schrompf: vorher hat der linux-kernel die halt auseinander gezogen, solange noch "echte" kerne frei waren. jetzt durch's pinnen kann er das nicht mehr
09:25:26 xq: ja
09:25:32 xq: darum 15 prozesse, nicht 31
09:25:44 xq: 1 echter core per prozess
09:25:49 xq: damit dir das hyperthreading nicht den kram wegfrisst
09:25:54 Schrompf: und die auf jeweils core_idx * 2 pinnen. das kann ich nun wieder nicht
09:26:15 Schrompf: aber ich könnte einfach mal jeden zweiten hwthread disablen, das geht ja mit dem linuxkernel ohne neustart
09:26:39 Schrompf: (das ist auch der grund, warum ich HT nicht einfach ausschalte. das müsste man im BIOS machen, und der rechner steht in irgendnem hetzner-rechenzentrum in frankfurt)
09:27:10 xq: oh
09:27:18 xq: aber jo, echo 0 > /sys/class/cpu/…/online geht ja :D
09:31:52 Schrompf: nein :-) ich krieg selbst mit sudo ein "permission denied"
09:32:08 xq: ich hoffe aus einer rootshell
09:32:10 xq: und nicht
09:32:14 xq: sudo echo 0 > …
09:32:20 Schrompf: warum? wo ist der unterschied?
09:32:24 xq: sudo echo 0
09:32:32 xq: gibt 0 auf stdout mit rootrechten aus
09:32:47 xq: und deine shell leitet das dann mit "> /…" in die datei weiter
09:32:57 xq: sudo ist kein modifier, sondern einfach ein programm
09:33:39 Schrompf: das geht. ich hab angst
09:33:58 xq: du kannst nicht alle kerne abschalten, keine sorge
09:35:00 Schrompf: läuft. wird aber 15x50s brauchen, eh ich die ergebnisse sehe
09:37:20 Schrompf: ach beischlaf
09:37:31 xq: hm?
09:37:51 Schrompf: anscheinend gibt's da keine systematik, welche hw-threads und ihre geschwister auf welchen indizes landen
09:38:42 Schrompf: ich hab jetzt hier gerade drei jobs gesehen: auf 6,7,12 oder so. und der 6er ist nach 45s fertig, der 7er und der 12er nach 80s, wie als ob die beiden hyperthreaden
09:40:47 Schrompf: naja, zumindest müsste ich an der zahlenentwicklung sehen, ob dieser langsame stetige anstieg noch da ist
09:41:19 Schrompf: naja, ne, wenn ihr weiter irgendwas HTet, kann ich ja nicht ausschließen, dass der anstieg auch daran liegt
09:41:22 Schrompf: ficken
09:44:08 xq: kaka
09:45:58 Schrompf: es gibt /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
09:46:26 Schrompf: die sollte ich mal durchgehen und gezielt cpus disablen
09:49:32 Schrompf: muss nicht mal gezielt, ist einfach 0<->16, 1<->17 usw. ich hatte 0<->1, 2<->3 angenommen.
09:54:17 joeydee joined the channel
09:54:34 joeydee: moin
09:55:09 xq: huhu
09:56:45 Schrompf: hi
09:57:29 Schrompf: der anstieg der rechenzeit ist trotzdem noch da
09:58:53 xq: wild
10:09:30 Schrompf: pah. dann doch ganz simpel
10:10:02 Schrompf: die CPU-Taktfrequenz aus lscpu ist nur die des ersten Cores. Die steigt also nur, wenn zufällig gerade ein Job aufm ersten Core landet
10:10:09 Schrompf: daher hab ich da keine Connection gesehn
10:10:15 xq: well
10:11:06 Schrompf: mit 'watch "grep MHz /proc/cpuinfo"' krieg ich die taktfrequenz jedes kerns. und da sieht man mit ein bissl augen zusammenkneifen, dass der immer um ~50MHz runtergeht mit jedem zusätzlichen job
10:11:19 xq: ah
10:11:23 xq: thermal throttling?
10:11:27 xq: cpu temperatur auch beobachtet?
10:12:09 Schrompf: ne. müsste ich mal.
10:12:25 Schrompf: aber ich vermute eher: Power Throttling
10:12:38 Schrompf: also die designated power consumption oder wie die hieß
10:13:02 xq: jo
10:13:14 Schrompf: unter "thermal throttling" hatte ich verstanden: senkt frequenz wegen temperatur
10:13:20 Schrompf: also überhitzungsschutz
10:13:31 Schrompf: aber ich merke gerade, das hängt ja eh alles sehr unmittelbar zusammen
10:21:00 Schrompf: nagut, das ist durch
10:26:15 joeydee: xq, bei deiner SVG-zu-TVG-Interpretation, wie war das mit Pfadrichtungen (CW vs. CCW) - ist da beides erlaubt?
10:26:26 xq: ja, ist beides legal
10:27:33 joeydee: Wie kann man da eigentlich "innen" von "außen" unterscheiden?
10:27:45 xq: örm
10:27:48 xq: du fragst mich grade sachen
10:27:58 xq: ich weiß es grade tatsächlich nicht und hab auch keinen kopf dafür
10:27:59 xq: sorry
10:28:09 Schrompf: mit dem anzahl-schnittpunkte-theorem vielleicht?
10:29:28 joeydee: Für einen beliebigen Bildpunkt geht das, ja.
10:29:38 xq: ah, ja+
10:31:19 Schrompf: ansonsten: du kannst ja das winding ausrechnen. winkeldiff aller teilstücke müsste ja in summe -360 oder +360 ergeben für geschlossene pfade
10:31:47 Schrompf: leider halt nur in summe, teilstücke können ja in die gegenrichtung gehen bei konkaven fickern
10:33:30 joeydee: ja, ich will den Polygonzug traversieren, da könnte der winding-Test helfen.
10:33:44 joeydee: Den hatte ich nicht auf dem Schirm.
10:34:13 xq: der polygonzug? hält der auch an vertex 3?
10:35:00 joeydee: ja, 16_50 Uhr ab Paddington
10:36:37 joeydee: Weil der Schnitttest hat beim traversieren wieder Ausnahmen, ich weiß ja nicht auf ob "ein wenig links neben dem Segment" nicht schon wieder eine Kante überspringt.
10:39:35 Schrompf: naja, das könntest du mit ein bissl heuristik abfedern
10:40:21 Schrompf: also: "ein bissl links vom segment", dann "in richtung segment" und dann müsstest du 1 oder 2 oder 25 treffer kriegen, aber immer > 0. daran kannst du dann näher oder ferner hüpfen
10:40:45 Schrompf: ist aber alles quatsch, mit der winding-rechnung kriegst du ein bequemes "innen ist links/rechts des linienzugs"
10:41:48 joeydee: "ich weiß ja nicht auf ob ..." - sollte eigentlich heißen "ich weiß ja nicht auf Anhieb ob ..." - also ja, zwar lösbar, aber nur mit weiteren Tests
10:42:00 Schrompf: ja
10:42:12 joeydee: Winkelsumme war das Stichwort
10:42:18 joeydee: das sollte gehen
10:42:44 Schrompf: Sumkelwinne
10:43:05 joeydee: Sinkel-Wumme
10:43:31 Schrompf: Wink-Summel
10:43:37 Schrompf: ich bin müde
10:43:55 joeydee: In der Summe ist das ein Gewinnkel.
10:44:12 Schrompf: <3
10:46:19 xq:
10:46:23 xq: wie viel schaden macht die?
10:47:40 Schrompf: je nach Sinkel-Widerstand des Ziels, würde ich mutmaßen
11:03:53 joeydee: Wenn man die auf alle Polygone gleichzeitig anwendet, gibts den größten Schaden.
18:39:46 Magister joined the channel