> 3) Fully async node js style with call backs I thought we were talking about concurrency. This model is single threaded.
Here is a very high performance web concurrency model used prevalently at big Internet shops I've worked at... a) one big async I/O "dumb spooler" (either on-machine, or as a remote proxy) --- this is basically offloading the work of buffering/spooling for slow-clients, so your workers can free up as fast as possible. Sometimes it does other http-connection related optimizations. b) one worker-thread per end-user request-handler, spawned 1-4x per core, depending on workload --- threads instead of async, because it's too easy to lock-up an async core and create a cascade failure for any contended resources (db locks, cursors, etc, etc). The spooler in (a) means this thread is finished as fast-as-possible and not dependent on the client accept rate. It finishes and moves onto new work before the spooler finishes. c) async I/O core per worker-thread, to overlap calls to backend-servers --- this avoids worker latency becoming an additive/serial combination of backend-calls without the overhead of a thread-stack per overlapping network RPC request. Sometimes this done with threads instead of async, because modern machines can handle a crapload of threads, especially if there are legacy synchronous/blocking network RPC libs. On Wed, Jul 31, 2013 at 8:44 AM, Jonathan S. Shapiro <[email protected]>wrote: > As to range checks, your point is well taken, but the effects are > pernicious when the consequences for inlining are concerned. For > CPU-intensive algorithms, it can easily make a 4x to 8x difference in > algorithm performance. In particular, it means that loop unrolling isn't > very helpful. > For the naive... What are the main issues with range checks, inlining, and unrolling? A value-type array can't change size, and can't disappear as long as you have a pointer to it. If it's a structured increment loop (1 to 10 by n), it seems easy to hoist the range check and inline/unroll. Though thinking about it, I see a tricky problem in that even if you try to hoist, if the range-check fails at the hoist, the semantics of typesafe loop iteration mean we still have to run the loop until we hit the bounds, and we have to throw a specific error for hitting the bounds, so the hoisted check didn't really help us. Plus, in non-fixed increment loops (e.g. binary-search), or array-index-dereferencing, it seems hard to eliminate the range-check. Did I miss anything?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
