Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #25599
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Subject | Re: RAFTS-like optimiser; progress report |
| Newsgroups | comp.lang.forth |
| References | (2 earlier) <2013Sep7.170614@mips.complang.tuwien.ac.at> <laqdnaQ8I6t7CLbPnZ2dnUVZ_q2XnZ2d@supernews.com> <2013Sep9.144131@mips.complang.tuwien.ac.at> <DKydncrylYLrTrDPnZ2dnUVZ_gWdnZ2d@supernews.com> <2013Sep9.170811@mips.complang.tuwien.ac.at> |
| Message-ID | <_vmdnVjAG8aecLDPnZ2dnUVZ_oudnZ2d@supernews.com> (permalink) |
| Date | 2013-09-09 10:45 -0500 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>Alex McDonald <blog@rivadpm.com> wrote: >>>>>>> 2. Elimination of redundant stores, such as 10 y1 ! 20 y1 ! >>>>>> >>>>>>And at that point you'll have to decide what to do about volatile. >>>>> >>>>> On the first order I would not let the compiler eliminate any @s and >>>>> !s. If the programmer wants to do that he can do it in the source code. >>>> >>>>Well, then you have to wonder about visibility to other threads. Do >>>>you really want every store to have a store barrier to ensure that it >>>>actually becomes visible to other threads? There's a performance >>>>penalty to pay. >>> >>> My view is that what some processor makers are doing wrt shared >>> memory is totally impractical for general consumption. It's the >>> supercomputer mindset: Let's do minimal hardware and leave the >>> headaches to the programmers. This approach has failed to work for >>> most programmers repeatedly (e.g., look at the Cell), and it will >>> fail when it comes to shared memory, too. >> >>Well, it's not failed yet. > > I would say it is failing all the time. Most programs (including > mine, apart from pipelines) are still single-threaded; there are some > multi-threaded programs, Indeed there are. It depends on the quality of language support for threads: some programming languages support it well, and programs are commonly multi-threaded, and libraries use multiple threads when they're there. > but stuff like lockless shared-memory access is still black magic > that hardly anybody does; AFAIK there's not even a textbook for that > stuff. The Art of Multiprocessor Programming, Maurice Herlihy, Nir Shavit, MK 2008, 2012. I suppose all this depends on whether you see the glass as half full or half empty. Programming with multiple threads is what I do all the time, so it's the world I know. >>> I see two possible outcomes: >>> >>> 1) Hardware will become capable enough to support sequential >>> consistency or something close enough to it (and the barriers will be >>> cheap, because they are noops). That's a common development in >>> hardware: First a new feature appears and is designed for minimizing >>> hardware, later it is implemented in a more usable way. Examples: >>> trap barrier (trapb) on Alpha; alignment restrictions on SSE and >>> SSE-based SIMD extensions. >>> >>> 2) Communicating between threads with shared memory will stay a topic >>> for specialists only. Mere mortals will use some higher-level >>> libraries to communicate between threads. The specialists will use >>> the mechanisms the hardware provides (like barriers) instead of using >>> C-inspired abstractions like volatile. >> >>Or some combination of the two. > > Yes, it is likely, that, if processor makers make their hardware > better, the number of programmers who can implement lockless code > correctly rises from <1000 to maybe 100000, which will still be a > minority of programmers, and most programmers will still use > higher-level libraries. The hardware isn't going to change wrt memory consistency, from what I've seen of newish designs. What we are going to get instead, though, is hardware support for transactions. Then you don't need to support memory consistency where it isn't necessary. > And I think that the processor makers will make their hardware > better, because they want to sell multi-cores, and the more > programmers are out there that can make good use of them, the more > applications will there be that are an argument for buying them. For some value of "better", yes, but not in the way you're suggesting. Maintaining a consistent view of memory all the time across all cores is too expensive. Andrew.
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RAFTS-like optimiser; progress report Alex McDonald <blog@rivadpm.com> - 2013-09-06 14:12 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-06 16:54 -0500
Re: RAFTS-like optimiser; progress report Alex McDonald <blog@rivadpm.com> - 2013-09-06 16:02 -0700
Re: RAFTS-like optimiser; progress report Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-07 03:01 +0200
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 03:21 -0500
Re: RAFTS-like optimiser; progress report albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-07 19:56 +0000
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-07 15:06 +0000
Re: RAFTS-like optimiser; progress report "Alex McDonald" <blog@rivadpm.com> - 2013-09-07 19:01 +0100
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-09 12:23 +0000
Re: RAFTS-like optimiser; progress report "Alex McDonald" <blog@rivadpm.com> - 2013-09-10 12:01 +0100
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-10 12:45 +0000
Re: RAFTS-like optimiser; progress report "Alex McDonald" <blog@rivadpm.com> - 2013-09-10 16:33 +0100
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-11 15:02 +0000
Re: RAFTS-like optimiser; progress report "Alex McDonald" <blog@rivadpm.com> - 2013-09-11 17:44 +0100
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-13 11:58 +0000
Re: RAFTS-like optimiser; progress report "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-14 22:47 -0400
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-15 16:05 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 16:08 -0500
Re: RAFTS-like optimiser; progress report mhx@iae.nl - 2013-09-08 03:21 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 06:42 -0500
Re: RAFTS-like optimiser; progress report mhx@iae.nl - 2013-09-08 04:51 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 07:02 -0500
Re: RAFTS-like optimiser; progress report Paul Rubin <no.email@nospam.invalid> - 2013-09-08 10:08 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 12:47 -0500
Re: RAFTS-like optimiser; progress report Paul Rubin <no.email@nospam.invalid> - 2013-09-08 11:10 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 15:16 -0500
Re: RAFTS-like optimiser; progress report Paul Rubin <no.email@nospam.invalid> - 2013-09-08 16:08 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-09 04:57 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-09 12:41 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-09 08:56 -0500
Re: RAFTS-like optimiser; progress report albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-09 14:20 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-09 09:27 -0500
Re: RAFTS-like optimiser; progress report "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-10 04:31 -0400
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-10 05:11 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-09 15:08 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-09 10:45 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-11 15:21 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-11 12:04 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-11 17:46 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-11 14:45 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-13 13:00 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-13 10:46 -0500
Re: RAFTS-like optimiser; progress report stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-13 17:44 +0000
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-14 15:31 +0000
Re: RAFTS-like optimiser; progress report Paul Rubin <no.email@nospam.invalid> - 2013-09-14 10:33 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-14 12:39 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-15 15:05 +0000
Re: RAFTS-like optimiser; progress report Alex McDonald <blog@rivadpm.com> - 2013-09-15 08:32 -0700
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-15 13:20 -0500
Re: RAFTS-like optimiser; progress report stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-15 16:54 +0000
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-15 17:02 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-15 12:54 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-16 09:21 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-16 08:39 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-16 15:48 +0000
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-16 15:03 -0500
Re: RAFTS-like optimiser; progress report anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-17 10:15 +0000
Re: RAFTS-like optimiser; progress report "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-17 17:24 -0400
Re: RAFTS-like optimiser; progress report stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-17 13:10 +0000
Re: RAFTS-like optimiser; progress report "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-10 04:30 -0400
Re: RAFTS-like optimiser; progress report Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-10 05:14 -0500
Re: RAFTS-like optimiser; progress report mhx@iae.nl - 2013-09-07 03:22 -0700
Re: RAFTS-like optimiser; progress report mhx@iae.nl - 2013-09-07 03:32 -0700
csiph-web