Re: RAFTS-like optimiser; progress report

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups	comp.lang.forth
Subject	Re: RAFTS-like optimiser; progress report
Date	2013-09-09 15:08 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<2013Sep9.170811@mips.complang.tuwien.ac.at> (permalink)
References	(1 earlier) <LPqdnRhGztBg07fPnZ2dnUVZ_oadnZ2d@supernews.com> <2013Sep7.170614@mips.complang.tuwien.ac.at> <laqdnaQ8I6t7CLbPnZ2dnUVZ_q2XnZ2d@supernews.com> <2013Sep9.144131@mips.complang.tuwien.ac.at> <DKydncrylYLrTrDPnZ2dnUVZ_gWdnZ2d@supernews.com>

Show all headers | View raw

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 visiblity 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, 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.

>> 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.

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.

>> What does that mean for the question you raise?  What should a Forth
>> system implementor do?
>> 
>> If we bet on outcome 1, we just generate a barrier after
>> every @ and !, and on good hardware, these barriers will cost little.
>> 
>> If we bet on outcome 2, we don't generate barriers automatically, but
>> provide ways for specialists to use them explicitly.
>
>I bet on 1.5 .

The Forth implementation generates barriers for half of the
accesses?-)

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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