Interesting. I have read that collection but I completely forgot about this story.
Blindsight also has augmented humans whose reasoning is beyond baseline human understanding and there are dedicated people that are there to bridge the communication.
There's a couple in that collection - 'Understand' is about a brain injury patient that gets an experimental treatment and becomes super intelligent - what he does with that intelligence and humanities attempts to restrain him, and 'Division by Zero' is a mathematicians struggle to continue with life when a discovery undermines all of mathematics. It's a great collection.
Well, except for the fact that asserts can be used during debugging to do input validation while these shouldn't be used for that. They also introduced `contract_assert` which seems to have no benefit over assert other than it's more likely to not be disabled.
Asserts also shouldn't be used for input validation.
If during debugging you are peppering asserts that restate things that per the API contract should already be true, but you want to make extra sure your bug isn't caused by something slipping through the cracks: that's what what contracts are for.
Nothing to do with pthreads. As long as you want to use shared memory to communicate with concurrent processes, you need a memory model with compiler support. Even if you exclusively use mutexes.
> As long as you want to use shared memory to communicate with concurrent processes
That's something pthreads do and CSP doesn't.
> you need a memory model with compiler support. Even if you exclusively use mutexes.
If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."
For better or worse, our current hardware architectures present a shared memory interface for intercore communication. So if you want a non-toy CSP programing language you have to implement with a programming language that support shared memory concurrency (for the OS at the very least).
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
Not sure what CSP is supposed to mean, but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
> but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
If that's your bottleneck then you've either already solved every other class of performance issue with your program or you're working in a fantasy environment-- you're probably not hacking on FFmpeg right now. 90% of performance is I/O bound, whether it be the disk, the network or whatever. You can easily ascertain the correctness of a CSP system, because it's just message passing and inherently synchronous. Not so much with shared memory. It's a tradeoff. Unix pipes are also pretty goddamn fast, like, this is an issue people have spent time squeezing as much performance as possible out of. Google uses Go for all of their important backend shit. The entire internet is a giant message passing system.
> 90% of performance is I/O bound, whether it be the disk, the network or whatever
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
> to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must.
Architecture problem. Do your programs normally saturate a 40 gig network pipe?
> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
You can boot up a Plan 9 kernel and tell me if it works or not. Like, this is not a high bar, but you keep treating it like it is because it's based on the assumption that all compilers are broken with the set of all compilers being GCC.
At least some GCC devs claimed that the standard does not impose any requirements on these macros if a compiler does not claim strict ISO/IEC 6055 (aka IEE 754) conformance (which is still optional, and gcc and clang do not claim it).
A C implementation can be fully-compliant without conforming to ISO/IEC 6055, that's optional; question is just whether that optionality extends to fenv.h too. (at least how far I looked, imo it doesn't, and the pragma must exist, and valid fesetround calls (which there may be none of if no FE_* rounding modes are defined) must be represented by FLT_ROUNDS, even if it changes literally no actual float op behavior)
> So I run most development on a VM. But part of my test-suite and smoke-tests rely on runninng it directly on the host OS (which is not ideal). I'd love to hear suggestions to avoid this.
reply