09:10:43 IceMichael: moin
09:10:50 IceMichael: xq, hab mir jetzt das power profiler kit ii bestellt :D
09:15:23 IceMichael: oh, lieferzeit 120 Tage+
09:15:24 IceMichael: oh mann
09:16:43 IceMichael: brech ich vll doch wieder ab
09:43:51 IceMichael: na ja, ne, das scheint irgendwie schon das geilste Teil zu sein, braucht nur ewig grml... also gut, muss ich Projekte wohl erstmal 180d delayen :D
10:04:16 Magister joined the channel
11:01:03 Magister joined the channel
11:03:51 xq: moin moin
11:04:06 xq: IceMichael: sweet, aber 180d ist hart
11:04:12 xq: leider wird elektronik grade mangelware
11:04:35 IceMichael: :( wie kommt das?
11:04:41 IceMichael: ich hab es trotzdem bestellt, nuetzt ja nix
11:04:47 xq:
11:04:51 xq: wenn man das wüsste
11:05:22 xq: also, wir haben in der firma ernsthafte schwierigkeiten, neue chips zu bekommen
11:05:23 xq: es fehlt an allem
11:06:12 xq: https://www.digikey.de/products/de/integrated-circuits-ics/embedded-microcontrollers/685?FV=-8%7C685&quantity=0&ColumnSort=-1000009&page=1&nstock=1&k=stm32f&pageSize=25&pkeyword=stm32f
11:06:15 xq: klick mal hier
11:06:23 xq: das dürfte alles schon vorgefiltert sein
11:06:32 xq: stm32f ist nen verdammt weit verbreiteter µC
11:06:54 xq: schau an, wie viel verfügbar ist
11:10:12 IceMichael: pro Zeile so 100
11:16:32 xq: auf seite 1/5
11:16:38 xq: auf seite 2 ist das *maximum* 1
11:16:56 xq: sprich: pro variante sind im schritt noch 20 stück über
11:34:32 IceMichael: wow, ja, das ist echt hart
11:35:24 IceMichael: mal ne andre Frage, vll hast du ne Idee: bei nem Kunden crasht PR immer, ich weiß nicht, wieso. Ich habe bei ihm jetzt sogar ne VM gebastelt und auch da crasht es. In meiner VM und zig Computern crasht es nicht. Der Report zeigt einfach nur, dass er versucht was in den Speicher zu schreiben bzw. evtl. sogar nur nen Hash erzeugen will und kaputt geht
11:35:54 IceMichael: ich hab das nie irgendwo gesehen auf den ganzen Geräten und VMs und hab mich eh gefragt, ob bei ihm RAM oder so vll schrott ist. Aber ist nur meine Software, alles andere geht, also unlikely :D
11:36:13 IceMichael: aber der report meldet Probleme immer an Stellen, die bei meinen Tests problemlos laufen
11:36:38 IceMichael: na ja, gut, ob du ne Idee hast, in welche Richtung man weiterchecken könnte, ist wsl ne doofe Frage mit so wenig Infos
11:37:52 xq: keine ahnung
11:37:56 xq: er soll dir ein video schicken
11:38:01 xq: vllt. hast du nen bedienfehler-bug
11:39:30 IceMichael: nee, bin die ganze Zeit via TV drauf
11:39:47 IceMichael: hmm, also es könnte index out of bounds sein für nen Wert, den ich über __builtin_clz kriege
11:39:59 IceMichael: wenn das auf unterschiedlichen Maschinen unterschiedlich reagiert oder mal falschen output hat, wäre das ne Erklärung
11:40:07 IceMichael: bei mir ist das Resultat aber auf die ganze input range wohldefiniert
11:41:05 xq: örm
11:41:09 xq: spannende frage:
11:41:14 xq: für welches target compilierst du?
11:42:21 IceMichael: win10 oder was meinst genau?
11:42:28 xq: CPU
11:42:30 xq: OS
11:42:31 IceMichael: und x86/intel ganz normal
11:42:32 xq: ABI
11:42:40 xq: "x86/intel" ist *sehr* unpräzise
11:42:59 IceMichael: ich nutz halt das standardding von win10 msvc2019 64 bit
11:43:08 IceMichael: hab da sonst nichts speziell eingestellt :D
11:43:10 xq: hm
11:43:35 IceMichael: also in meiner win10 vm läuft es halt auch
11:43:48 IceMichael: bei ihm ist der gemeinsame Teiler halt echt CPU und RAM
11:44:14 IceMichael: i3-3217U
11:45:14 IceMichael: er hat sogar neuen RAM gekauft :D aber den alten drin gelassen na ja... und nutzt irgendwie kein RAM-Check-tool bis auf win healthcheck.. hab ihm welche verlinkt, aber wollter nicht na ja
11:46:41 xq: naja, meine frage ist: für welche CPU cross-compilst du?
11:46:48 xq: hat sein system alle benötigten CPU-Features?
11:46:54 IceMichael: ich cross-compile eigentlich nicht, ich compile in meiner win10 vm
11:46:58 xq: ja well
11:47:04 xq: grade, weil du sowas wie CLZ nutzt
11:47:21 IceMichael: ja, ich weiß aber nicht, wo er das herzieht
11:47:34 IceMichael: aber ich hab sogar nen UT als exe genau für die Funktionen davon, das könnt ich mal bei ihm laufen lassen eigentlich
11:47:43 xq: UT?
11:47:51 xq: https://github.com/ziglang/zig/blob/master/lib/std/target/x86.zig#L7-L148
11:48:04 xq: das hier sind so die config/tweaking-flags, die du bei x86 so hast *grin*
11:49:37 xq: du hast halt grade eine dir unbekannte kombination der flags an :D
11:51:19 xq: für den i3 sind folgende features verfügbar: https://github.com/ziglang/zig/blob/master/lib/std/target/x86.zig#L2062-L2090
11:53:02 xq: und wenn ich das recht sehe, hat der ivy bridge keine clzero extension
11:54:25 IceMichael: unit test
11:54:41 IceMichael: hmm
11:54:45 IceMichael: aber er beklagt sich ja auch nicht
11:54:54 IceMichael: ok, das wäre halt unglaublich hart dumm, wenn es daran liegt
11:55:18 IceMichael: ich dachte, das sei so ein superbase feature. Schrompf meinte ja auch, dass so ein paar einfache Befehle eigentlich jede CPU kann
11:55:25 IceMichael: aber würds erklären natürlich
11:55:49 xq:
11:55:51 xq: wie meinen?
11:55:58 xq: es crashed halt direkt beim ausführen der instruction
11:58:56 joeydee joined the channel
11:58:59 joeydee: moin
12:09:22 IceMichael: moin joeydee
12:09:32 IceMichael: xq, also es crasht hier nicht, aber mein unit test hab ich bei ihm mal gestartet
12:09:35 IceMichael: und das failed alles
12:10:51 IceMichael: also nice :)
12:10:58 IceMichael: aber na ja, er crasht nicht beim Aufruf, er liefert irgendein andres Ergebnis
12:11:14 IceMichael: heisst aber, die clzll calls muss ich alle rauswerfen und durch irgendwas weniger performantes ersetzeen
12:12:59 IceMichael: danke xq, das war echt wieder mal ein mega Hinweis
12:15:33 IceMichael: na ja, also alle diese clz-Teile ersetzen
13:07:32 xq: das ist der falsche schluss
13:07:39 xq: du löst grade nur ein symptom, aber nicht die ursache
13:07:48 xq: die ursache ist: dein compiler compiliert für eine zu moderne CPU
13:07:56 xq: __builtin_clz() bleibt dir erhalten für jegliche CPU
13:08:03 xq: aber du musst halt für die passende CPU compilieren ;)
13:08:13 xq: ansonsten wird dir sowas immer und immer wieder passieren
14:02:44 IceMichael: xq, verstehe ich nicht. Also ich muss ein target angeben, das alt genug ist, sodass neuere und ältere gleichermaßen damit klarkommen?
14:02:52 IceMichael: oder soll ich 10 compiles anbieten?
14:10:40 IceMichael: hm, im Endeffekt ist es jetzt für msvc doch __lzcnt64, was ich nutze
14:26:13 IceMichael: da haben diverse Leute schon berichtet, dass je nach Compiler etc. andre Ergebnisse rauskommen, was ein Mist
14:26:36 IceMichael: man darf nix passen, was dem compiler sagt, dass es CPU-seitig existiert, tue ich aber auch nicht. Ansonsten kann man noch ein define setzen, probiere ich mal
14:48:41 IceMichael: BitScanReverse scheint gut zu sein
15:12:59 xq: du kannst entweder diverse kompilate anbieten
15:13:14 xq: oder du machst diverse object files, welche die funktionalität für diverse CPUs compiliert benutzen
15:13:22 xq: und switched dann zu laufzeit auf basis der CPU info
15:32:10 IceMichael: klingt zu aufwendig für mich
15:32:16 IceMichael: ich hab jetzt für win einfach BitScanReverse genutzt
15:32:36 xq: inwiefern für "win"?
15:33:01 IceMichael: falls der code für win compiled wird
15:33:08 xq: das macht doch überhaupt keinen sinn
15:33:09 IceMichael: ich compile ja für windows und macos
15:33:15 xq: das hat mit windows und MacOS überhaupt nix zu tun
15:33:17 xq: du musst halt mit deinen instructions den spagat zwischen "schnell genug" und "supported auch alte hardware" hinbekommen
15:33:29 IceMichael: doch hat es
15:33:36 IceMichael: BitScanReverse ist portabler, steht in der Dokumentation
15:33:51 xq: ja und? dein mac-code bleibt dann aber unportabel
15:34:36 IceMichael: ne, der nutzt kein lzcnt, weil er direkt __builtin_clz nutzen kann, was aber unter win, oder zumindest mit msvc nicht existiert
15:34:56 xq: erm
15:35:08 xq: du weißt schon, dass die CPUs die selben sind?
15:35:55 IceMichael: hat apple so viele i3 im Einsatz? hm
15:36:30 xq: naja
15:36:38 IceMichael: die Frage ist ja, ob __builtin_clz für unsupportete CPUs automatisch ne Softwarefunktion nutzt auch. Oder kann man das ausschliessen?
15:36:41 xq: du kannst jetzt natürlich dein problem für *einen* von beliebig vielen fällen fixen
15:36:46 xq: oder du machst nen root cause fix
15:36:53 xq: aber du scheinst grade nur an nem workaround interessiert zu sein
15:38:10 IceMichael: also für win ist das gefixt, für macos klappt es jetzt halt nicht für alle CPUs
15:38:23 IceMichael: bei macos ist eh immer neuerer Kram nötig
15:38:27 xq: es ist für win nicht gefixed
15:38:33 xq: dieser crash ist gefixed
15:38:35 xq: aber nicht der grund
15:38:39 xq: sondern ein symptom davon
15:39:25 IceMichael: hö?
15:39:30 xq: na
15:39:35 xq: dein compiler compiliert für $CPU
15:39:46 xq: du hast aber wohl vor, auch ältere CPUs zu supporten
15:39:56 xq: du weißt aber nicht, wie, wo und wann es wieder crashen wird
15:40:13 xq: weil du nicht weißt, für welche CPU dein compiliert das programm überhaupt baut
15:40:18 xq: oder was deine mindestanforderungen sind
15:41:04 IceMichael: ich nutze sonst ja keine Intrinsics und BSR ist laut stackoverflow für quasi alle x86 CPUs unterstützt
15:41:11 xq: das ist komplett egal
15:41:15 IceMichael: überhaupt nicht
15:41:20 IceMichael: ich nutze sonst keine Intrinsics
15:41:22 xq: das hat mit intrinsics überhaupt nix zu tun
15:41:32 xq: sondern damit, was dein compiler für code emitted
15:41:36 xq: und was er zulässt
15:41:45 xq: und was er an instructions in seinem pool hat, die zulässig sind
15:42:08 IceMichael: was wär denn dein konkreter Vorschlag?
15:42:31 xq: na, die korrekte CPU an den Compiler mitgeben, die deine mindestanforderungen sind
15:42:45 IceMichael: hm, wie gibt man bei C++ an den Compiler ne CPU?
15:42:55 xq: -mcpu, -march
15:43:09 xq: bei zig sind wir mit der wahl von x86_64-v2 auf die schnautze gefallen
15:43:50 xq: guck mal auch hier für die features: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
15:43:55 xq: welche compiler setzt du ein?
15:44:13 xq: LZCNT ist von x86_64-v3 btw
15:44:26 IceMichael: bei windows ist es halt einfach das msvc2019 ding
15:44:36 IceMichael: da gibt's sonst nicht viel Auswahl, oder?
15:44:49 IceMichael: x86_64 ist die Plattform, ich biete gar kein 32-Bit mehr an, aber wsl wieder die falsche Antwort :D
15:45:07 IceMichael: v2, v3 ist nice zu wissen, danke
15:45:12 xq: klar, für windows gibts genug compiler
15:45:19 IceMichael: ich weiß
15:45:30 xq: dann versteh ich deine frage nicht
15:45:31 IceMichael: aber ich mein, wenn ich msvc2019 installiere und einfach loslege, dann ist es einfach der MS Compiler
15:45:37 xq: erm
15:45:38 xq: ja
15:45:46 xq: so n bisschen
15:45:50 xq: der hat genug compilerschalter
15:46:01 IceMichael: ja, aber du hast ja gefragt, welche compiler ich nutze
15:46:09 xq: aber da weiß ich nicht, wie man das einstellt
15:46:09 IceMichael: also v1 sollte mir eigentlich reichen, schätz ich
15:46:23 xq: BSR haste dann auch nicht mehr
15:46:34 xq: afaik
15:46:38 xq: bzw. es gibt ne anmerkung dazu
15:46:58 IceMichael: ich seh nur mit Parameter 0, was mich nicht interessiert
15:46:59 xq: siehe direkt das kapitel nach dem verlinkten
15:47:46 IceMichael: ich seh da nur einen Absaty, wozu ich BSR/BSF finde (in der Tabelle oben steht's gar nicht) und das sollte bei mir egal sein
15:48:00 xq: ja
15:48:03 xq: dann sollte das hinhauen
15:49:39 IceMichael: ist halt jetzt die Frage, was der default bei msvc ist
15:49:49 IceMichael: zurzeit sehe ich in den Commpilerflags kein arch, aber wer weiß, ob das woanders steht
15:51:00 IceMichael: also googlebar ist so was wie "x86-64-v2" iVm VS jedenfalls nicht wirklich
15:51:06 IceMichael: da scheint VS ne andre Sprache zu sprechen
15:51:22 xq: jop
15:51:26 IceMichael: "n 2020, through a cross-vendor collaboration, a few microarchitecture levels were defined"
15:51:36 IceMichael: na super, damit ist es doch völlig unbrauchbar :D als ob MS da mitzieht
15:51:45 IceMichael: und wenn, dann dauert es, bis es in VS echt mal drin ist
15:51:52 xq: das heißt nicht, dass du das nicht nutzen kannst ;)
15:52:00 xq: nur, dass du nicht direkt sagen kannst "mach mal dies"
15:52:13 IceMichael: genau, die Frage stellt sich wohl nach den aktivierten CPU Features, oder?
15:52:18 IceMichael: die sind ja common language
15:53:12 IceMichael: ok, das ist auch, was /arch erwartet
15:53:26 xq: naja,, auch nur ein bisschen common language :D
15:54:57 IceMichael: BSR/BSF gehören zu 80386 :D
15:55:10 IceMichael: ich kann wohl wirklich davon ausgehen, das ist überall drin
15:55:32 xq: j
15:55:34 xq: stimmt
15:55:48 IceMichael: aber gut, du meinst, das Problem ist, ohne /arch geht er davon aus, dass zB SSE4.2 geht und dann installiert das ein Kunde und BOOM
15:56:02 IceMichael: weil der optimizer das dann nutzt (als ob er das täte)
15:56:09 IceMichael: das wäre in der Tat Mist
15:56:22 xq: jo, ich hab das lieber explizi
15:57:13 IceMichael: ja, verstehe ich
15:57:22 IceMichael: ok, also LZCNT gehört zu AVX2 und damit zu v3
15:57:38 IceMichael: na ja, bin hier definitiv jetzt einfach naiv
15:57:51 IceMichael: ich schätze, für macos sollte ich halt auch auf BSR/BSF gehen, dann wäre ich bzgl dessen safe
15:59:40 IceMichael: hm, viel kann arch wohl aber auch nicht, einfach AVX-Kram: https://docs.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-160
15:59:44 IceMichael: default nutzt wohl SSE2 immerhin
16:00:53 IceMichael: ich glaube dennoch... es ist unwahrscheinlich, dass msvc krasse Sachen reinpackt, die dann auf alten Maschinen nicht gehen/crashen, damit wäre jeder, der nicht drauf achtet, ja direkt zum Tode verurteilt
16:01:24 IceMichael: also das reelle Problem ist wohl ziemlich klein. Aber dennoch danke für das Update, werde ich in Zukunft drauf achten