-------- Original Message --------
Subject: Re: [Jchat] new wiki essay
Date: Sat, 22 Feb 2014 10:31:48 -0500
From: Robert Bernecky <[email protected]>
To: [email protected], Morten Kromberg <[email protected]>
The folks at Dyalog have introduced "futures and isolates" into
release of 14.0 of Dyalog APL. Morten Kromberg talked a bit
about them here, at the Dyalog '13 conference:
http://www.google.com/url?q=http://www.dyalog.com/dyalog_13/presentations/D07_Parallel_Language_Features_in_Version_14.pptx&sa=U&ei=u8EIU5S8KIaayQHv_4HwBA&ved=0CCYQFjAB&usg=AFQjCNHsIxTDK1HLx9nzjqbGk4fVzGz-gw
I have not tried them out, but they look to have simplicity and
elegance, allowing many forms of parallelism to be expressed
in a way that will elate users of functional array language.
Bob
On 14-02-22 09:35 AM, Jan-Pieter Jacobs wrote:
Well, I think that low rank verbs working on higher rank data are easily
parallellizable (see for instance:
http://www.jsoftware.com/jwiki/MarshallLochbaum/Parallelize , in my
uninformed opinion, the same can work on other PC's as well).
The overhead issue is always there, and it is up to the user to not apply
parallellization for things that are not worth parallellizing.
The dependency and caching problem is a harder nut to crack. In Matlab,
they sort of solved the issue introducing different classes of variables
when using parallel for-loops:
http://www.mathworks.nl/help/distcomp/advanced-topics.html#bq_of7_-1 . A
similar thing might be concocted in J using ranks, and enforced through
preprocessing of the code being run. It's not perfect though, I've seen
lots of errors mixing this with pass-by-reference object oriented
programming, but it gets a long way already.
Just my 2 cents.
Jan-Pieter
2014-02-22 15:14 GMT+01:00 Don Guinn<[email protected]>:
The J notation is already for multiprocessing on multiprocessing computers
with shared memory. Each is just one example. When the rank of a verb is
less than the rank of its nouns can multiprocess.
Problems I see to expanding J to multiprocessing:
1: Any user definitions with side effects like using global names can fail.
2: Computer now use cache memories. Cache works well when the cache of one
processor is not being updated by another processor. This is not much of a
problem when dealing with unrelated tasks; however, J multitasking involves
multitasking related tasks. So cache update collisions are much more likely
and could really slow down processors.
3: The dispatching and cleanup for multiprocessing overhead might exceed
the time saved for short running verbs.
I would hate to see new conjunctions and adverbs added to J to support
multiprocessing as the existing ones are already so ready for
multiprocessing. Then the problem becomes how for the interpreter to know
when to multiprocess and when to not.
On Sat, Feb 22, 2014 at 1:07 AM, Jack Andrews<[email protected]> wrote:
What's an example of notation that might help concurrent computing? In
k,
there's peach (parallel each) which seems to be adequate.
On Friday, February 21, 2014, Raul Miller<[email protected]> wrote:
J is currently an excellent tool for developing those skills, but if
any
of
us have implemented J as a notation for homogeneous computations on
computing clusters, I've not heard about it.
And that's a shame. We have a lot we could offer people but we need to
clean up our act if we are going to succeed there.
Thanks,
--
Raul
On Thu, Feb 20, 2014 at 11:13 AM, robert therriault
<[email protected]<javascript:;>>wrote:
Nice work Raul,
I agree with Joe that it is key that the audience be identified, the
next
step beyond that is finding a way to get the production in front of
that
audience...gasp...marketing.
For now the best suggestion I have is to move your author's note to
the
top and make it an abstract. I think it sets the tone and the
motivation
for the reader really well.
On the employment issue, I think that people with skills in big data
are
in demand ... and that J is an excellent tool to develop and execute
those
skills.
Cheers, bob
On Feb 20, 2014, at 7:41 AM, Raul Miller<[email protected]
<javascript:;>>
wrote:
On Thu, Feb 20, 2014 at 10:33 AM, Joe Bogner<[email protected]
<javascript:;>
wrote:
I think the essay is fairly technical in nature and requires a
fairly
steep
baseline of knowledge. I agree that it might be helpful to
identify
the
audience up front. Maybe even have a "Why J?" for different types
of
audiences
In terms of wiki structure, perhaps urls with
Essays/WhyJ/AudienceType
might work.
That said, I am limited in my own vision (which is spread a bit
thin
right
now).
If anyone wants to propose their own draft and/or piggy back their
vision
on mine (or even replace mine - I have no problem taking a back
seat),
please feel free.
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
Robert Bernecky
Snake Island Research Inc
18 Fifth Street
Ward's Island
Toronto, Ontario M5J 2B9
[email protected]
tel: +1 416 203 0854
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
