13

I'm trying to get some speed up in my program and I've been told that Ruby Fibers are faster than threads and can take advantage of multiple cores. I've looked around, but I just can't find how to actually run different fibers concurrently. With threads you can do this:

threads = []

threads << Thread.new {Do something}
threads << Thread.new {Do something}

threads.each {|thread| thread.join}

I can't see how to do something like this with fibers. All I can find is yield and resume which seems like just a bunch of starting and stopping between the fibers. Is there a way to do true concurrency with fibers?

Jesse Jashinsky
  • 10,313
  • 6
  • 38
  • 63
  • 1
    I think you mean true parallelism (as noted by twopoint718 below). Fibers can be used for concurrency, so can threads. But they do not run in parallel. – Matt Connolly Jan 22 '13 at 23:09

3 Answers3

15

There seems to be a terminology issue between concurrency and parallelism.

I just can't find how to actually run different fibers concurrently.

I think you actually talk about parallelism, not about concurrency:

Concurrency is when two tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same instant. Eg. multitasking on a single-core machine. Parallelism is when tasks literally run at the same time, eg. on a multicore processor

Quoting: Concurrency vs Parallelism - What is the difference?.

Also well illustrated here: http://concur.rspace.googlecode.com/hg/talk/concur.html#title-slide

So to answer the question:

Fibers are primitives for implementing light weight cooperative concurrency in Ruby.

http://www.ruby-doc.org/core-2.1.1/Fiber.html

Which doesn't mean it can run in parallel.

Community
  • 1
  • 1
wacha
  • 499
  • 6
  • 14
15

No, you cannot do concurrency with Fibers. Fibers simply aren't a concurrency construct, they are a control-flow construct, like Exceptions. That's the whole point of Fibers: they never run in parallel, they are cooperative and they are deterministic. Fibers are coroutines. (In fact, I never understood why they aren't simply called Coroutines.)

The only concurrency construct in Ruby is Thread.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • Really? Oh well, that's too bad. That means the title of this article was misleading then: http://www.infoq.com/news/2007/08/ruby-1-9-fibers – Jesse Jashinsky Jun 18 '10 at 16:26
  • 6
    I was under the impression that co-routines are a form of concurrency, and the OP does in fact mean to ask can you do _parallelism_ with Ruby fibers (which you should not). – Matt Joiner Jul 28 '11 at 00:38
  • 5
    `Fibers` are concurrency constructs. – user454322 Feb 04 '14 at 13:44
  • Concurrency doesn't mean parallelism. It's a conceptual property of code, and fibers can be though of as running "at the same time" overall, even though only one is really on CPU at any given moment (Then again, same goes for all of ruby, even with threads) – DarkWiiPlayer Feb 07 '19 at 11:42
  • I think this answer might be out of date now. I was trying `Fiber`s today and came to this SO question trying to find out why my fibers weren't executing concurrently. I had a loop that created 100 of them all at once, where each one slept for one second, and then a loop that called `resume` on each of them. The program executed them sequentially, taking much longer than one second to complete. If I added a scheduler (I chose `libev_scheduler`) and added the code `Fiber.set_scheduler Libev::Scheduler.new` to my program, they did run concurrently, with the program finishing in about one second. – Matt Welke Sep 14 '22 at 21:20
  • I made my own question to share these results and to get help understanding the results (https://stackoverflow.com/questions/73723382/why-do-ruby-fibers-that-run-sequentially-without-a-scheduler-set-run-concurrentl). – Matt Welke Sep 14 '22 at 21:37
1

if you want true concurrency you'll want to use threads with jruby (which doesn't actually have fibers, it only has threads, one per fiber).

Another option is to "fork" to new processes, which could run things in true parallel on MRI.

rogerdpack
  • 62,887
  • 36
  • 269
  • 388