freenode/#sicl - IRC Chatlog
Search
19:49:49
Bike
https://gist.github.com/Bike/e587d9f6dcfb4c50936d61c4bc150398 i wrote out (much of) how i'd explain atomics but it's more like a tutorial than a standard, so i'll have to pare that down
4:16:16
Bike
unfortunately, after a while this results in diagrams like these https://cdn.discordapp.com/attachments/390697866055647242/803840415941001236/c11.png
4:18:36
Bike
They're diagrams of possible executions (i.e. happens-before total orders) for simple C programs. I think the black lines are happens-before, and the colored lines relate to orderings of reads and writes that you have to deal with if you use atomics.
4:19:16
Bike
Incidentally, apparently hans "garbage collector" boehm is heavily involved in the C++ standards discussions of this stuff. that's kind of interesting
4:21:59
Bike
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0668r4.html or at least here he is. some of this stuff is still an open research area, at least as relates to like, formal verification.
4:24:44
Bike
actually in another tab i have a paper open that mentions interaction between this stuff and garbage collectors
4:25:20
Bike
"[...] a similar capability will likely be needed by any C++ garbage collector. Furthermore, garbage collectors enable use cases that are quite similar to those of [read copy update]"
4:25:57
Bike
But I will be interested to see if they're concerns for garbage collection more generally. In multithreaded environments anyway.
4:27:44
Bike
Most of the complicated stuff comes in when you give up sequential consistency, which apparently really does help performance sometimes. But probably if the main concern is correctness one can just stick with sequential consistency.
4:30:15
beach
So, in summary, in order to make C++ as fast as possible while still having a well-defined memory model, they need to make that memory model extremely complicated. At the same time, their exception system is broken, so can't really be used by application code, and the fact that they still stipulate manual memory management means that they can't write programs that are both modular and fast.
4:32:01
beach
Oh, and at the same time, the world's most popular programming language is Python, which is at least an order of magnitude slower than any naive Common Lisp implementation.
4:33:17
beach
So the only conclusion I can see is that they are doing all this work for game developers, who, as we know, don't care about modularity as long as they can save a few nanoseconds here and there.
4:34:35
Bike
my impression is that the memory model stuff is actually more closely linked to OS development. and system stuff like garbage collectors, apparently.
4:35:07
Bike
I guess because operating systems people are the one writing libraries to implement locks and stuff, which is one thing you want to be fast where sequential consistency isn't necessary.
4:35:37
Bike
some of the sbcl source about memory barriers actually just recommends reading a text file in the linux kernel docs
4:36:34
beach
That sounds plausible, actually. But I suspect they exaggerate the need for speed for both those use cases.
4:37:45
beach
I mean, take a modern OS. They spend all this time optimizing memory access and such, but they are stuck with expensive context switches that make it impossible to use modern I/O devices in the normal way.
4:40:23
beach
For example, I can't get a simple music-synth program to work on my Linux system with any reasonable delay, without compiling a special version of the kernel.
4:40:58
Bike
i haven't done enough programming with atomics to have much of a very educated opinion about speed. i'm hoping if lisp can get some definition here maybe i can.
4:41:44
Bike
the reason i started in on this again is that i realized the caching in ctype could be written in a lock free way pretty easily, but i can't actually express some of what i need for that
4:42:20
Bike
it's certainly possible boehm and so on are wrong, but i definitely don't know enough to convince anybody of that
4:42:43
beach
Bike: All I am saying is that we (i.e., you in this case) can probably afford to be more conservative with the memory model and still have good overall performance, due to other qualities of Common Lisp.
4:43:04
aeth
beach: That isn't true about game developers anymore. It was true 10-30 years ago back when they would ship a release and never patch it, leaving bugs and all. But these days, they might support the same game for 10-20 years so it actually needs to have readable/maintainable code.
4:43:07
Bike
yeah. i mean, it's not like i'm including the whole C++ memory model here, just stuff that seems like it could be useful.
4:43:25
aeth
beach: The "this doesn't need to be maintained and it does need to be a few nanoseconds faster" of today seems to be scientific computing
4:43:32
Bike
i'd also like to put in safety guarantees java (the only other language with a memory model, practically) has that C++ doesn't
4:44:03
beach
aeth: That's an interesting evolution. Thanks for the information. Though I still hear about "data-oriented programming" which seems to be the opposite of modulariry.
4:44:45
aeth
Yeah, some gamedevs think that they're still living in the past because e.g. Id in the days of Doom is still very romanticized. But a ton of gamedev is just done in C# or even Lua these days.
4:45:43
aeth
And most of the rest is stuck on C++ because of lock-in, e.g. the middleware they use is C++ and good luck interoperating with C++ with something other than C++
4:47:07
beach
Bike: Yes, I agree. I am just saying that there is probably no need so squeeze out every nanosecond. We have other advantages over languages such as C++.
4:48:21
Bike
the sbcl subtypep cache is very aggressively optimized and deals with some of this stuff. it would be interesting to know what particularly motivated that. i mean, subtypep is important if you're doing a lot of type inference stuff, of course
4:48:52
Bike
(it is, unfortunately, also kind of unreadable, but for lispy macro reasons rather than because of memory model concerns)
4:51:49
beach
I suspect we are observing the result of a maintenance model where (according to scymtym) each individual pretty much decides what is worthwhile, combined with a long history of evolution of the code.
4:53:17
beach
For SICL, I would much rather emphasize general mechanisms such as the call-site optimizatino I came up with, the fast generic dispatch, path replication, etc., than attempting to individually optimize every other part of the code.
4:56:36
beach
Let me take just one example. I decided to stick with the indirection imposed by standard objects, even for objects like functions simple arrays, etc. It would have been tempting to optimize those cases by introducing header-less objects, thereby complicating the code a lot.
4:56:37
beach
But with general mechanisms (like call-site optimization) and others yet to be invented, we can keep the code simple and still get better performance that what would have been possible with those tempting optimizations.
4:58:30
beach
Another example. The indirection through the header makes the rack internally consistent. So it seems a lot of synchronization can be avoided by forcing the reallocation of a new rack and the use of CAS.
4:58:57
beach
Without the indirection, locks would be the only option in many cases, as far as I can tell.
5:00:07
beach
I don't even know how SBCL handles AREF. I mean, it has to verify the size and then access the element. What if there is a call to ADJUST-ARRAY in the middle?
5:07:48
Bike
that's good to hear. i'm not sure about that one. the simple/compound thing feels a bit too elaborate
5:08:32
beach
I am not sure it is the style that a standards document should have, but the explanation is good.
5:13:02
beach
And the "Acquisition and release section" seems to totally answer my question from yesterday (my time).
5:18:11
beach
Bike: Oh, and I am often a good proofreader for this kind of stuff, because of my apparent inability to understand prose that is not extremely precise.
5:22:39
Bike
that's flattering, but i won't be convinced i understand this stuff until i've had to debug programs using it :)