IRC channel logs
2024-10-28.log
back to list of logs
<lanodan>Reminds me of wondering how mescc can be so painfully slow <Googulator>Probably comparable to running AI models on the CPU <Googulator>I wonder how fast mescc would be on an AMD MI300A... <Googulator>5.3TB/s memory bandwidth available to the CPU cores <notgull>Imagine if we needed to use a GPU to run MesCC <stikonas>well, on x86_64 mescc is not super slow, probably 10 minutes to rebuild itself and another 10 minutes to build tcc <stikonas>on my riscv64 board (visionfive2), it is painfully slow <stikonas>perhaps as slow as a week to build to tcc <stikonas> at least with the current build script which I admit might not be efficient <stikonas>we should probably create unified-libc.c when building meslibc <stikonas>I think visionfive2 is very memory bandwidth limited though <stikonas>later, once it reaches tcc and gcc, things work reasonably fast <stikonas>at least as fast as you can expect from riscv64 <nore>(the first ~120 bytes of the file are the closest to binary, but they are pure printable ASCII characters and extensively documented, used to bootstrap the rest of the file) <stikonas>so does it run in some kind of emulator? <stikonas>since I guess there is no real subleq hardware <nore>yes, there's an emulator in the repo <nore>the file populates the initial memory (one character = one memory location), the execution starts at location 0 <nore>real subleq hardware would be nice and not too difficult to build I'd hope, since it would use only a few gates besides the memory <nore>yep, so no instruction decoding to do at all <stikonas>maybe evne not too hard to build out of discrete components... <nore>that's what I would hope, yes!