A Solution to CPU-intensive Tasks in IO Loops • Hacker News Board

Re: A Solution to CPU-intensive Tasks in IO Loops

#21

Post by jamii » Mon, Feb 06, 2012, 9:54 AM UTC

yxhuvud wrote: post #19

willvarfar wrote: post #3

Earlier quoted context omitted.

(article author) Spot on except for the bit about being inefficient; presumed performance is very much the thing that makes the complexity worth it.

What are your thoughts on the disruptor pattern? It seems to me to be something that tries to eat the cake of multithreading while still having a lot of the simplicity of eventing. ( https://code.google.com/p/disruptor/ )

The disruptor is just a very efficient event loop. It doesn't prevent you from blocking the handling thread.

Re: A Solution to CPU-intensive Tasks in IO Loops

#22

Post by superrad » Mon, Feb 06, 2012, 12:16 PM UTC

Doesn't erlang effectively do this, allowing its processes to only execute a certain amount of vm instructions before allowing a switch to another process?

Re: A Solution to CPU-intensive Tasks in IO Loops

#23

Post by willvarfar » Mon, Feb 06, 2012, 3:49 PM UTC

superrad wrote: post #22

Doesn't erlang effectively do this, allowing its processes to only execute a certain amount of vm instructions before allowing a switch to another process?

Yes, it is one of the neat languages with the green threads that I alluded to towards the end of the article.

Your description also fits CPython, though ;)

Re: A Solution to CPU-intensive Tasks in IO Loops

#24

Post by yxhuvud » Mon, Feb 06, 2012, 5:04 PM UTC

jamii wrote: post #21

yxhuvud wrote: post #19

Earlier quoted context omitted.

What are your thoughts on the disruptor pattern? It seems to me to be something that tries to eat the cake of multithreading while still having a lot of the simplicity of eventing. ( https://code.google.com/p/disruptor/ )

The disruptor is just a very efficient event loop. It doesn't prevent you from blocking the handling thread.

True, if you do blocking stuff in the handler instead of in the worker threads.

Re: A Solution to CPU-intensive Tasks in IO Loops

#25

Post by oconnore » Mon, Feb 06, 2012, 6:00 PM UTC

bkirwi wrote: post #16

oconnore wrote: post #14

Earlier quoted context omitted.

> presumed performance is very much the thing that makes the complexity worth it. Presumed performance/complexity of what? That isn't even a comprehensible English sentence, never mind a well thought out rebuttal to the OP.

It seems clear to me that's he's talking about the performance / complexity of the algorithm that the article was about? There was significant discussion of the performance in the article, but the original commenter didn't have anything to contribute but a sassy comment. I'd be interested in hearing more about why he/she disagrees with the author's arguments, but frankly, a one-line criticism deserves a one line rebu…

But there are two algorithms in context here, and the more complex/efficient one is the OS preemptive scheduler. It then appears that 'willvarfar' is agreeing with 'ot' in a sentence that is structured as a critique. It confused me...

> Also -- I'm not sure the comparison is accurate. Preemptive multitasking involves suspending the running process, while the author's suggestion involves emptying the queue behind the blocking process... or am I misunderstanding?

I think the author's suggestion is to transparently spawn new threads when the event queue becomes blocked by a long running process. As soon as you do this, you lose a major advantage of the event loop in the first place -- namely that you don't have to worry about concurrency control because event handlers are atomic. I don't think (and it doesn't grep) he mentions anything about emptying the queue; why would that ever be a good idea?

Re: A Solution to CPU-intensive Tasks in IO Loops

#26

Post by willvarfar » Mon, Feb 06, 2012, 7:29 PM UTC

bkirwi wrote: post #16

oconnore wrote: post #14

Earlier quoted context omitted.

> presumed performance is very much the thing that makes the complexity worth it. Presumed performance/complexity of what? That isn't even a comprehensible English sentence, never mind a well thought out rebuttal to the OP.

It seems clear to me that's he's talking about the performance / complexity of the algorithm that the article was about? There was significant discussion of the performance in the article, but the original commenter didn't have anything to contribute but a sassy comment. I'd be interested in hearing more about why he/she disagrees with the author's arguments, but frankly, a one-line criticism deserves a one line rebu…

spot on :)