ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:72120] [Ruby trunk - Feature #11817] [Open] map.parallel
       [not found] <redmine.issue-11817.20151214225341@ruby-lang.org>
@ 2015-12-14 22:53 ` eike
  2015-12-15  4:28 ` [ruby-core:72131] [Ruby trunk - Feature #11817] map.parallel matz
  1 sibling, 0 replies; 2+ messages in thread
From: eike @ 2015-12-14 22:53 UTC (permalink / raw
  To: ruby-core

Issue #11817 has been reported by Eike Dierks.

----------------------------------------
Feature #11817: map.parallel
https://bugs.ruby-lang.org/issues/11817

* Author: Eike Dierks
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I'd like to suggest a new method: #parallel

That method should take care of executing workloads in parallel across multiple cores.

I believe that #map can sometimes be distributed to many simultaneous threads.

So we would spread out the map blocks into parallel processing,
and then collect the results in order.

I believe this would need some new infrastructure like apple did with great_central,
so I'm talking along these lines.
(Aka we only want to open up as many threads as there are cores)

This would not help much with a simple map (because we need to collect and serialize the results in the end)
but it could be cool for more complex mappings.

Maybe this should have been a rails topic first,
because there it might make a lot of sense to render partials in parallel,
this could really speed up rails response rendering ;-)

But I believe this is a topic for ruby in general.
Given that we now go to really many cores,
it should be at the heart of ruby to use that.

For a start we could just declare #parallel as -> return self.
and than improve on it.

A naive implementation would just open a new thread for every parallel map block,
but that would not work well -- it actually would be very slow.

So we actually need a thread management,
along the lines of great central.

I believe this should be built into the very core libs of the ruby language.

I know this is hard stuff, but it needs to be done.
Let's go parallel from the heart of the language.

---


Please let us discuss if adding the #parallel method would be a good idea.
Let's come up with some implementations to find the problems.

I'm explicitly referring to map#parallel here.
In rails that might be cache.parallel (if you followed)

for some math tasks it might also be
   parallel do {}



































-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [ruby-core:72131] [Ruby trunk - Feature #11817] map.parallel
       [not found] <redmine.issue-11817.20151214225341@ruby-lang.org>
  2015-12-14 22:53 ` [ruby-core:72120] [Ruby trunk - Feature #11817] [Open] map.parallel eike
@ 2015-12-15  4:28 ` matz
  1 sibling, 0 replies; 2+ messages in thread
From: matz @ 2015-12-15  4:28 UTC (permalink / raw
  To: ruby-core

Issue #11817 has been updated by Yukihiro Matsumoto.


Show me your imaginary code example, so we can understand your concrete intention.
There's lot of issues around concurrency in Ruby. Simply adding `map.parallel` may not solve the problem.
But we are interested in your idea.

Matz.


----------------------------------------
Feature #11817: map.parallel
https://bugs.ruby-lang.org/issues/11817#change-55542

* Author: Eike Dierks
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I'd like to suggest a new method: #parallel

That method should take care of executing workloads in parallel across multiple cores.

I believe that #map can sometimes be distributed to many simultaneous threads.

So we would spread out the map blocks into parallel processing,
and then collect the results in order.

I believe this would need some new infrastructure like apple did with great_central,
so I'm talking along these lines.
(Aka we only want to open up as many threads as there are cores)

This would not help much with a simple map (because we need to collect and serialize the results in the end)
but it could be cool for more complex mappings.

Maybe this should have been a rails topic first,
because there it might make a lot of sense to render partials in parallel,
this could really speed up rails response rendering ;-)

But I believe this is a topic for ruby in general.
Given that we now go to really many cores,
it should be at the heart of ruby to use that.

For a start we could just declare #parallel as -> return self.
and than improve on it.

A naive implementation would just open a new thread for every parallel map block,
but that would not work well -- it actually would be very slow.

So we actually need a thread management,
along the lines of great central.

I believe this should be built into the very core libs of the ruby language.

I know this is hard stuff, but it needs to be done.
Let's go parallel from the heart of the language.

---


Please let us discuss if adding the #parallel method would be a good idea.
Let's come up with some implementations to find the problems.

I'm explicitly referring to map#parallel here.
In rails that might be cache.parallel (if you followed)

for some math tasks it might also be
   parallel do {}



































-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-12-15  3:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <redmine.issue-11817.20151214225341@ruby-lang.org>
2015-12-14 22:53 ` [ruby-core:72120] [Ruby trunk - Feature #11817] [Open] map.parallel eike
2015-12-15  4:28 ` [ruby-core:72131] [Ruby trunk - Feature #11817] map.parallel matz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).