3 ms·

I'm confused: "Inspired by the apparent success of Java's new memory model, many of the same people set out to define a similar memory model for C++, eventuall

by bullen 5y ago

I'm confused: "Inspired by the apparent success of Java's new memory model, many of the same people set out to define a similar memory model for C++, eventually adopted in C++11." - https://research.swtch.com/plmm https://research.swtch.com/plmm "Rust's growing connection to the deep embedded world rules out the memory models of dynamic languages such as Java and Javascript." So what is Rust using now, C++11 or C++20? "memory model for atomics from C++20"?!

NobodyNada 5y ago
C++’s memory model has not changed much (if at all) since C++11. The Rust documentation specifically refers you to the C++20 standard, because they had to pick some version, but the C++20 memory model is (as far as I know) the same memory model introduced with the C/C++11 standards.
- pjmlp 5y ago
  Kind of, volatile meaning changed, but they are looking into it for C++23 as the embedded community is not happy with the outcome.
  - tialaramex 5y ago
    But, volatile isn't actually part of the memory model (except arguably in MSVC). And all that was changed was to deprecate things that are a bad idea. They don't mean anything different, they aren't hard errors, they're just deprecated. The embedded community in this context is people who were able to: #include <embedded_vendor/mmio_stuff.h> ... a file full of dodgy C pre-processor macros into their C++ project and are unhappy that J. F. Bastien's volatile deprecation means now their compiler points out what a terrible idea some of those macros actually are. Having the compiler shut up and silently allow this might make them feel better, but the situation they're in isn't actually improved by such a reversion at all. Removing the batteries and disabling the smoke alarm does mean you get a peaceful night's sleep, but sometimes you don't wake up after that peaceful night's sleep because meanwhile your home burned down and there was no alarm. The claim made in the proposal paper is that every C++ programmer who is including such macros definitely ensures by construction that their use of the macros is actually safe. You've probably read a bunch of real world C++ code written by people who are very confident in their ability to write correct programs, how do you feel about the likelihood that all these programs are in fact correct by construction despite using the unsafe macros? It seems that in later revisions of the proposal, they considerably reduced the scope of the un-deprecation, realising that even if you earnestly believe (interrupt_register |= ENABLE_IRQC) isn't a footgun, it's much harder to rationalise (clock_rate /= 3) and either way nobody wanted half the random places C++ allowed you to write "volatile" anyway, so deprecating those isn't actually a problem and "reverting" the deprecation just highlights yet another mysterious black box in C++ with no clear purpose.
    - pjmlp 5y ago
      Yep, I am with you on that, it is that kind of subculture that spoils the fun of using C++, and no matter what the community does to improve the language, such kind of source bases will always be around in some companies.
comex 5y ago
To quote the Rustonomicon page: “C++11 was the first version of the model but it has received some bugfixes since then.”
tialaramex 5y ago
Essentially the C++ 20 memory model is the C++ 11 memory model except where it talked about Consume now it just warns you that it's unclear whether this does what you want or expect and so you should probably not use it. "This ordering is temporarily discouraged" was added to the standard in 2017 and was unsurprisingly not removed in 2020. Rust simply omits Consume altogether. It can always be added if there's consensus that we now understand what's going on here and can meaningfully deliver it on hardware people actually have in the real world.
- bullen 5y ago
  Can you explain to someone who has not written a kernel but still coded Java and C(++) for 20 years how this quote is possible (how it works that Java which is written in C can outperform C): "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html I get the feeling this quote is possible due to the memory management rewrite of the entire JVM in version 1.5 to allow Doug to make the concurrency package? But I cannot explain it, even if I have experienced it!
  - tialaramex 5y ago
    I can try, in the most general sense. There are some specific technical tricks going on like the use of a JIT (Just In Time compiler) but mostly it comes back to this: The Java program isn't doing anything that is literally impossible in C, but powerful abstractions can make it exponentially easier for everybody to do it in Java. I can just about keep in my head how Quick Sort works. So, I figure I could write one, from scratch, in maybe a day or two in a language like C and have it work. But obviously I shouldn't do that, your standard C library comes with a perfectly nice fast sort. However, Java is supplied with an array of equally good features, and C is quite sparse on that front. You could program every one of those features in C, but, you probably didn't. Memory management is an example like that, but spread through most programs. If you're meticulously allocating and freeing things in C, that takes time. Is it worth it? Maybe not but can you keep track well enough to do anything faster without just leaking unlimited memory? Java comes with a good Garbage Collector which can avoid all that explicit tracking you need to do, yet free all the same memory. Clever. You can do this in C, some people do, but it's hard, you probably don't do it.

by bullen 5y ago

NobodyNada 5y ago

C++’s memory model has not changed much (if at all) since C++11. The Rust documentation specifically refers you to the C++20 standard, because they had to pick some version, but the C++20 memory model is (as far as I know) the same memory model introduced with the C/C++11 standards.

pjmlp 5y ago
Kind of, volatile meaning changed, but they are looking into it for C++23 as the embedded community is not happy with the outcome.
- tialaramex 5y ago
  But, volatile isn't actually part of the memory model (except arguably in MSVC). And all that was changed was to deprecate things that are a bad idea. They don't mean anything different, they aren't hard errors, they're just deprecated. The embedded community in this context is people who were able to: #include <embedded_vendor/mmio_stuff.h> ... a file full of dodgy C pre-processor macros into their C++ project and are unhappy that J. F. Bastien's volatile deprecation means now their compiler points out what a terrible idea some of those macros actually are. Having the compiler shut up and silently allow this might make them feel better, but the situation they're in isn't actually improved by such a reversion at all. Removing the batteries and disabling the smoke alarm does mean you get a peaceful night's sleep, but sometimes you don't wake up after that peaceful night's sleep because meanwhile your home burned down and there was no alarm. The claim made in the proposal paper is that every C++ programmer who is including such macros definitely ensures by construction that their use of the macros is actually safe. You've probably read a bunch of real world C++ code written by people who are very confident in their ability to write correct programs, how do you feel about the likelihood that all these programs are in fact correct by construction despite using the unsafe macros? It seems that in later revisions of the proposal, they considerably reduced the scope of the un-deprecation, realising that even if you earnestly believe (interrupt_register |= ENABLE_IRQC) isn't a footgun, it's much harder to rationalise (clock_rate /= 3) and either way nobody wanted half the random places C++ allowed you to write "volatile" anyway, so deprecating those isn't actually a problem and "reverting" the deprecation just highlights yet another mysterious black box in C++ with no clear purpose.
  - pjmlp 5y ago
    Yep, I am with you on that, it is that kind of subculture that spoils the fun of using C++, and no matter what the community does to improve the language, such kind of source bases will always be around in some companies.

comex 5y ago

To quote the Rustonomicon page: “C++11 was the first version of the model but it has received some bugfixes since then.”

tialaramex 5y ago

Essentially the C++ 20 memory model is the C++ 11 memory model except where it talked about Consume now it just warns you that it's unclear whether this does what you want or expect and so you should probably not use it. "This ordering is temporarily discouraged" was added to the standard in 2017 and was unsurprisingly not removed in 2020. Rust simply omits Consume altogether. It can always be added if there's consensus that we now understand what's going on here and can meaningfully deliver it on hardware people actually have in the real world.

bullen 5y ago
Can you explain to someone who has not written a kernel but still coded Java and C(++) for 20 years how this quote is possible (how it works that Java which is written in C can outperform C): "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html I get the feeling this quote is possible due to the memory management rewrite of the entire JVM in version 1.5 to allow Doug to make the concurrency package? But I cannot explain it, even if I have experienced it!
- tialaramex 5y ago
  I can try, in the most general sense. There are some specific technical tricks going on like the use of a JIT (Just In Time compiler) but mostly it comes back to this: The Java program isn't doing anything that is literally impossible in C, but powerful abstractions can make it exponentially easier for everybody to do it in Java. I can just about keep in my head how Quick Sort works. So, I figure I could write one, from scratch, in maybe a day or two in a language like C and have it work. But obviously I shouldn't do that, your standard C library comes with a perfectly nice fast sort. However, Java is supplied with an array of equally good features, and C is quite sparse on that front. You could program every one of those features in C, but, you probably didn't. Memory management is an example like that, but spread through most programs. If you're meticulously allocating and freeing things in C, that takes time. Is it worth it? Maybe not but can you keep track well enough to do anything faster without just leaking unlimited memory? Java comes with a good Garbage Collector which can avoid all that explicit tracking you need to do, yet free all the same memory. Clever. You can do this in C, some people do, but it's hard, you probably don't do it.