| |||||||||||||
Cool new Free softwareCool new Free softwarePosted Dec 19, 2012 12:20 UTC (Wed) by man_ls (subscriber, #15091)In reply to: Cool new Free software by juliank Parent article: Status.net service to phase out, replaced by pump.io Yes, it's trendy. Its pervasive async event model is really interesting once you get inside its twisted head. Our friends in the functional community should appreciate the return of functional programming, with a vengeance: in node, everything is a callback. I remember reading the tortured syntax that Paul Graham had to write to enable some kind of pseudo-multiprocessing in Lisp; in node, it is all there and nicely managed for you.
(Log in to post comments)
Cool new Free software Posted Dec 19, 2012 14:40 UTC (Wed) by ms (subscriber, #41272) [Link]
It's pretty difficult to consider that code for NodeJS that does any substantial amount of IO can be described by the word "nice" (though I realise I'm slightly rewording what you wrote).
Callbacks lead to horrible staircases of code which tend to look fugly, and infect all APIs everywhere. Things like promises make for slightly nicer looking code, and give you more choices from an API POV, but are still not brilliant. IMHO, the "fact" is that for nice looking code, which is intuitive and readable, you want to be able to write blocking code.
I just don't understand why people think that callback-based programming is necessary for good performance. Most sane languages with a good RTS and green threads will be able to match the performance of NodeJS for anything involving IO. And almost certainly lead to better looking code. The popularity of NodeJS I find most perplexing. Maybe most other languages do not have good RTS or green threads.
Cool new Free software Posted Dec 19, 2012 15:53 UTC (Wed) by man_ls (subscriber, #15091) [Link] Apparently, declarative languages with threads and RTS and whatever are much harder to exploit fully than node.js, even with its tortuous callback model. I don't know if V8 does magic or what; it would be nice if someone more knowledgeable could enlighten us.Anyway it is possible to write code that hides some of this complexity, avoiding anonymous functions for most of the work. The functional programming model and the object oriented stuff can be made to play together nicely with some effort. Since a few years ago I have wondered why the kernel doesn't do something similar with an application's event loop: instead of the app having to call and wait for some time (or, god forgive us, poll all the time), the kernel should drop its privileges and give control to the app's process directly. Similar to Java event handlers, I guess, but without the JVM overhead. Async everywhere!
Cool new Free software Posted Dec 19, 2012 16:13 UTC (Wed) by nix (subscriber, #2304) [Link] the kernel should drop its privileges and give control to the app's process directlyYou mean, exactly what select(), poll() et al do?
Cool new Free software Posted Dec 19, 2012 16:29 UTC (Wed) by man_ls (subscriber, #15091) [Link] I am not sure how select() and poll() work, but let me explain it a little bit better. With the classic model, a running process says that it wants to access e.g. the keyboard and then blocks on it: the whole process is frozen and its state is maintained. When an event comes, the kernel has to wake it up, thaw its state, and then let it run again where it left off.In a callback model, a process registers to access to the keyboard, its state is preserved (in javascript as a few closures), and the process dies. When an event comes a new process is created, the closures are recovered and off we go. The new process may even be based on the kernel process instead of the original, although in this hand-waving scenario I am not sure if this is at all feasible. Note that the new process can only access those variables that it is actually going to use, not the whole address space.
Cool new Free software Posted Dec 19, 2012 16:52 UTC (Wed) by nix (subscriber, #2304) [Link]
There is no such thing as 'a kernel process' in this sense: a process is not 'frozen' when it's select()ing, it's blocking *in the kernel*. When an event comes, the kernel wakes up and returns to userspace: no 'thawing' is necessary. select() is just a system call that blocks in the kernel, just like, say, read() often does (and just as lots of other syscalls do).
Creating a new process for every single event seems sure to be far more expensive than just a privilege transition out of kernel mode. My system here can manage about five or ten thousand forks per second, but it can manage well over a million context switches into and out of kernel mode per second.
(As for a process being 'based on' a kernel process, the level of your confusion regarding how processes work in Unix is seemingly so great that I can't even imagine what you intend this to mean. Your last line suggests that you expect it to have a whole new address space of its own, which makes the thing a process-creation-level of difficulty rather than a thread-creation-level, and requires among other things a TLB flush. Expensive, expensive...)
Cool new Free software Posted Dec 19, 2012 17:27 UTC (Wed) by man_ls (subscriber, #15091) [Link] I was just translating poorly what I imagine that node.js does, to kernel concepts (which for me is admittedly like translating French into Italian). Precisely the idea was to avoid creating a new address space. Instead of having a new address space, just use the kernel's (knowing that the process will not access what it shouldn't).
Cool new Free software Posted Dec 19, 2012 19:42 UTC (Wed) by nix (subscriber, #2304) [Link]
Yeah. That's exactly what select(), poll(), and other blocking syscalls do now, and have done since Unix was invented (well, OK, they weren't around then, but read() was, and it did just the same).
Cool new Free software Posted Dec 19, 2012 19:47 UTC (Wed) by man_ls (subscriber, #15091) [Link] Way to go then :) Thanks for your patience.
Cool new Free software Posted Dec 19, 2012 16:53 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Creating a new short-lived process for every mouse movement, joystick waggle, keystroke, and network packet sounds like the sort of thing that you need to have designed your kernel for from day one if it's to work remotely well.
Cool new Free software Posted Dec 19, 2012 17:31 UTC (Wed) by man_ls (subscriber, #15091) [Link] Yes, probably, but nix above says that his system can manage 10k fork()s per second, and I doubt there are that many user events. Also, I think a "softer" version of fork() should be used which does not create a new address space. If at all possible, it would be like the reverse of a micro-kernel: a macro-kernel which invokes stuff normally reserved to user space.To leave the hand-waving space, such a scheme might be possible in the OpenWebDevice or Boot2Gecko, where there is nothing between the kernel and the javascript VM.
Cool new Free software Posted Dec 19, 2012 19:48 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh, there certainly can be 10k or more user events per second. Even ignoring the extreme case of network cards (10GbE cards can generate so many packets that you have only a clock tick or so to process each byte), mice can easily generate a few thousand events per second, and eye trackers will probably be even worse. I don't really want my CPU pegged because I waved my mouse around the screen -- not unless it's really got work to do, that is. Processing the mouse events is not work. (Note that if you're running X on a uniprocessor system this probably involves lots of context switches between multiple distinct processes, but even that is many many times faster than process creation.)
The softer version of fork() you refer to is called thread creation. It is faster -- I can generate a few tens of thousands of threads a second on this system -- but still not anywhere near as fast as context switching. You are still throwing performance away for, as far as I can tell, no benefit.
Worse yet -- if you're receiving a stream of events from some input device, they are almost certainly related in some way, and you almost always want to process them in the same process, or at least in related processes. Kicking off a new process for each event seems likely to lead to cursing from developers as they have to marshal the things back together again before they can process them. End result: a slower system, annoyed developers, more complex and buggy code, and... uh... no benefit, as far as I can see. What benefit is all this supposed to bring? Is it just 'more processes -> more isolation -> always necessarily better'? 'cos I used to think like that, and it just isn't so.
Cool new Free software Posted Dec 19, 2012 20:46 UTC (Wed) by man_ls (subscriber, #15091) [Link] Of course not, spawning a new process for every event is not a good idea. I did not explain myself clearly and got confused in the meantime. Allow me to reboot the thread.The thing is that an event should only do what it is supposed to do, and nothing else. If the result of a mouse movement is that a counter is updated, then let the kernel do it, and not bother my own process; when my process needs to read the counter it will do that. If the mouse pointer is moved and I want to paint a cool shadow, then ideally I would let the kernel know and the kernel will paint the cool shadow. Many things work like that now; it would be great if it was the default mechanism to answer user events. Look at it as dtrace on steroids, if you want. For a long task (such as a menu selection), then by all means create a process and let it deal with the event. Otherwise, store the new value and let me query it if and when I need it. Taken to the extreme I don't even need to have running processes except for background tasks.
Cool new Free software Posted Dec 19, 2012 22:50 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Please try doing some GUI programming, your ideas sound good in the abstract, but they fail when you get down to trying to use them
Taking your mouse example, some graphics cards do support hardware mouse cursors, where the card handles moving the mouse pointer.
however, such support really doesn't help much and is fading from use today because nowdays people want to change the shape of the cursor depending on what you are doing, etc.
you also have to think about how the program should know that it should look for an update to the mouse position. you don't want it spinning in a loop when nothing happens.
you also don't just want the current position of the mouse, you want to know it's path, and how fast it's moving (along with what buttons, if any are pressed during any part of this time)
There are pretty good reasons that systems do things the way they do. People have tried a LOT of things over the years, and what's in place may not be the perfect way to do things, but they've survived lots of competing ideas along the way.
Cool new Free software Posted Dec 19, 2012 23:03 UTC (Wed) by man_ls (subscriber, #15091) [Link] I know this is just another load of armchair OS design, and that it will not probably work in real life, but perhaps it is worth a try for somebody.Remember that this article refers to node.js. People have tried many things over the years in the web server arena, and around 2000 Apache was the clear market leader, with Microsoft a distant second. Apparently everything had been invented already. Then in 2002 a Russian guy decided to start development on a different model. Guess what: 10 years later it is the second web server in actives, ahead of Microsoft IIS. A year ago some crazy guys took Google's V8 engine and coded a web server around it, not in C or C++ but in... JavaScript. Preposterous. The result: the new web server everyone is talking about, capable of sustaining thousands of requests per second out of the box.
Cool new Free software Posted Dec 20, 2012 12:53 UTC (Thu) by njs (guest, #40338) [Link]
There is no "the kernel" versus "the user process" when it comes to doing things -- there is just a CPU running some code, with different memory access rules. Presumably the way you would tell the kernel about this cool shadow and how to draw it is that you would provide some shadow drawing machine code, and then when the mouse pointer moved the kernel would set up some registers etc. (a "context") and then run this machine code. But now we have just described exactly what user processes are...
When a user process blocks, it doesn't actually sit there as an entity taking up space. It gets converted into a callback attached to whatever event caused it to block.
Cool new Free software Posted Dec 20, 2012 18:37 UTC (Thu) by jch (guest, #51929) [Link]
> Most sane languages with a good RTS and green threads will be able to match the performance of NodeJS for anything involving IO.
We've done some benchmarks comparing threads with (machine-generated) event-driven code. Unsurprisingly enough, the results indicate that well implemented user-space cooperative ("green") threads are just as fast as event-driven code, but use vastly more memory. Surprisingly enough, Linux' NPTL is only some 50% slower, which I find very impressive.
See Figures 4 and 6 on pages 10 and 12 of http://www.pps.univ-paris-diderot.fr/~jch/research/cpc-20...
-- jch
Cool new Free software Posted Dec 20, 2012 20:21 UTC (Thu) by nix (subscriber, #2304) [Link]
NPTL was very well optimized, every bit polished until it was far more scalable than normal users would ever need on the assumption that high-end users would push even those limits. A superb piece of work all around.
Cool new Free software Posted Dec 20, 2012 20:57 UTC (Thu) by job (guest, #670) [Link]
What's interesting about it? It's even less interesting than Twisted or POE, which is at least ten years older.
But I would say that's probably what people like about it. It's not interesting, it works and it's easy to understand. Perhaps that makes for a large ecosystem one day. V8 certainly gives great performance. That's a great combination.
(Personally I think the callback spaghetti makes for hard to read code. Let's just say I wouldn't want to debug someone else's code. And this is from someone who actually likes Perl.)
|
|||||||||||||