egg|nomz|egg changed the topic of #kspacademia to: https://gist.github.com/pdn4kd/164b9b85435d87afbec0c3a7e69d3e6d | Dogs are cats. Spiders are cat interferometers. | Космизм сегодня! | Document well, for tomorrow you may get mauled by a ネコバス. | <UmbralRaptor> egg|nomz|egg: generally if your eyes are dewing over, that's not the weather. | <ferram4> I shall beat my problems to death with an engineer.
awang has quit [Ping timeout: 182 seconds]
awang has joined #kspacademia
<UmbralRaptor>
Bleah, tired and hungry.
<UmbralRaptor>
;choose "Increase local entropy by getting food" "increase local entropy by doing laundry" "increase local entropy by solving stat mech homework problems"
<UmbralRaptor>
!choose "Increase local entropy by getting food" "increase local entropy by doing laundry" "increase local entropy by solving stat mech homework problems"
<Qboid>
UmbralRaptor: Your options are: "Increase local entropy by getting food" "increase local entropy by doing laundry" "increase local entropy by solving stat mech homework problems". My choice: "Increase local entropy by getting food" "increase local entropy by doing laundry" "increase local entropy by solving stat mech homework problems"
<UmbralRaptor>
doh, wrong syntax
<UmbralRaptor>
!choose Increase local entropy by getting food|ncrease local entropy by doing laundry|increase local entropy by solving stat mech homework problems
<Qboid>
UmbralRaptor: Your options are: Increase local entropy by getting food, ncrease local entropy by doing laundry, increase local entropy by solving stat mech homework problems. My choice: Increase local entropy by getting food
<icefire>
wonder why kmath ignored that command
<icefire>
guess I could check the logs... or I could not and continue to be lazy
<awang>
!wpn -add:wpn ruby-throated
<Qboid>
awang: Weapon added!
<awang>
!wpn -remove:wpn ruby-throated
<Qboid>
awang: Weapon removed!
<awang>
!wpn -add:adj ruby-throated
<Qboid>
awang: Adjective added!
<awang>
!wpn -add:wpn hummingbird
<Qboid>
awang: Weapon already added!
<UmbralRaptor>
;choose Increase local entropy by getting food|increase local entropy by doing laundry|increase local entropy by solving stat mech homework problems
<kmath>
UmbralRaptor: Increase local entropy by getting food
<UmbralRaptor>
Apparently the quotes matter?
<awang>
Quotes?
<icefire>
its because there wasnt any delimiters
<icefire>
kmath ignores <= 1 options in a choose
<UmbralRaptor>
ah
<bofh>
!acr -add:MISSISIPI Multiple Intense Solvent Suppression Intended for Sensitive Spectroscopic Investigation of Protonated Proteins Instantly
<Qboid>
bofh: I added the explanation for this acronym.
<kmath>
<HubbleTelescope> Good news! The subject of our iconic photo lives on. https://t.co/6ocONHZjzw
<UmbralRaptor>
bofh: o_O
<bofh>
UmbralRaptor: hilariously, "cheap date" encodes (iirc) a potassium channel that when mutated makes flies more susceptible to the effects of ethanol, particularly on postural control.
<UmbralRaptor>
pfft
e_14159 has quit [Ping timeout: 207 seconds]
e_14159 has joined #kspacademia
technicalfool_ has joined #kspacademia
technicalfool has quit [Ping timeout: 383 seconds]
awang has quit [Read error: Connection reset by peer]
awang has joined #kspacademia
icefire has quit [Read error: Connection reset by peer]
Orkeren has quit [Read error: Connection reset by peer]
Orkeren has joined #kspacademia
<UmbralRaptor>
bofh: cats!
<bofh>
UmbralRaptor: ?
<egg|zzz|egg>
!wpn whitequark
* Qboid
gives whitequark a first/follow stellated octagon
<egg|zzz|egg>
!wpn bofh
* Qboid
gives bofh a weak pagan SPANG
<egg|zzz|egg>
!wpn UmbralRaptor
* Qboid
gives UmbralRaptor a 2N3904
<egg|zzz|egg>
whitequark: uh oh what did conda do again
<whitequark>
the usual
StCypher has quit [Ping timeout: 186 seconds]
egg|cell|egg has joined #kspacademia
egg|phone|egg has quit [Ping timeout: 383 seconds]
egg|phone|egg has joined #kspacademia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #kspacademia
egg|phone|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|phone|egg has joined #kspacademia
tawny has quit [Ping timeout: 186 seconds]
egg|cell|egg has joined #kspacademia
egg|phone|egg has quit [Read error: Connection reset by peer]
awang has quit [Ping timeout: 207 seconds]
egg|cell|egg has quit [Ping timeout: 182 seconds]
egg|phone|egg has joined #kspacademia
tawny has joined #kspacademia
egg|cell|egg has joined #kspacademia
egg|phone|egg has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
egg|phone|egg has joined #kspacademia
egg|cell|egg has quit [Read error: Connection reset by peer]
<kmath>
<LokiVolcano> Simon: Total cost would be approximately the cost of Mars Science Laboratory. And yet, you get both ice giants, on… https://t.co/KcM5OCXseA
<Qboid>
[#19883] title: Critical Linux filesystem permissions are being changed by latest version | #### I'm opening this issue because:... | https://github.com/npm/npm/issues/19883
<UmbralRaptor>
o_O
egg|cell|egg has joined #kspacademia
egg|phone|egg has quit [Read error: Connection reset by peer]
tawny has joined #kspacademia
tawny has quit [Ping timeout: 383 seconds]
tawny has joined #kspacademia
tawny has quit [Ping timeout: 198 seconds]
icefire has joined #kspacademia
StCypher has joined #kspacademia
tawny has joined #kspacademia
* awang
🔪 linkers that can't find symbols in .static libs
<awang>
Clang says it can't find the symbol
<awang>
Go to the .a file, llvm-nm says it's defined right there
<awang>
idk what I'm supposed to do now
<awang>
Never mind, apparently Clang doesn't support LTO for static libraries
<iximeow>
.. why not?
<iximeow>
i clearly don't understand LTO well enough
* UmbralRaptor
🔥 thermodynamics
<whitequark>
pretty sure it does
<whitequark>
when you build with -flto, clang places bitcode into .o files instead of machine code
<whitequark>
then you make an .a as usual, except that you use llvm-ar
<bofh>
UmbralRaptor: ?
<iximeow>
whitequark: ha, i'd assumed LTO was some link-time lining/dead function elimination kind of thing. that makes more sense
<whitequark>
iximeow: you're not wrong
<whitequark>
what happens afterwards is that ld loads a linker plugin, which is basically the llvm middle-end and backend, merges all the modules, and optimizes them as if they were a single compilation unit
<whitequark>
inlining and DCE are parts of that
<iximeow>
gotcha. seems a lot more reasonable on bitcode than whatever target arch directly, too
<whitequark>
not more reasonable but the only possible way
<whitequark>
you can't really optimize machine code directly, there are too many invariants that aren't present in the source language
<whitequark>
nb: bitcode is not arch-independent, #ifdef's exist, `int` exists
<kmath>
<diodebot> superconducting glaive-glaive-glaive-guisarme-glaive-saturated atlatl-emitting digital diode (SGGGGGSAEDD)
<iximeow>
hm.. i'd be surprised if you couldn't craft bitcode that LLVM would break with LTO
<whitequark>
what do you mean?
<iximeow>
you'd do LTO on bitcode because it's *easier* to verify some operation won't produce a broken program, yeah? you *could* do that on x86, say, directly, though it would be difficult and even more brittle
<whitequark>
nope
<whitequark>
the bitcode has a very large set of things that are undefined behavior, and the frontend is tasked with ensuring these things never happen
<whitequark>
(or occasionally the user, such as when compiling C)
<whitequark>
the optimizer is then free to assume that none of the undefined behavior happens, so if it does in fact happen, the optimizer is not at fault
<whitequark>
with x86 though there is no undefined behavior for the most part, there's just... behavior
<whitequark>
and there are *extremely* few equivalent transformations of x86 code you can do
<soundnfury>
whitequark: yes but anything you can do with bitcode, you could _in principle_ do with asm, it just might be hideously computationally expensive (you might have to detect the presence of invariants by analysing the whole program, rather than being told about them)
<whitequark>
soundnfury: nope?
<whitequark>
for example: bitcode has an `add nsw` instruction, for `no signed wrap`
<whitequark>
this produces undefined behavior if it ever dynamically wraps around
<whitequark>
this means that even if you have something like `int l = atoi(argv[1]); for(int i = 0; i < l; i++) ...` (i++ produces an `add nsw` instruction) the optimizer is free to assume no signed wrap
<whitequark>
once you lower this to x86 code you lose this knowledge
<whitequark>
another example: the assume intrinsic (__builtin_assume in gcc/clang)
tawny has quit [Remote host closed the connection]
<iximeow>
some optimizations become impossible, yes
<iximeow>
dead code/inlining as particular examples are still possible
<whitequark>
dead code elimination doesn't need lto
<whitequark>
-ffunction-sections/-fdata-sections
tawny has joined #kspacademia
<whitequark>
inlining is not legal
<whitequark>
it's legal to change the machine code of a function dynamically by mapping it rwx and rewriting
<whitequark>
therefore, you can not inline
<whitequark>
well, if you aim to run LTO on general x86 code and not just x86 code produced by a C compiler
<iximeow>
right, i was going to say you'd have to show self-modification is not able to happen in the region under consideration
<iximeow>
you can mprotect() a function in C just the same, though i dunno if that becomes undefined behavior by the spec?
<whitequark>
it is
<iximeow>
rad
<whitequark>
i mean
<whitequark>
why do you think the compiler can inline functions? :D
<whitequark>
because rewriting them is UB
<whitequark>
most optimizations in C and most of its UB are two sides of the same coin
<iximeow>
yeah honestly i'd never thought about trying to modify an inlined functions
<soundnfury>
whitequark: but if you do whole-program analysis and determine that the program obeys the invariant, you don't need an annotation (like 'nsw') telling you you may assume it
<whitequark>
soundnfury: please read what i wrote again
<soundnfury>
whitequark: please read what I wrote at all
icefire has quit [Ping timeout: 207 seconds]
<whitequark>
I did.
<whitequark>
whole-program analysis doesn't let you recover invariants that aren't in the program.
<soundnfury>
to prove an optimisation is safe, you can either (a) be told you can assume things (there will be no signed wrap of this add, etc.) or (b) determine those things are true
<soundnfury>
now, in the latter case you may sometimes run up against Entscheidungsprobleme and so on,
icefire has joined #kspacademia
<soundnfury>
but in principle if you have access to hypercomputation it's doable ;)
<whitequark>
no it's not
<soundnfury>
and if the invariant is not in fact true of the program... then it was UB to begin with, so nasal demons are correct.
<soundnfury>
(and so is deciding not to perform the optimisation because you didn't discover the invariant it requires)
<whitequark>
if you lower this to a call to `atoi` then you can never go to the `main: retq $0` which is the correct optimized version
<iximeow>
that's fine. no one claimed that all optimizations continue to be applicable to the same degree on native code
<soundnfury>
... well, since argv comes from outside the program, the above program is UB since the assumption might not hold
<whitequark>
"the above program is UB" is a meaningless phrase
<soundnfury>
whereas if this function, rather than being main(), were some random function and the calling code were available for analysis, then if the assumption is always true then it can in theory be discovered to be so by the optimiser
<whitequark>
you might have wanted to say "the above program always dynamically invokes UB" instead, but that's clearly not true, because it doesn't if it's called with `0` as an argument
<soundnfury>
ok, I'll rephrase it. "the above program dynamically invokes UB for a non-empty subset of its input space"
<whitequark>
sure
<whitequark>
so?
<soundnfury>
(and is therefore not conforming or not strictly conforming or something like that, I forget the definitions)
<soundnfury>
So real, non-broken assumptions (rather than your synthetic and broken __builtin_assume()) that come from things like C's rules, const and restrict qualifiers, etc.,
<soundnfury>
can be recovered if they are correct
<soundnfury>
and if they aren't correct, then they won't be recovered... but optimisations based on them will cause the program to fail because they weren't correct and the optimiser is giving you nasal demons
* awang
just wasted an hour and a half debugging something that could have been fixed if the console output was read
<whitequark>
soundnfury: okay, what you're saying is true if you have hypercomputation
<whitequark>
but that's cheating.
<awang>
iximeow: Not really sure why. Apparently Clang says "hey, I found all these things you aren't using" and removes everything from the archive
<whitequark>
if we had hypercomputation we wouldn't need optimizers in the first place.
icefire has quit [Ping timeout: 186 seconds]
<awang>
So then the linker tries to link the executable and complains it can't find things
<UmbralRaptor>
"Not that it matters, but lets be pedantic."
<awang>
First clue was the warnings that non-header-only libraries were getting "no symbols" errors
<iximeow>
if you accept that some valid optimizations are missed, you don't need hypercomputation, you just need a paranoid linker
<whitequark>
iximeow: ... my point was precisely that working on x86 instead of ir would result in missed optimizations
<iximeow>
ah, i'd taken you to indicate that it was simply *not possible* on x86
<awang>
Does clang support -ffunction-sections/-fdata-sections?
<whitequark>
have you looked at the amount of interdependencies between x86 instructions?
<whitequark>
flags in particular are a nightmare
<iximeow>
whitequark: yes.
<awang>
I've only ever seen those mentioned when building for Pi-ish things or kernels
<iximeow>
i think i've mentioned to you that my day job is writing RE tools
<whitequark>
like, this came up while i was working on binary ninja
<whitequark>
you didn't
<iximeow>
oh
<iximeow>
yeah
<whitequark>
well then I needn't say anything further
<whitequark>
awang: yes
<whitequark>
of course it does
<iximeow>
(fun fact: some obfuscating "protectors" insert junk instructions and/or compute specific eflags values, which are then `pushfd; pop eax`'d and used for math)
<awang>
UmbralRaptor: Compiler writeres in a nutshell :P
<awang>
(kidding, of course; I want to be one eventually)
<iximeow>
rather, junk instructions that can only be determined junk if you follow the computed flags :(
<soundnfury>
whitequark: yeah I was never claiming it was a *good idea*
<awang>
iximeow: That sounds like a fun job
<awang>
It probably will end up being user error on my end
<awang>
Told CMake to pass "-flto=thin" to everything
<iximeow>
awang: i've grown the power/party trick to disassemble x86 in my head. it's fun, if that sounds fun. :D
<awang>
I didn't think Clang would try to optimize .a files though
<awang>
If that is what is actually happening
<awang>
iximeow: Yes, that sounds fun
<awang>
At least as of now
<awang>
Bet I wouldn't say the same if I were working with x86 much more
<awang>
I hear it's fun
<whitequark>
awang: what exactly does clang output
<whitequark>
also, LTO and ThinLTO are not the same thing
<awang>
whitequark: Let me check. I deleted the build folder, so will need to reproduce
<awang>
And yeah, I know LTO and ThinLTO aren't the same
<awang>
I've just defaulted to ThinLTO because it's free performance without significantly affecting build times
<awang>
Or at least free performance once I finish rooting out all the UB
<soundnfury>
^ proving that there ain't no such thing as a free performance.
<iximeow>
free nasal demons!
<awang>
whitequark: "arning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: libgeometry.a the table of contents is empty (no object file members in the library define global symbols)"
<awang>
Er
<awang>
s/ "/ "w/
<Qboid>
awang meant to say: whitequark: "warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: libgeometry.a the table of contents is empty (no object file members in the library define global symbols)"
<whitequark>
that sounds like you should be running llvm-ranlib on the archive instead
<whitequark>
who runs that command
<awang>
CMake, I think?
<awang>
I think it just runs whatever ranlib happens to be in the PATH
<awang>
Interesting point though
<awang>
Let me symlink the two together...
<whitequark>
yeah, you need to specify llvm-ranlib explicitly
<whitequark>
um
<whitequark>
noooo
<awang>
Nope
<whitequark>
-DCMAKE_RANLIB=llvm-ranlib
<whitequark>
-DCMAKE_AR=llvm-ar
<awang>
ranlib: Unknown command line argument '-q'
<awang>
Ah, replace ar too
<iximeow>
... llvm-ar? are llvm .a not ar archives?
<whitequark>
iximeow: they are
<whitequark>
but ar is a superset of ranlib
<whitequark>
ever wondered why is there $TARGET-ar built by binutils? that's why
<whitequark>
specifically, the s option
<iximeow>
oof
<bofh>
Eugh.
<awang>
Wonder how many things I'll break if I replace Xcode's toolchain binaries with normal Clang's
<whitequark>
don't.
<whitequark>
that will break the toolchain.
<whitequark>
instead, use the cmake options I gave you above.
<awang>
I am
<whitequark>
(or better, write a toolchain file)
<awang>
I was just curious as to what would happen
<awang>
I think homebrew comes with the option to install one
<awang>
It didn't work last time I tried, which was quite a while ago
<awang>
whitequark: Yep, that did the trick!
<awang>
Thank you!
<whitequark>
you might still have trouble with the linker
<whitequark>
but I'm not sure
<whitequark>
if you do, tell me
<awang>
Nope, compiled/ran successfully
<awang>
Or at least the test suite did
<whitequark>
sssweet
<awang>
~40 seconds shaved off of 3-4 minute runtime
<iximeow>
oo nice
<awang>
And the code is still horrendously inefficient
<iximeow>
someone cross compile all this c# to rust for me so i can stop thinking about mono's insane jit
<awang>
iximeow: Insanely good, I hope? :P
<iximeow>
my favorite mono jit experience was finding that the length of a byte[] in a very tight loop was loaded at the end of every iteration, to compare an index against
<iximeow>
arrays in c# being non-resizable... that was unpleasant
<iximeow>
they have an alternate llvm backed that can be used for jit but it appears unsupported and broken in master
<iximeow>
some tweaks get it running but its performance is similar to their hand-rolled jit, not sure why
<iximeow>
:(
<whitequark>
garbage collection
<whitequark>
llvm doesn't support precise gc
<iximeow>
oh hum, that makes sense
<iximeow>
either way, it's funny getting better performance in a windows vm on the MS .net runtime than on the host running mono
* awang
🔪 Microsoft OneDrive Setup
egg|cell|egg has quit [Ping timeout: 207 seconds]
<awang>
I like how VS on a VM manages to run in about 3/4 the time as Clang on the host machine
<awang>
Is VS really that much better than Clang at optimization?
<whitequark>
purely computational workloads with hardware virtualization enabled don't really get much of a penalty
<whitequark>
speaking of VS, there's no direct comparison
icefire has joined #kspacademia
<awang>
Oh
<awang>
interesting
<whitequark>
iirc, VS is better at their equivalent of ThinLTO but Clang generates faster code
<awang>
I'd still love to know what's causing the performance discrepency though
<whitequark>
or something like that
<awang>
Hmmm
<whitequark>
could be anything.
<awang>
Wonder if I can convince my boss to let me spend a week or two staring at the disassembly
<SnoopJeDi>
"could be anything" is an alarmingly good summary of compilers
<iximeow>
with a sufficiently smart compiler,
<awang>
!wpn -add:adj sufficiently smart
<Qboid>
awang: Adjective added!
<iximeow>
!wpn awang
* Qboid
gives awang a diabolic jellyfish
<awang>
!wpn -add:wpn compiler
<Qboid>
awang: Weapon already added!
<awang>
Wonder how long it's going to take for the sufficiently smart compiler to emerge