Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #28595 > unrolled thread

Forth reinvention

Back to article view | Back to comp.lang.forth

Contents

  Forth reinvention dambere@web.de - 2014-02-20 01:19 -0800
    Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 05:07 -0500
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 14:56 +0000
        Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 16:16 -0500
          Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 23:25 +0000
            Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 20:42 -0500
              Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:41 +0000
    Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-20 11:18 +0100
      Re: Forth reinvention dambere@web.de - 2014-02-20 02:36 -0800
        Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-20 17:35 +0100
          Re: Forth reinvention dambere@web.de - 2014-02-20 11:34 -0800
            Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 09:53 -1000
            Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 12:23 -0800
              Re: Forth reinvention dambere@web.de - 2014-02-20 14:00 -0800
                Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 14:23 -0800
                  Re: Forth reinvention dambere@web.de - 2014-02-22 02:21 -0800
                    Re: Forth reinvention AKK <akk@nospam.org> - 2014-02-22 12:02 +0100
                Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:38 -0600
            Re: Forth reinvention Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-20 12:35 -0800
              Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 13:38 -0800
    Re: Forth reinvention m.a.m.hendrix@tue.nl - 2014-02-20 03:59 -0800
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 15:11 +0000
        Re: Forth reinvention m.a.m.hendrix@tue.nl - 2014-02-20 07:41 -0800
    Re: Forth reinvention Richard Owlett <rowlett@pcnetinc.com> - 2014-02-20 06:38 -0600
      Re: Forth reinvention dambere@web.de - 2014-02-20 12:03 -0800
    Re: Forth reinvention Julian Fondren <julian.fondren@gmail.com> - 2014-02-20 07:08 -0800
    Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 09:37 -1000
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 20:50 +0000
        Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 15:39 -1000
          Re: Forth reinvention albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:50 +0000
          Re: Forth reinvention Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-02-21 11:10 +0000
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 13:50 +0000
          Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:46 -0600
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:55 +0000
            Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:11 +0000
              Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:23 -0600
          Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:38 +0000
          Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:29 +0000
            Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-22 07:52 -1000
              Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-22 19:06 +0000
              Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-23 13:40 +0000
      Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 20:40 -0500
        Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 18:43 -1000
          Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-21 13:16 +0100
        Re: Forth reinvention stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:49 +0000
      Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 14:50 +0000
        Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 16:28 +0000
          Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:54 +0000
            Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:27 -0500
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-22 17:49 +0000
        Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:51 +0100
          Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:39 -0600
            Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:40 +0100
              Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-22 19:24 -0800
                Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:48 +0100
              Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:39 -0600
                Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:46 +0100
                  Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-23 14:26 -0800
                    Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-24 02:44 +0100
                      Re: Forth reinvention Spam@ControlQ.com - 2014-03-03 12:43 -0500
                      Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-03-03 10:06 -0800
                  Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:59 -0600
    Re: Forth reinvention mike73900@gmail.com - 2014-03-03 14:04 -0800
      Re: Forth reinvention mhx@iae.nl - 2014-03-05 06:59 -0800
        Re: Forth reinvention Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-03-05 16:33 +0100
        Re: Forth reinvention Mark Wills <markwills1970@gmail.com> - 2014-03-05 09:08 -0800
          Re: Forth reinvention mhx@iae.nl - 2014-03-05 10:47 -0800
    Re: Forth reinvention AKK <akk@nospam.org> - 2014-03-07 07:30 +0100
      Re: Forth reinvention Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-07 07:55 +0100
      Re: Forth reinvention albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:29 +0000
        Re: Forth reinvention AKK <akk@nospam.org> - 2014-03-07 12:04 +0100
        Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-07 17:03 -0500
          Re: Forth reinvention Mark Wills <markwills1970@gmail.com> - 2014-03-08 05:31 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#28601

On Thursday, February 20, 2014 10:19:23 AM UTC+1, dam...@web.de wrote:
> With regard to the discussion in 'Forth in oblivion', 
> I have specifically asked the question what properties a 
> Forth successor should have ? I think important are the 
> following aspects: 
> - switch to infix notation: Personally I found RPN an elegant, 
> mathematical notation both solving inconsistencies of traditional
> infix notations and ease parsing. However, in general people 
> have an innate aversion to the adoption of unorthodox concepts 
> nor are people able to think in abstract terms of implementation 
> efficiency. 
> For these psychological reasons, a RPN based programming language 
> can hardly interest a wider audience without constraint, 
> especially since most programmers these days are already 
> grown with quite different (and much more complex) languages 
> compared to Forth. 

Debatable :-) Let me say that none of the users of my 
programs (engineers, students) has EVER brought this up. (All my 
programs use the interpreter to some extent -- I find the 
interpreter a big ++ that should not be hidden).

> - Automatic parallelization: The trend goes to multi core 
> architectures. A programming language that is relieving the 
> programmer from the not inconsiderable task of paralleling 
> programs will necessarily be attractive. 

Right. In the iForth project we are looking into parallel 
programming, but we add a very distinctive Forth flavor to it...

> - Lack of leadership: To my knowledge, there exist no 
> central leadership with financial impact to promote Forth 
> by all means. This must change.

Promote? Why?

-marcel

[toc] | [prev] | [next] | [standalone]

#28608

on 20/02/2014 11:59:51, marcel wrote:
> > On Thursday, February 20, 2014 10:19:23 AM UTC+1, dam...@web.de wrote:
>> With regard to the discussion in 'Forth in oblivion',
>> I have specifically asked the question what properties a
>> Forth successor should have ? I think important are the
>> following aspects:
>> - switch to infix notation: Personally I found RPN an elegant,
>> mathematical notation both solving inconsistencies of traditional
>> infix notations and ease parsing. However, in general people
>> have an innate aversion to the adoption of unorthodox concepts
>> nor are people able to think in abstract terms of implementation
>> efficiency.
>> For these psychological reasons, a RPN based programming language
>> can hardly interest a wider audience without constraint,
>> especially since most programmers these days are already
>> grown with quite different (and much more complex) languages
>> compared to Forth.
> 
> Debatable :-) Let me say that none of the users of my
> programs (engineers, students) has EVER brought this up. (All my
> programs use the interpreter to some extent -- I find the
> interpreter a big ++ that should not be hidden).
> 
>> - Automatic parallelization: The trend goes to multi core
>> architectures. A programming language that is relieving the
>> programmer from the not inconsiderable task of paralleling
>> programs will necessarily be attractive.
> 
> Right. In the iForth project we are looking into parallel
> programming, but we add a very distinctive Forth flavor to it...

This is one area where most languages fail to shine. It's not just about
parallelising compute either but also in the IO space utilising shared
memory and storage. The current models are well past their sell by dates.
http://snia.org/sites/default/files/NVMProgrammingModel_v1.pdf

> 
>> - Lack of leadership: To my knowledge, there exist no
>> central leadership with financial impact to promote Forth
>> by all means. This must change.
> 
> Promote? Why?

He wants to follow.

> 
> -marcel
> 

[toc] | [prev] | [next] | [standalone]

#28609

On Thursday, February 20, 2014 4:11:06 PM UTC+1, Alex McDonald wrote:
[..]
> http://snia.org/sites/default/files/NVMProgrammingModel_v1.pdf 
[..]

People that think like that are the reason Forth exists (and stays).

-marcel

[toc] | [prev] | [next] | [standalone]

#28603

dambere@web.de wrote:
> With regard to the discussion in 'Forth in oblivion', I have specifically asked the question what properties a Forth successor should have ?
>
> I think important are the following aspects:
>
> - switch to infix notation:

Impossible to do and yet remain FORTH [ps - I'm not shouting but 
being historically accurate {hint read up on how FORTH was named ;}]

> Personally I found RPN an elegant mathematical notation both solving inconsistencies
> of traditional infix notations and ease parsing.

Thus indicating some grasp on reality.

>However, in general people have an innate aversion to the 
adoption of unorthodox
>  concepts nor are people able to think in abstract terms of 
implementation efficiency.

And that is germane? How?

>  For these psychological reasons, a RPN based programming 
language can hardly interest
>  a wider audience without constraint, especially since most 
programmers these days are
>  already grown with quite different (and much more complex) 
languages compared to Forth.

With that logic the financial districts of the modern world would 
not exist.
"Why?" you ask. Claustrophobes are uncomfortable in elevators, 
therefore elevators
  should not exist. Therefore buildings are height limited.
            Recall "For want of a nail ... ..."

> - Automatic parallelization:
> The trend goes to multi core architectures. A programming language that is relieving
>  the programmer from the not inconsiderable task of paralleling 
programs will
>  necessarily be attractive.

I don't follow your logic.

> - Lack of leadership:
> To my knowledge, there exist no central leadership with financial impact to promote
>  Forth by all means. This must change.
>

And you will contribute the first million? ???

[toc] | [prev] | [next] | [standalone]

#28618

Am Donnerstag, 20. Februar 2014 13:38:42 UTC+1 schrieb Richard Owlett:
> dambere@web.de wrote:
> With that logic the financial districts of the modern world would 
> not exist.
> 
> "Why?" you ask. Claustrophobes are uncomfortable in elevators, 
> 
> therefore elevators
> 
>   should not exist. Therefore buildings are height limited.
> 
>             Recall "For want of a nail ... ..."
I think these examples are not suitable. Technological developments of companies subject to innovation pressure because of the need for financial growth within capitalist economies. Technological innovations will also prevail if they lead to (what the elevator example alludes) a generally recognizable value. In both cases, one can speak of a pressure to innovation. This is exactly the reason why I wrote: "... a resist audience without *CONSTRAINT*". You can easily see the validity of my argument if you take into consideration how much companies of a certain size are dealing with innovation problems. This is because the financial security of these companies compensates for the pressure to innovation so that the human aspect I noted take more attention.

[toc] | [prev] | [next] | [standalone]

#28607

On Thursday, February 20, 2014 3:19:23 AM UTC-6, dam...@web.de wrote:
> With regard to the discussion in 'Forth in oblivion', I have specifically asked the question what properties a Forth successor should have ?
> 

What disussion?  It's the same old race to dance on Forth's grave.  Forth fell marginally in some measure of popularity and no longer appears on a list?  Well, that's as good an excuse as any to break out the prepared euology.  Forth is DEAD because none of you listened to ME!!1  I guess it's easier to whine about libraries than to write them, but I don't see where the fun is.
 
> 
> I think important are the following aspects:
> 

Summarized:

1. Let's have a completely different language.
2. With a gimmick.
3. And a sugar daddy.

[toc] | [prev] | [next] | [standalone]

#28616

On 2/19/14 11:19 PM, dambere@web.de wrote:
> With regard to the discussion in 'Forth in oblivion', I have specifically asked the question what properties a Forth successor should have ?
>
> I think important are the following aspects:
>
> - switch to infix notation:
> Personally I found RPN an elegant, mathematical notation both solving inconsistencies of traditional infix notations and ease parsing. However, in general people have an innate aversion to the adoption of unorthodox concepts nor are people able to think in abstract terms of implementation efficiency. For these psychological reasons, a RPN based programming language can hardly interest a wider audience without constraint, especially since most programmers these days are already grown with quite different (and much more complex) languages compared to Forth.

RPN is way overstated as an impediment to Forth, because it's an obvious 
feature that's easy to point to. But I really don't think it's a serious 
impediment. Many, many people in addition to you have learned to manage 
*postfix* notation and found it elegant and efficient.

As Hans so succinctly said, stacks are used in many compilers. By 
exposing them (and other internal features) Forth puts more power in the 
hands of programmers. That's a good thing.

> - Automatic parallelization:
> The trend goes to multi core architectures. A programming language that is relieving the programmer from the not inconsiderable task of paralleling programs will necessarily be attractive.

Parallelization is an implementation strategy, not a language feature.

> - Lack of leadership:
> To my knowledge, there exist no central leadership with financial impact to promote Forth by all means. This must change.
>

Now you're close to the mark. The reason that Forth hasn't received more 
notice in the world is largely due to the fact that none of its 
developers or supporters has had the financial or institutional backing 
necessary to publicize it widely or give it the public visibility needed 
to generate a following. FORTH, Inc. FIG, MPE, and others have tried, 
but without way more significant budgets small businesses or interest 
groups have no leverage.

How many of you who are using Forth in professional projects are 
reporting on your work in journals, magazines, or general computing 
conferences? If you don't do this, how is anyone to know?

Did the Forth 200x group send press releases regarding the Forth2012 
public review? Did they follow up with prominent magazines or web sites 
to ensure the notice was published?

The fact is, Forth has undergone a constant process of reinvention ever 
since Chuck's first publications in the 70's. Major improvements have 
been made in features (multitasking, data base support, graphics) by 
vendors, and Forth94 generated immense breakthroughs in implementation 
strategies such as sophisticated cross-compilers and optimizing 
compilers. The innovations have been undertaken primarily by people who 
are *using* the language in real-world applications, and therefore 
respond to actual programmer needs, rather than perceptions. 21st C 
Forth is a far better language than it was in the 80's or 90's.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#28622

on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
> On 2/19/14 11:19 PM, dambere@web.de wrote:

> 
>> - Automatic parallelization:
>> The trend goes to multi core architectures. A programming language that is relieving the programmer 
from the not inconsiderable task of paralleling programs will necessarily
be attractive. > 
> Parallelization is an implementation strategy, not a language feature.

Here I disagree, and very strongly indeed. Concurrent and parallel
progamming demand languages that allow more than just task or process
management. There are many forms; SIMD, parallel execution on tightly
coupled, loosely coupled and decoupled systems, shared distributed
memory, concurrent actor models, future and promise models -- heck, a
huge slew of parallel & concurrent stuff where the language is the
difference between being able to do something and not being able to
express yourself at all. And no, it's not just libraries or
implementation strategy.

[toc] | [prev] | [next] | [standalone]

#28634

On 2/20/14 10:50 AM, Alex McDonald wrote:
> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>
>>
>>> - Automatic parallelization:
>>> The trend goes to multi core architectures. A programming language that is relieving the programmer
> from the not inconsiderable task of paralleling programs will necessarily
> be attractive. >
>> Parallelization is an implementation strategy, not a language feature.
>
> Here I disagree, and very strongly indeed. Concurrent and parallel
> progamming demand languages that allow more than just task or process
> management. There are many forms; SIMD, parallel execution on tightly
> coupled, loosely coupled and decoupled systems, shared distributed
> memory, concurrent actor models, future and promise models -- heck, a
> huge slew of parallel & concurrent stuff where the language is the
> difference between being able to do something and not being able to
> express yourself at all. And no, it's not just libraries or
> implementation strategy.

Do you have an example?

There seem to be lots of multi-core architectures out there nowadays, 
but I haven't heard of a "new language" in which everything has to be 
re-written in order to run on them. If programs written in C, C++, Java, 
or whatever are now suddenly running parallel, surely that's because the 
underlying components have been structured to enable the parallel 
architecture.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#28646

In article <UpSdnZ24iMXIM5vOnZ2dnUVZ_hqdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 2/20/14 10:50 AM, Alex McDonald wrote:
>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>
>>>
>>>> - Automatic parallelization:
>>>> The trend goes to multi core architectures. A programming language
>that is relieving the programmer
>> from the not inconsiderable task of paralleling programs will necessarily
>> be attractive. >
>>> Parallelization is an implementation strategy, not a language feature.
>>
>> Here I disagree, and very strongly indeed. Concurrent and parallel
>> progamming demand languages that allow more than just task or process
>> management. There are many forms; SIMD, parallel execution on tightly
>> coupled, loosely coupled and decoupled systems, shared distributed
>> memory, concurrent actor models, future and promise models -- heck, a
>> huge slew of parallel & concurrent stuff where the language is the
>> difference between being able to do something and not being able to
>> express yourself at all. And no, it's not just libraries or
>> implementation strategy.
>
>Do you have an example?
>
>There seem to be lots of multi-core architectures out there nowadays,
>but I haven't heard of a "new language" in which everything has to be
>re-written in order to run on them. If programs written in C, C++, Java,
>or whatever are now suddenly running parallel, surely that's because the
>underlying components have been structured to enable the parallel
>architecture.

We only need to be subtle changes in the definition of a language.
For instance Algol68 knows subroutine calls with more than one parameter.
The language specification says that
in ape( note(..), miss(..), home(..) );
the parameters to ape() may be calculated concurrently, in our case
by three separate cores.
If
    note(..); miss(..); home(..) ;
is replaced by
    note(..), miss(..), home(..) ;
this indicates that the procedure calls may be calculated concurrently.
A similar situation for slicing
  a[17:2000] = b[19:2002];
This may be split over several DMA devices.

It is the programmers responsibility to make sure that any race conditions
don't influence the result.

Up till now Algol68 has been implemented as a traditional sequential
language, but it need not be.

In tForth (transputer) there is a more obtrusive notation
PAR
   note
   miss
   home
END-PAR

but it amounts to the same.

It is as trivial as in a baking pie recipe:
   while the dough is rising, mix the white of 17 eggs
   with 200 grams of sugar.

Now synchronization is much harder, but we have a lot of experience
of that in operating systems like Unix that run a lot of processes
at the same time. (Algol68 has language features to help.)

>
>Cheers,
>Elizabeth
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#28650

Elizabeth D. Rather wrote:

> On 2/20/14 10:50 AM, Alex McDonald wrote:
>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>
>>>
>>>> - Automatic parallelization:
>>>> The trend goes to multi core architectures. A programming language that
>>>> is relieving the programmer
>> from the not inconsiderable task of paralleling programs will necessarily
>> be attractive. >
>>> Parallelization is an implementation strategy, not a language feature.
>>
>> Here I disagree, and very strongly indeed. Concurrent and parallel
>> progamming demand languages that allow more than just task or process
>> management. There are many forms; SIMD, parallel execution on tightly
>> coupled, loosely coupled and decoupled systems, shared distributed
>> memory, concurrent actor models, future and promise models -- heck, a
>> huge slew of parallel & concurrent stuff where the language is the
>> difference between being able to do something and not being able to
>> express yourself at all. And no, it's not just libraries or
>> implementation strategy.
> 
> Do you have an example?
> 
> There seem to be lots of multi-core architectures out there nowadays,
> but I haven't heard of a "new language" in which everything has to be
> re-written in order to run on them. If programs written in C, C++, Java,
> or whatever are now suddenly running parallel, surely that's because the
> underlying components have been structured to enable the parallel
> architecture.
> 
> Cheers,
> Elizabeth

Many of the multi-core implementations I have seen are far from parallel 
processing. Each core being targeted at specific tasks. I suppose the MPP 
implementation might be the best eample of parallel operation.
 
-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#28657

on 21/02/2014 11:10:27, Paul E Bennett wrote:
> Elizabeth D. Rather wrote:
> 
>> On 2/20/14 10:50 AM, Alex McDonald wrote:
>>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>>
>>>>
>>>>> - Automatic parallelization:
>>>>> The trend goes to multi core architectures. A programming language that
>>>>> is relieving the programmer
>>> from the not inconsiderable task of paralleling programs will necessarily
>>> be attractive. >
>>>> Parallelization is an implementation strategy, not a language feature.
>>>
>>> Here I disagree, and very strongly indeed. Concurrent and parallel
>>> progamming demand languages that allow more than just task or process
>>> management. There are many forms; SIMD, parallel execution on tightly
>>> coupled, loosely coupled and decoupled systems, shared distributed
>>> memory, concurrent actor models, future and promise models -- heck, a
>>> huge slew of parallel & concurrent stuff where the language is the
>>> difference between being able to do something and not being able to
>>> express yourself at all. And no, it's not just libraries or
>>> implementation strategy.
>>
>> Do you have an example?
>>
>> There seem to be lots of multi-core architectures out there nowadays,
>> but I haven't heard of a "new language" in which everything has to be
>> re-written in order to run on them. If programs written in C, C++, Java,
>> or whatever are now suddenly running parallel, surely that's because the
>> underlying components have been structured to enable the parallel
>> architecture.
>>
>> Cheers,
>> Elizabeth
> 
> Many of the multi-core implementations I have seen are far from
> parallel processing. Each core being targeted at specific tasks. I
> suppose the MPP implementation might be the best eample of parallel
> operation.
> 

Parallelism comes in all shapes and sizes.

A more "modern" approach to running many different tasks (in the sense
that this is much more recent technology) is to run them as VMs that
support a specific unit of work. These "super-task" VMs have task-like
features such as clone, suspend here and resume there on a different
processor or snapshot and duplicate to several physical processors. (Even
different architectures; there's research work on enabling running Intel
or ARM VMs on ARM or Intel. Why not? That's what VMs are all about;
they're virtual.)

It's not unusual to find a set of VMs, one running a load balancer, one
running Apache and wiki software and another running the SQL database for
the wiki perhaps all on a single machine when the load is very light, and
then "bursting" (to use the slightly overexcitable terminology of the
cloud providers) several tens of VMs running on tens of physical servers
when the load is heavy.

To manage these VMs and other resources like network and storage are for
example OpenStack and CloudStack APIs. Will these APIs become language
features in the future? I'd certainly bet on it.

[toc] | [prev] | [next] | [standalone]

#28651

Elizabeth D. Rather <erather@forth.com> wrote:
> On 2/20/14 10:50 AM, Alex McDonald wrote:
>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>
>>>
>>>> - Automatic parallelization:
>>>> The trend goes to multi core architectures. A programming language that is relieving the programmer
>> from the not inconsiderable task of paralleling programs will necessarily
>> be attractive. >
>>> Parallelization is an implementation strategy, not a language feature.
>>
>> Here I disagree, and very strongly indeed. Concurrent and parallel
>> progamming demand languages that allow more than just task or process
>> management. There are many forms; SIMD, parallel execution on tightly
>> coupled, loosely coupled and decoupled systems, shared distributed
>> memory, concurrent actor models, future and promise models -- heck, a
>> huge slew of parallel & concurrent stuff where the language is the
>> difference between being able to do something and not being able to
>> express yourself at all. And no, it's not just libraries or
>> implementation strategy.
> 
> Do you have an example?
> 
> There seem to be lots of multi-core architectures out there nowadays, 
> but I haven't heard of a "new language" in which everything has to be 
> re-written in order to run on them. If programs written in C, C++, Java, 
> or whatever are now suddenly running parallel, surely that's because the 
> underlying components have been structured to enable the parallel 
> architecture.

Here's a very simple example in Java, which has had a recent overhaul
to make it easier to write parallel programs.

This is old-style Java method that calculates the sum from
lo <= n < hi of some function f(n):

    static double sum(int lo, int hi, IntToDoubleFunction f) {
        double res = 0;
        for (int i = lo; i < hi; i++)
            res += f.apply(i);
        return res;
    }

The exact details of the syntax don't matter, but it's equivalent to
the Forth

: sum ( xt lo hi -- f)
   0.0e  swap do  i s>f dup execute f+  loop drop ;

New-style Java looks like this:

    static double sum(int lo, int hi, IntToDoubleFunction f) {
        return IntStream.range(lo, hi).mapToDouble(f).sum();
    }

Here, we create a stream of integers from lo to hi, apply the function
f to every element, and sum the results.  It's the same calculation,
but it's inherently parallel: there is no implied ordering from lo to
hi, so this computation can be spread over many processors.  Of course
a heoric optimizing compiler could determine that the first program
could be converted into parallel execution, but that's hard to do in
general.  I'm sure there could be a nice Forth equivalent of the
second form, but it would take some designing.

Andrew.

[toc] | [prev] | [next] | [standalone]

#28656

on 21/02/2014 11:46:27, Andrew Haley wrote:
> Elizabeth D. Rather <erather@forth.com> wrote:
>> On 2/20/14 10:50 AM, Alex McDonald wrote:
>>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>>
>>>>
>>>>> - Automatic parallelization:
>>>>> The trend goes to multi core architectures. A programming language that is relieving the 
programmer
>>> from the not inconsiderable task of paralleling programs will necessarily
>>> be attractive. >
>>>> Parallelization is an implementation strategy, not a language feature.
>>>
>>> Here I disagree, and very strongly indeed. Concurrent and parallel
>>> progamming demand languages that allow more than just task or process
>>> management. There are many forms; SIMD, parallel execution on tightly
>>> coupled, loosely coupled and decoupled systems, shared distributed
>>> memory, concurrent actor models, future and promise models -- heck, a
>>> huge slew of parallel & concurrent stuff where the language is the
>>> difference between being able to do something and not being able to
>>> express yourself at all. And no, it's not just libraries or
>>> implementation strategy.
>>
>> Do you have an example?
>>
>> There seem to be lots of multi-core architectures out there nowadays,
>> but I haven't heard of a "new language" in which everything has to be
>> re-written in order to run on them. If programs written in C, C++, Java,
>> or whatever are now suddenly running parallel, surely that's because the
>> underlying components have been structured to enable the parallel
>> architecture.
> 
> Here's a very simple example in Java, which has had a recent overhaul
> to make it easier to write parallel programs.
> 
> This is old-style Java method that calculates the sum from
> lo <= n < hi of some function f(n):
> 
> static double sum(int lo, int hi, IntToDoubleFunction f) {
> double res = 0;
> for (int i = lo; i < hi; i++)
> res += f.apply(i);
> return res;
> }
> 
> The exact details of the syntax don't matter, but it's equivalent to
> the Forth
> 
>: sum ( xt lo hi -- f)
> 0.0e  swap do  i s>f dup execute f+  loop drop ;
> 
> New-style Java looks like this:
> 
> static double sum(int lo, int hi, IntToDoubleFunction f) {
> return IntStream.range(lo, hi).mapToDouble(f).sum();
> }
> 
> Here, we create a stream of integers from lo to hi, apply the function
> f to every element, and sum the results. It's the same calculation,
> but it's inherently parallel: there is no implied ordering from lo to
> hi, so this computation can be spread over many processors. Of course

Or fewer & faster SIMD instructions.

> a heoric optimizing compiler could determine that the first program
> could be converted into parallel execution, but that's hard to do in
> general. I'm sure there could be a nice Forth equivalent of the second
> form, but it would take some designing.
> 
> Andrew.

[toc] | [prev] | [next] | [standalone]

#28661

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>This is old-style Java method that calculates the sum from
>lo <= n < hi of some function f(n):
>
>    static double sum(int lo, int hi, IntToDoubleFunction f) {
>        double res = 0;
>        for (int i = lo; i < hi; i++)
>            res += f.apply(i);
>        return res;
>    }
>
>The exact details of the syntax don't matter, but it's equivalent to
>the Forth
>
>: sum ( xt lo hi -- f)
>   0.0e  swap do  i s>f dup execute f+  loop drop ;
>
>New-style Java looks like this:
>
>    static double sum(int lo, int hi, IntToDoubleFunction f) {
>        return IntStream.range(lo, hi).mapToDouble(f).sum();
>    }
>
>Here, we create a stream of integers from lo to hi, apply the function
>f to every element, and sum the results.  It's the same calculation,
>but it's inherently parallel: there is no implied ordering from lo to
>hi, so this computation can be spread over many processors.

Either it's parallel, or it's not the same calculation.  The
associative law does not hold for floating-point numbers, so the
result will be different in general (there may be some parameters for
which the results are the same).

>Of course
>a heoric optimizing compiler could determine that the first program
>could be converted into parallel execution, but that's hard to do in
>general.

The compiler must not rearrange the additions, so there is no
parallelization potential there.  It could do all the calls to f in
parallel (and somewhat in parallel to the summation), which may or may
not provide a parallelization speedup.

So the new style offers a parallelization opportunity not present in
the old style, but rounding behaviour will probably vary between runs
(right?).

I find it interesting that this style looks like a pipeline (with "."
instead of "|"); I guess that the functions may empoly data
parallelism in addition to pipeline parallelism, though.

>I'm sure there could be a nice Forth equivalent of the
>second form, but it would take some designing.

I did some presentation on pipeline/stream parallelism for Forth some
years ago:

@Unpublished{ertl08ft,
  author =       {M. Anton Ertl},
  title =        {Die Multicore-Herausforderung},
  note =         {Talk given at Forth-Tagung 2008},
  url =          {http://www.complang.tuwien.ac.at/papers/ertl08ft.pdf},
  year =         {2008}
}

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

[toc] | [prev] | [next] | [standalone]

#28685

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> The compiler must not rearrange the additions, so there is no
> parallelization potential there.  It could do all the calls to f in
> parallel (and somewhat in parallel to the summation), which may or may
> not provide a parallelization speedup.
> 
> So the new style offers a parallelization opportunity not present in
> the old style, but rounding behaviour will probably vary between runs
> (right?).

Good point.  That depends on the exact definition of sum(), and I
haven't checked.

> I find it interesting that this style looks like a pipeline (with "."
> instead of "|"); I guess that the functions may empoly data
> parallelism in addition to pipeline parallelism, though.
> 
>>I'm sure there could be a nice Forth equivalent of the
>>second form, but it would take some designing.
> 
> I did some presentation on pipeline/stream parallelism for Forth some
> years ago:
> 
> @Unpublished{ertl08ft,
>  author =       {M. Anton Ertl},
>  title =        {Die Multicore-Herausforderung},
>  note =         {Talk given at Forth-Tagung 2008},
>  url =          {http://www.complang.tuwien.ac.at/papers/ertl08ft.pdf},
>  year =         {2008}
> }

Forth, Inc. did vectorFORTH some twenty-odd years ago.  It was
presented at The 1990 Rochester FORTH Conference.  But the parallel
data model I described isn't just about vectors: in the long run the
idea, AIUI, is to replace iteration over structures altogether.  I
don't know if that's practical, and I have my doubts.

Andrew.

[toc] | [prev] | [next] | [standalone]

#28654

on 21/02/2014 01:39:30, "Elizabeth D. Rather" wrote:
> On 2/20/14 10:50 AM, Alex McDonald wrote:
>> on 20/02/2014 19:37:55, "Elizabeth D. Rather" wrote:
>>> On 2/19/14 11:19 PM, dambere@web.de wrote:
>>
>>>
>>>> - Automatic parallelization:
>>>> The trend goes to multi core architectures. A programming language that is relieving the programmer
>> from the not inconsiderable task of paralleling programs will necessarily
>> be attractive. >
>>> Parallelization is an implementation strategy, not a language feature.
>>
>> Here I disagree, and very strongly indeed. Concurrent and parallel
>> progamming demand languages that allow more than just task or process
>> management. There are many forms; SIMD, parallel execution on tightly
>> coupled, loosely coupled and decoupled systems, shared distributed
>> memory, concurrent actor models, future and promise models -- heck, a
>> huge slew of parallel & concurrent stuff where the language is the
>> difference between being able to do something and not being able to
>> express yourself at all. And no, it's not just libraries or
>> implementation strategy.
> 
> Do you have an example?

Yes. There's no way in Forth-the-language to specify an atomic operation
for X 1 +!. Interestingly, it doesn't need multi-core for it to be a
potential source of errors. That code isn't even guaranteed to be atomic
on a single processor if it uses pre-emptive interrupts and the interrupt
routine writes to X. Without basic atomic operation support, we can't
support locks or semaphores in Forth.

> 
> There seem to be lots of multi-core architectures out there nowadays,
> but I haven't heard of a "new language" in which everything has to be
> re-written in order to run on them. If programs written in C, C++,
> Java, or whatever are now suddenly running parallel, surely that's
> because the underlying components have been structured to enable the
> parallel architecture.

Of course, the hardware got there first. Much of my career has been spent
chasing the "good ideas" that hardware designers put in their offerings.
But languages must eventually catch up, because doing stuff like an
atomic increment is but one of the issues where language assistance is
essential if the concepts are to be transportable across architectures.
Not just OSes, but chipsets too.

It's not just multi-core either; that happens to be one of many ways of
parallel processing, the two major categories being task and data
parallelism. As an example of data parallelism I mentioned SIMD. Many
languages find it very hard to take advantage of instruction level
parallelism. Microsoft's latest & greatest C++ compiler barely supports
SSE2, and requires the use of extensive pragmas to help out the compiler.
Moving the pragmas into the language will help. See a great Intel
exposition of the issue here;
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1612.pdf

Forth is a bit of a laggard in this respect. Much of the ANS
specification is suitsble for single core processors with no SIMD and
non-preemptive scheduling to support concurrent programming. Now, it may
be that this was a suitable target yesterday, and remains a suitable
target today for resource constrained low end systems. But even cheap
chips are way beyond that now, and with Forths targeting desktop or
server class machines, we need task and data parallelism constructs built
into the language.

> 
> Cheers,
> Elizabeth
> 

[toc] | [prev] | [next] | [standalone]

#28679

"Elizabeth D. Rather" <erather@forth.com> writes:
>There seem to be lots of multi-core architectures out there nowadays, 
>but I haven't heard of a "new language" in which everything has to be 
>re-written in order to run on them.

I have heard of many such languages.

> If programs written in C, C++, Java, 
>or whatever are now suddenly running parallel,

They are not.  If they have been written multi-threaded, and the
threads don't wait too much on each other, they run in parallel,
otherwise they just run sequentially.

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

[toc] | [prev] | [next] | [standalone]

#28692

On 2/22/14 3:29 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> There seem to be lots of multi-core architectures out there nowadays,
>> but I haven't heard of a "new language" in which everything has to be
>> re-written in order to run on them.
>
> I have heard of many such languages.
>
>> If programs written in C, C++, Java,
>> or whatever are now suddenly running parallel,
>
> They are not.  If they have been written multi-threaded, and the
> threads don't wait too much on each other, they run in parallel,
> otherwise they just run sequentially.

Where is the "decision" to run them parallel made? At the language 
level, or the OS level? If at the OS level, the same applies to 
multi-threaded Forths. The style of multitasking in Forth has very 
little interdependence between threads.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#28693

on 22/02/2014 17:52:22, "Elizabeth D. Rather" wrote:
> On 2/22/14 3:29 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> There seem to be lots of multi-core architectures out there nowadays,
>>> but I haven't heard of a "new language" in which everything has to be
>>> re-written in order to run on them.
>>
>> I have heard of many such languages.
>>
>>> If programs written in C, C++, Java,
>>> or whatever are now suddenly running parallel,
>>
>> They are not.  If they have been written multi-threaded, and the
>> threads don't wait too much on each other, they run in parallel,
>> otherwise they just run sequentially.
> 
> Where is the "decision" to run them parallel made? At the language
> level, or the OS level? If at the OS level, the same applies to
> multi-threaded Forths. The style of multitasking in Forth has very
> little interdependence between threads.
> 
> Cheers,
> Elizabeth
> 

The programmer makes that decision. Languages or libraries enable and the
OS delivers -- if it's been asked, and if it can.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web