Let's all just agree to use Perl. It's just dynamic, functional, OOPy C isn't it?
J/K. I think this is an interesting problem in that its a sandbox for allocation and GC in pretty much any dynamic interpreter's implementation. My qualm is that it would be "easy" to tune for the test. Consider the difference between dynamic blocks of a small but fixed size, getting alloc'd/freed in an asynchronous way (a network stack?) versus a pool of variable byte length strings getting shuffled around (a key/value store?). Those are simple, but drastically different, strategies for your heap. There won't be a "best" answer besides the limits of your problem domain.
By my understanding of the event, a wall of mud and ash buried the city 10+ feet deep almost instantly. Fossil were found with food in their mouths. What timeline was this "simulation" built on?
I think that many "servers" today aren't going to benefit though from the level of optimization that you're talking about. Network bandwidth is at least an order of magnitude slower than memory and PCI throughput. For all but the most heavyweight computational tasks (ie. gaming, finance, scientific computing, etc.) this kind of multiplexing optimization is very helpful. If you're needing to get that kind of performance, you would userspace map off the NIC.
With how fast modern processors (CPUs and GPUs) are, whats much more important nowadays is not stalling on the flow from the NIC. The solution of the original author seems to me like a very simple fix for the old naive paradigm of state machine switching off from a single thread.
I think you might be (impressively) too close to the metal, and guilty of premature optimization. For example, a simple database application would benefit much more from keeping the slow I/O bottlenecks flowing than from the compute multiplexing.
Read the whole thing. There are some well developed points near the end, but i feel many of these premises are fundamentally flawed. For example, that mobile devices will gain keyboards and become our primary computers.
Mobile is for content consumption, workstations are for content creation. Missing that key point leads many of the points here astray. Solving the disparity is one of the major open areas in HCI research.
I'm really impressed with this (now that it has loaded).
I do have a qualm, hopefully taken as constructive criticism and not nit-picking:
The cornea and the aqueous humor are going to have different IORs and because this doesn't appear to be modeled, the iris is unrealistically distorted at sharp angles.
Otherwise, this is amazingly, disturbingly realistic. Good job.
I think this article was very Very enlightening about what is going on with the "Web" at large. It's refreshing to see some numbers backing up what is going on. I work as an amateurish FOSS developer and a network engineer by day. These numbers tell me something i already knew: the desktop is now longer the primary way to browse the web. I have a smarty-phone and occasionally use it to look things up, but the "normal" web on mobile is atrocious. Looks like the days of ads and pop-ups filling the margins of pages might be coming to an end. Maybe we can start catering to the users looking for information instead of trying to work everyone over for advertising revenue.
My site browses on mobile just fine, and it's fully un-optimized wordpress.
I am very disappointed to see this posted where, when, and how it is. Comparing Linux to Mac is like comparing apples to Lamborghinis. I can get an apple, cheaply if not for totally for free, locally, anywhere at any time. Lamborghinis are very expensive, both in up-front cost and maintenance, and truly don't perform relative to the cost. What i hear is someone moaning about how much effort it takes to choose the best kind of apple, Gala? Granny Smith? Sour Green? Golden? Macintosh? I'd rather have an apple than Apple.
J/K. I think this is an interesting problem in that its a sandbox for allocation and GC in pretty much any dynamic interpreter's implementation. My qualm is that it would be "easy" to tune for the test. Consider the difference between dynamic blocks of a small but fixed size, getting alloc'd/freed in an asynchronous way (a network stack?) versus a pool of variable byte length strings getting shuffled around (a key/value store?). Those are simple, but drastically different, strategies for your heap. There won't be a "best" answer besides the limits of your problem domain.