- "C++ Modules Might Be Dead-on-Arrival" - 1 Update
- You have to be more convinced by my writing - 1 Update
- About my scalable algorithms.. - 1 Update
- [Modération JNTP] Annulation de <q32hkh$k8t$7@dont-email.me> - 1 Update
- I have just taken a look at the Memory ordering of ARM CPU architecture - 1 Update
| Thomas Koenig <tkoenig@netcologne.de>: Feb 01 11:17PM ["Followup-To:" nach comp.lang.fortran gesetzt.] > similar to Fortran's most recent module/submodule system. (Apart from > the C++ habit of creating incomprehensible syntax.) The problem seems > to be the interaction with the preprocessor. The build system (which was proposed to be solved by referring to some of Oracle via some sort of web server by a committee member, but where the Oracle was supposed to have its info from was left unspecified) was one point. Interaction with the preprocessor was another. Renaming when importing from a module was not supposed to be possible, and modules were proposed to be independent of namespaces - you could happily have identifiers from several namespaces in a single module, and identifiers from one namespace distributed across several modules. I think the last two points show that the proposed C++ modules are indeed fundamentally different from Fortran modules and submodules. > One of the best decisions of the Fortran committee in the past was to > *not* include a preprocessor in the standard. (Sorry, couldn't resist.) And so people use the ill-suited C preprocessor anyway :-) |
| Horizon68 <horizon@horizon.com>: Feb 01 03:16PM -0800 Hello... You have to be more convinced by my writing about weak memory models like the ARM CPU architecture: Read more here what is saying Herb Sutter about "Strong" and "weak" hardware memory models: https://herbsutter.com/2012/08/02/strong-and-weak-hardware-memory-models/ As you have noticed i have to wait for ARM to switch to TSO like it is doing with ARMv8, this will enable us to very easily port some aglorithms from x86 TSO to ARM TSO. Now my scalable algorithms are working on x86, so i think that my scalable algorithms will be very easily portable to ARM CPU architecture as soon as ARM will switch to TSO memory model. Thank you, Amine Moulay Ramdane. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 01 02:42PM -0800 On 2/1/2019 2:03 PM, Horizon68 wrote: > https://en.wikipedia.org/wiki/Memory_ordering > Here is my scalable MLock and my scalable AMLock that i have invented: > https://sites.google.com/site/scalable68/scalable-mlock [...] Do you happen to have a link to the paper where the original MLock is? I used to have it, but manged to loose it: damn it! I remember coding it up over in comp.arch some years ago. |
| Elephant Man <conanospamic@gmail.com>: Feb 01 10:42PM Article d'annulation émis par un modérateur JNTP via Nemo. |
| Horizon68 <horizon@horizon.com>: Feb 01 02:36PM -0800 Hello, Read this: I have just taken a look at the Memory ordering of ARM CPU architecture here: https://en.wikipedia.org/wiki/Memory_ordering And i think that there is something happening with weak memory models like ARM and this is not good, take for example my scalable MLock or my scalable AMLock that i have invented here: https://sites.google.com/site/scalable68/scalable-mlock and here: https://sites.google.com/site/scalable68/scalable-amlock They are working now with x86 memory model that is a TSO memory model like Sparc TSO, but to be able to port them to ARM i have to use more memory barrier that costs more than on x86, also there is another problem is that you can make more errors on the memory ordering process on the weaker memory model of ARM. So i think i will stay with x86 CPU architecture, and not port my scalable algorithms on ARM, because ARM must provide us with a TSO memory model to be able to be more efficient. About memory models and sequential consistency: As you have noticed i am working with x86 architecture.. Even though x86 gives up on sequential consistency, it's among the most well-behaved architectures in terms of the crazy behaviors it allows. Most other architectures implement even weaker memory models. ARM memory model is notoriously underspecified, but is essentially a form of weak ordering, which provides very few guarantees. Weak ordering allows almost any operation to be reordered, which enables a variety of hardware optimizations but is also a nightmare to program at the lowest levels. Read more here: https://homes.cs.washington.edu/~bornholt/post/memory-models.html Memory Models: x86 is TSO, TSO is Good Essentially, the conclusion is that x86 in practice implements the old SPARC TSO memory model. The big take-away from the talk for me is that it confirms the observation made may times before that SPARC TSO seems to be the optimal memory model. It is sufficiently understandable that programmers can write correct code without having barriers everywhere. It is sufficiently weak that you can build fast hardware implementation that can scale to big machines. Read more here: https://jakob.engbloms.se/archives/1435 Thank you, Amine Moulay Ramdane. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment