| ▲ | netr0ute 6 days ago |
| Hi everyone, I'm the author of this article. Feel free to ask me any questions to break the radio silence! |
|
| ▲ | benreesman 6 days ago | parent | next [-] |
| Nice work and good writeup. I think most of that is very sound practice. The codegen switch with the offsets is in everything, first time I saw it was in the Rhino JS bytecode compiler in maybe 2006, written it a dozen times since. Still clever you worked it out from first principles. There are some modern C++ libraries that do frightening things with SIMD that might give your bytestring stuff a lift on modern stupid-wide high mispredict penalty stuff. Anything by lemire, stringzilla, take a look at zpp_bits for inspiration about theoretical minimum data structure pack/unpack. But I think you got damn close to what can be done, niiicccee work. |
| |
| ▲ | Sesse__ 6 days ago | parent [-] | | FWIW, this is basically an implementation of perfect hashing, and there's a myriad of different strategies. Sometimes “switch on length + well-chosen characters” are good, sometimes you can do better (e.g. just looking up in a table instead of a long if chain). The “value speculation” thing looks completely weird to me, especially with the “volatile” that doesn't do anything at all (volatile is generally a pointer qualifier in C++). If it works, I'm not really convinced it works for the reason the author thinks it works (especially since it refers to an article talking about a CPU from the relative stone age). |
|
|
| ▲ | inetknght 6 days ago | parent | prev | next [-] |
| Overall, this is a fantastic dive into some of RISC-V's architecture and how to use it. But I do have some comments: > However, in Chata's case, it needs to access a RISC-V assembler from within its C++ code. The alternative is to use some ugly C function like system() to run external software as if it were a human or script running a command in a terminal. Have you tried LLVM's C++ API [0]? To be fair, I do think there's merit in writing your own assembler with your own API. But you don't necessarily have to. I'm not likely to go back to assembly unless my employer needs that extra level of optimization. But if/when I do, and the target platform is RISC-V, then I'll definitely consider Ultraseembler. > It's not clear when exactly exceptions are slow. I had to do some research here. There are plenty of cppcon presentations [1] about exceptions, performance, caveats, blah blah. There's also other C++ conferences that have similar presentations (or even, almost identical presentations because the presenters go to multiple conferences), though I don't have a link handy because I pretty much only attend cppcon. [0]: https://stackoverflow.com/questions/10675661/what-exactly-is... [1]: https://www.youtube.com/results?search_query=cppcon+exceptio... |
| |
| ▲ | netr0ute 6 days ago | parent [-] | | > LLVM's C++ API I think I read something about this but couldn't figure out how to use it because the documentation is horrible. So, I found it easier to implement my own, and as it turns out, there are a few HORRIBLE bugs in the LLVM assembler (from cross reference testing) probably because nobody is using the C++ API. > There are plenty of cppcon presentations [1] about exceptions, performance, caveats, blah blah. I don't have enough time to watch these kinds of presentations. | | |
| ▲ | mpyne 6 days ago | parent | next [-] | | A specific presentation I'd point to is Khalil Estell's presentation on reducing exception code size on embedded platforms at https://www.youtube.com/watch?v=bY2FlayomlE But honestly you'd get vast majority of the benefit just by skimming through the slides at https://github.com/CppCon/CppCon2024/blob/main/Presentations... With a couple of symbols you define yourself a lot of the associated g++ code size is sharply reduced while still allowing exceptions to work. (Slide 60 on) | |
| ▲ | 0x98 6 days ago | parent | prev | next [-] | | > I think I read something about this but couldn't figure out how to use it because the documentation is horrible. Fair enough. > So, I found it easier to implement my own, and as it turns out, there are a few HORRIBLE bugs in the LLVM assembler (from cross reference testing) Interesting claim, do you have any examples? | |
| ▲ | inetknght 5 days ago | parent | prev [-] | | > I don't have enough time to watch these kinds of presentations. Then let me pick and share some of my favorites that I found enlightening, and summarize with some information that I found useful. By far, the most useful one is Khalil Estell's presentation last year [0]. It's a fairly face paced but relatively deep dive into exception mechanics. At the end, he advocates for a new tool that would audit a program to determine what exceptions could be thrown. I think that's a flipping fantastic idea for a tool. Unfortunately I haven't seen any progress toward it -- if someone here knows where his tool is, or a similar tool, please reply! I did send him an email a few months ago inquiring about it, but haven't received a reply. Nonetheless, the whole presentation was excellent in my opinion. I did see that he had another related presentation at ACCU this year [4] with a topic of "C++ Exceptions are Code Compression" (which I totally can believe -- I've seen it myself in binary sizes), but I haven't seen his presentation yet. I'll watch it later today. Just about anything from Herb Sutter is good. I don't like that he works for Microsoft, but he does great stuff for C++, including the old Guru of the Week series [1]. In particular, his 2019 presentation [2] describes different error handling techniques, some difficulties and pitfalls in combining libraries with different error handling techniques, and leads up to explaining why std::expected came about. He does pontificate a lot though, so the presentation is fairly high level and slow paced. Dave Watson's 2017 presentation [3] dives into a few different implementations of stack unwinding. It's good to understand how different compilers implement exceptions with low- or zero-cost overhead and what that "overhead" is really measuring. So, there's about a half of a day of presentations to watch here. I hope that's not too much for you. [0]: https://www.youtube.com/watch?v=bY2FlayomlE [1]: https://herbsutter.com/gotw/ [2]: https://www.youtube.com/watch?v=ARYP83yNAWk [3]: https://www.youtube.com/watch?v=_Ivd3qzgT7U [4]: https://www.youtube.com/watch?v=LorcxyJ9zr4 | | |
|
|
|
| ▲ | NooneAtAll3 6 days ago | parent | prev | next [-] |
| isn't your MemoryBank already somewhere in std::pmr? If I'm honest, I've never looked into pmr, but I always thought that that's where std has arena allocators and stuff https://en.cppreference.com/w/cpp/header/memory_resource.htm... |
|
| ▲ | msla 6 days ago | parent | prev | next [-] |
| What's the difference between a Programming Furu and a Programming Guru? Is there a joke I'm missing? |
| |
| ▲ | netr0ute 6 days ago | parent [-] | | Furus are "fake gurus." It comes from the Fintwit space where "furus" share their +1000% option trades as if they're geniuses in order to get you to sign up for their expensive Substack. |
|
|
| ▲ | jclarkcom 6 days ago | parent | prev [-] |
| You might look into using memory mapped IO for reading input and writing your output files. This can save some memory allocations and file read and write times. I did this with a project where I got more than 10x speed up. For many cases file IO is going to be your bottleneck. |
| |
| ▲ | Sesse__ 6 days ago | parent [-] | | mmap-based I/O still needs to go through the kernel, including memory allocation (in the page cache) and all. If you've got 10x speedup from mmap, it is usually because your explicit I/O was very inefficient; there are situations where mmap is useful, but it's rarely a high-performance strategy, as it's really hard for it to guess what your intended I/O patterns are just from the page faults it's seeing. | | |
| ▲ | jclarkcom 5 days ago | parent [-] | | Windows uses memory mapped IO for loading all executable processes because it allows you to start executing a process after loading a few pages even if the exe is megabytes. You can use the same to reduce latency for starting to assemble data before the rest of the file loads, the rest can be loaded using more efficienct asynchronous mechanisms. Using for output also means your process doesnt waits on flushes that is also async. And in memory constrained environments the OS doesn’t have to write your data to swap, it can just reload it from the meeting mapped file. | | |
| ▲ | Sesse__ 5 days ago | parent [-] | | Linux also uses mmap for running executables. But explicit I/O does not mean you have to start off by a gigabyte-long read(). | | |
|
|
|
