271–280 of 289 posts
Earlier quoted context omitted.
10x is a very safe margin. I suppose 2x is fine if you really know your code (usually you don't, really, unless you wrote all of it yourself).
Well, I’m not sure I’d call buying 1TiB of RAM and mlock’ing it all an optimization.
It is in the sense that it gets the speedup job done.
Earlier quoted context omitted.
Not at all compared to salaries. I mean just think about how many VMs you can buy for $200k-$500k/yr (total cost to the company of a senior engineer).
According to AWS you could only afford 10 instances each with 976GB of RAM for that salary (500k). If you were to do nothing but just buy the raw RAM it would cost you 50k. But you also need servers [0] to actually put the ram into. So it's probably closer to 70k. RAM isn't as cheap as you think. [0] and a network and network admins and server admins and and and
Earlier quoted context omitted.
I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on. Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems? I'm asking for one because I'm curious by nature and additionally because I simply take the garbage collector f…
The embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use…
Earlier quoted context omitted.
No, in practice this is not true. You will also need to write out to memory all the newly allocated objects which you don't need anymore. https://podcasts.apple.com/us/podcast/hidden-gc-bandwidth-co...
How is that related to memory allocation costs? We are talking about the cost of obtaining a chunk of memory. The cost of actually creating an object is allowed to be much higher because constructors are allowed to execute any arbitrary code. Just think about how expensive it would be to allocate a 3d vector consisting of 3 floats with malloc() 20000 times and then later deallocate it. Nobody is worrying about the co…
It's a cost that has to be paid when using bump pointer allocation.
> We are talking about the cost of obtaining a chunk of memory. The cost of actually creating an object is allowed to be much higher because constructors are allowed to execute any arbitrary code.
Accessing main memory is about two orders of magnitude slower than accessing L1. For that time you can run a lot of arbitrary code that accesses data in L1 and registers.
> Just think about how expensive it would be to allocate a 3d vector consisting of 3 floats with malloc() 20000 times and then later deallocate it. Nobody is worrying about the cost of writing 3 floats to RAM. Everyone is worrying about the cost of malloc traversing a free list and it causing memory fragmentation in the process. Meanwhile the arena allocator would be at least as efficient as using an array of 3d vectors.
malloc doesn't mandate free lists, other implementations exist. It's not about relative costs. OP claimed bump pointer allocation to be a "no-op" when it's clearly not.
Earlier quoted context omitted.
Well, I’m not sure I’d call buying 1TiB of RAM and mlock’ing it all an optimization.
It is not an "optimization" in the sense that it's not engineer's work. It is in the sense that it gets the speedup job done.
Earlier quoted context omitted.
It is not an "optimization" in the sense that it's not engineer's work. It is in the sense that it gets the speedup job done.
That’s just throwing hardware at a performance problem, not optimization.
Earlier quoted context omitted.
Arguably, the existence of nuclear reactors which don't fail safe under any contemplated crisis is a hardware bug. It's possible to design a reactor that can be ruptured by a bomb or earthquake, which will then dump core into a prepared area and cool down. This kind of physics-based safety is obviously not possible for airplanes.
What triggers the core dump? Humans? Software? Are there detectors integrated into the walls?
If all electronics fry simultaneously, then the reactor core cools in-place.
A bit OT, but I wonder how I'd feel if I was offered a job working on software for missiles. I'm sure the technical challenge would be immensely interesting, and I could tell myself that I cared more about accuracy and correctness than other potential hires... but from a moral standpoint, I don't think I could bring myself to do it. I realise of course that the military uses all sorts of software, including line of b…
> but from a moral standpoint, I don't think I could bring myself to do it. I've been in a similar situation, and I think there is something important to think about: Assuming you'd be working for the defense of a country with a track record of decency (at least a good fraction of the time anyway), you have to decide what people you want taking those jobs. Is it better that all of the people with qualms refuse to tak…
Yes, this is the kicker for me. My country does not have such a record. If it did, the hypothetical quandry would still exist, but would be much diminished.
Earlier quoted context omitted.
Rust's official documentation on FFI ( https://doc.rust-lang.org/nomicon/ffi.html ) recommends using an external crate 'libc' to facilitate even the minimal FFI functionality. This crate is not part of Rust itself. It is apparently maintained by some of Rust's developers, but again, this is not an official Rust component. To me this does not seem like the kind of mature design you would rely on for interoperability w…
Actually, Rust's std itself depends on that same libc crate, so it's a bit hard to say it's "not part of Rust itself".
Earlier quoted context omitted.
I feel like I've read about some rocket launch failures that were caused in part by launch delays leading to overflow and sign flipping, but can't find it now =/ It may be unwise to overide static analysis (a leak is found) with hueristics (the program won't run long enough to matter)
It is not just a heuristic if you have hard upper bounds on the things that matter - in that case, it is static analysis. A missile has a limited, and well-defined, fuel supply. In the case of memory management, it is not enough to just free it after use; you need to ensure that you have sufficient contiguous memory for each allocation. If you decide to go with a memory-compaction scheme, you have to be sure it never…
Ideally we'd be able to tie such assertions into a unified static analysis tool, rather than having humans evaluate conflicting analyses. And god forbid the hardware parameters ever change, because now you need to re-evaluate every such decision, even the ones nobody documented. Case in point: Arianne 5 (not exactly my original scenario, but exactly this one -- 64bit -> 16 bit overflow caused a variety of downstream effects ending in mission failure).