A well written and thoughtful article! Thanks for sharing.
It's been a while since I've read article on something like online gambling without feeling like the author was trying to proselytize.
Edit:
I appreciate the human perspective shared by the article, and get the feeling that OP offers a warning of the consequences of working in stigmatized fields. Ofc online gambling (and gambling in general tbh) is a terrible thing that ruins lives.
Thank you very much for reading! Yes, the purpose of this essay was to shed light on the challenges of launching startups in stigmatized niches and the consequences of working in them.
I'm pretty interested in realtime computing and didn't realise C++ was considered bandwidth efficient! Coming from C, I find myself avoiding most 'new' C++ features because I can't easily figure out how they allocate without grabbing a memory profiler.
You can always go through cachegrind or perf and see what happens with your code.
I managed to reach practical IPC limits of the hardware I was running on, and while I could theoretically make prefetcher happier with some matrix reordering, looking back, I'm not sure how much performance it provided since the FPU was already saturated at that point.
C++ is like C with extra features, but you don't need to use them.
If you want control over your memory, you can do pointers the C way, but you still have features like templates, namespaces, etc... Another advantage of C++ is that it can go both high and low level within the same language.
Disadvantage of C++ is mostly related to portability and interop. Things like name mangling, constructors, etc... can be a problem. Also, C++ officially doesn't support some C features like "restrict". In practice, you often can use them, but it is nonstandard. Probably not a concern for HPC.
> C++ is like C with extra features, but you don't need to use them
C++ certainly (literally (Cfront[0])) used to be this, but I thought modern (decade or more) conventional wisdom is to NOT think like this anymore. Curious to hear others weigh in.
To me, it is not "conventional wisdom", it is what a vocal group of C++ guys who look at Rust and its memory safety and don't want to be left out.
Their way is not wrong, new constructs are indeed safer, more powerful, etc... But if you are only in for the new stuff, why use C++ at all, you are probably better off with Rust or something more modern. The strength of C++ is that it can do everything, including C, there is no "right" way to use it. If you need raw pointers, use raw pointers, if you need the fancy constructs the STL provides, use them, these are all supported features of the language, don't let someone else who may be working in a completely different field tell you that you shouldn't use them.
C++ by comparison doesn't stand in your way too much either.
I feel like the biggest gripe Rust has is what happens when you do have to go unsafe.
That seems to be a strong point of contention for many folks.
Maybe all the reasons that lead people to use unsafe rust go away or the attitude about it shifts in some manner.
For me Rust turned out to be less interesting after I saw the whole ceremony about typing.
The amount of things I had to grasp just to get a glimpse into what a library does felt much more involved than any of the things I did with C++.
The whole annotation-ting feels much less necessary and more like a proper opt-in there.
C++ comes with baggage and requires up-front training. You need to dive into every language feature and STL library, learn how compilers implement stuff, then decide what to use and what not to, and the decision often depends on context. It has a high cognitive load in my opinion for that reason. But once you do that, you get a relatively high-level language that can go as low and be as fast as C.
There is unless using a llvm compiler that does naive things with code motion.
Rust is typically slowest (often negligible <3%), C++ has better CUDA support, and C can be heavily optimized with inline assembly (very unforgiving to juniors.)
Maybe not what they meant, but Rust sometimes makes it tempting to just copy things rather than fighting the borrow checker. Whereas in C++ you're free to just pass pointers around and not worry about it until / unless your code crashes or gets exploited.
Speaking authoritatively from my position as an incompetent C++ / Rust dev.
I see. Fortunately, I'm aware of that and I don't use clone (unless I intend to) as much. Borrow checker is usually not a problem when writing scientific/HPC code.
Because passing pointers isn't as ergonomic in Rust, I do things in arena-based way (for example setting up quadtrees or octrees). Is that part of the issue when it comes to memory bandwidth?
Stable Rust doesn't have a local allocator construct yet, you can only change the global allocator or use a separate crate to provide a local equivalent.
Right. I have seen Zig where one needs to specify allocators as well. I'm sorry I'm not well versed enough to know how it makes things better for HPC though?
For now my plan is to write fairly similar style code as one may write in C++/Fortran through MPI bindings in Rust.
if you're using thread level parallelism, there is always a benefit to having a per-thread allocator so that you don't have to take global locks to get memory, they become highly contended.
if you take that one step further and only use those objects on a single core, now your default model is lock-free non-shared objects. at large scale that becomes kind of mandatory. some large shared memory machines even forgo cache consistency because you really can't do it effectively at large scale anyways.
but all of this is highly platform dependent, and I wouldn't get too wrapped up around it to begin with. I would encourage you though to worry first about expressing your domain semantics, with the understanding that some refactoring for performance will likely be necessary.
if you have the patience and personally and within the project, it can be a lot of fun to really get in there and think about the necessary dependencies and how they can be expressed on the hardware. there's a lot of cool tricks, for example trading off redundant computation to reduce the frequency of communication.
There's a lot of useful advice here that'll surely come in handy to me later. For now, yeah I'm just going to try to make things work. So far I have mostly written intra-node code for which rayon has been adequate. I haven't gotten around to test the ergonomics of rs-mpi. But it feels quite an exciting prospect for sure.
I'm talking almost exactly about this haha. Flight software representation!! Although I have no experience programming FPGAs, I hope to gain some soon. They seem like the ultimate solution to my IO woes.
No way, was looking at the Z-7045 for a work project literally today. And yep I agree, simpler solutions have simpler problems lol. Thanks for the recommendation, I'll give it a look!
That chip was hitting a sweet spot in terms of DRAM controller and distributing memory bandwidth between CPU cores and fabric. Xilinx was very afraid of screwing this up and running into bottlenecks. One of the best balanced chips in that regard with a great controller. Your best bet still was to keep everything in blockram as much as possible and only read and write DRAM once at every end of the computation...
It might be my inner Luddite talking, but LLM use in defense and intelligence terrifies me. What happens when built-in model biases or hallucinations affect human safety? Who is to blame and how will this be mitigated? Fascinating but scary.
Not sure about the primary FSW but the BFS uses cFS[0]. As the sibling comment mentions, you can check it out on GitHub. Sadly I believe NASA keeps most of their best code private, probably siloed into mission-specific codebases. Still, the cFS repo is an awesome crash course on old-school Flight Software techniques.
At about 1:20, the presenter says the BFS uses a different OS and hardware (not sure if that means a different instance, or a different class, so to speak).
The amount and tone of discourse on this post is blowing my mind a little bit. I appreciate the criticism and concern about EFF's justification (it definitely seems a bit arbitrary) and would be a bit pissed if I was a donor. But X is so clearly an actively hostile, botted, and controlled platform. Does the hn crowd really value X so much? Or is this comment section also getting botted lol.
P.S. Man the AI writing complaints on this thread are quite upsetting. OP is handling it a lot better than I would, lol.
reply