ping seddd

<[keybase] unseddd>: pong sarang

<[keybase] unseddd>: err... talking to me?

Yes!

I was testing your fuzz PR for CLSAG seddd, and having trouble compiling

How did you go about it?

<[keybase] unseddd>: pretty sure I just compiled the normal afl way. maybe you need to set the env vars: CC=afl-gcc CXX=afl-g++

<[keybase] unseddd>: ^ may need to set during cmake step too

<[keybase] unseddd>: so something like: export CC=afl-gcc CXX=afl-g++; cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_TEST=ON && make

<[keybase] unseddd>: s/BUILD_TEST/BUILD_TESTS/

<[keybase] unseddd>: side-question: is any work being done on reducing the size of translation units in monero? (compiling currently takes over 6GB of RAM at peak)

Someone's looking at thinning boost includes, which take a lot of the TU bulk.

<[keybase] unseddd>: awesome! thanks moneromooo

<[keybase] unseddd>: boost is beastly, do not envy their work

boost is just so fucking misguided. "zero-installation libs!"

because they do literally everything in their header files

boost, C++, whatever. it's all fucking stupid.

header files are for interfaces, not implementations. period.

<[keybase] unseddd>: header-only definitely seems to be a strong trend in the C++ world

<[keybase] unseddd>: makes working with templates much simpler (but if you hate C++, imagine you hate templates too :)

yes. because every developer has a supercomputer at their disposal for compiling, and edit/compile/test cycles are free

and yes to your guess.

<[keybase] unseddd>: lol right. trying to get better at C, but do most of my coding in rust these days. compile times there are improving nicely

for several months it was impossible to do a native win32 compile of the Monero source tree, with debugging enabled

needed more than 3GB of RAM for the compiler

and produced more than 65536 symbol sections in the object file

oh wait - the object file problem was there regardless of native or cross-compile

and it was 32768 sections

because every stupid header file needed its own symbol section

<[keybase] unseddd>: do you think things will improve there with C++ modules?

I would expect so, I mean, isolating into modules ought to relieve a lot of the burdens

but I haven't really looked into it that much. who supports that already?

reminds me now why modula-2 was such a popular language in my Atari ST days

<[keybase] unseddd>: think it is planned for C++20, so only the latest compilers (looks like Clang11 and maybe VS Code)

<[keybase] unseddd>: GCC is working on them: gcc.gnu.org/wiki/cxx-modules

<[keybase] unseddd>: once modules have been supported a while, my guess would be header-only trend dies

will take a while for it to be usable in those compilers

<[keybase] unseddd>: definitely, maybe 2025 :p

<[keybase] unseddd>: jk, compiler work is hard though

lol

I was a gcc maintainer from 1989-1997 or so

something like that. m68k, MIPS, i860, sparc

fun times

<[keybase] unseddd>: oh awesome! look who i am talking to like i actually know shit, lol

5 years back then, heck, i860 would have been off the market before its support stabilized

<[keybase] unseddd>: what do you think of RISC-V ISA?

tbf, I never touched any of that frontend stuff. I worked on the machine-dependent stuff, going from the IR to asm.

I think RISC-V is a disorganized shitshow

too many optional instruction sets

it reflects timid design-by-committee, making it impossible for programmers to rely on any particular features to exist

<[keybase] unseddd>: lol. usually hear the modular design as a plus, you think it's borked?

yes. just like AVX512 is a pointless feature today, because so few x86 chips support it

go big or go home, all or nothing. 100% support, or better programmers will avoid it.

optional instruction sets suck. same situation in ARM with their crypto instruction set

Broadcom is a huge ARM licensee, makes all of the raspberry Pi CPUs, doesn't include crypto instructions

makes their entire product line a waste, for us

and really, a waste for everyone who wants to use a Pi on the WWW.

<[keybase] unseddd>: yeah, think that was the motivation for their "core ISA", with module ISAs being for stuff like crypto accelerators

<[keybase] unseddd>: could see the most used modules being incorporated into the main ISA (but that implies use)

Motorola did it right in m68k. unsupported instructions could trap and still be emulated in s/w without too bad a perf penalty

<[keybase] unseddd>: yeah, absolutely hate that broadcom chips are little black boxes inside so much hardware

yeah

anyway - if you can't rely on a particular instruction working on every CPU that runs your code, you generally end up not using it anywhere.

just saves headaches, as a programmer

<[keybase] unseddd>: not sure how risc-v handles unsupported instructions

<[keybase] unseddd>: true, just so hyped over such a big open-hardware project. even if it flops, it is influencing a lot of other projects

yeah, good point. maybe that's all it needs to do

That really only matters if you want to write your own asm code, though, right ? Otherwise, your compiler knows what insns to emit.