search

igrigorik / agent

Agent is an attempt at modelling Go-like concurrency, in Ruby
http://www.igvita.com/2010/12/02/concurrency-with-actors-goroutines-ruby/
729 stars 21 forks source link

Interesting article... #19

Closed ylluminate closed 9 years ago

ylluminate commented 10 years ago

You got some nice exposure from this article: http://www.sitepoint.com/agent-go-like-concurrency-ruby

One thing that bothered me from this, and I'm not sure about what you're doing yet as this is the first time I heard of your library and thought I'd just ask the question since there's potential misinformation going on: since JRuby offers concurrent parallelism, can't Agent likewise leverage this in order to give us true concurrent parallelism in our apps? We have been doing some work in Go, but keep trying to shift back to ruby as we prefer the full stack ruby environment using it with JRuby on our servers, Opal to replace JS, and then RubyMotion for mobile app (iOS and now Android). Having Agent offer true parallel processing facilities would be fantastic.

cpuguy83 commented 10 years ago

@ylluminate the "go" command is creating a new thread. I would argue this should be a Fiber and not a thread with some scheduler for the fibers, but that's my opinion.

So, using JRuby you'll get the concurrency you are looking for.

steventen commented 10 years ago

But jruby seems worse in this benchmark, any idea why?

cpuguy83 commented 10 years ago

Did the Java VM have enough time to warm up?

corasaurus-hex commented 10 years ago

@cpuguy83 I chose not to use fibers for a couple reasons. The first is that ruby 1.8 doesn't have fibers and we still support it. We can drop support for 1.8 eventually but it's trivial to support if we don't use fibers. The second is that fibers require cooperation (Fiber#yield / Fiber#resume) and I wanted agent to behave more like go where you don't have to think about cooperation at all, the runtime performs the cooperation automatically for you.

cpuguy83 commented 10 years ago

@nate For this, Go is actually doing a bit more in the background with the goroutinues.

Essentially, there is a set number of goroutine workers, each with their own queue. When you fire off a goroutine it get's added to one of these queues. If a worker runs out of runnable goroutinues it will pop one off another worker's queue and run it itself. It would actually be really cool for something to implement this in Ruby... if only we all had the time to do it!

corasaurus-hex commented 10 years ago

@cpuguy83 Yep, totally aware of that, it's M:N threading. My point was that from the user standpoint I wanted agent to function exactly like goroutines in the sense that the user does not have to actively try to cooperate with other goroutines for scheduling. Go handles this cooperation for you, using as many threads as you set, and schedules all the goroutines onto these threads, switching during certain operations (I/O, memory allocation I think, can't remember what else). Since we can't make ruby do M:N scheduling without cooperation, we have to settle for using threads.

Integralist commented 9 years ago

Looks like this issue has died. Is there any reason it hasn't been closed? seems @nate has given valid enough reasoning for this issue to be closed (unless I'm missing something).