|
NetKernel News Volume 2 Issue 17
February 25th 2011
What's new this week?
Catch up on last week's news here
Repository Updates
The following update is available in both the NKEE and NKSE repositories...
- layer0 1.53.1
- Update to the kernel properties loader to treat all properties as UTF-8. Adds a workaround for Java 5 which can only read properties resources as ISO-8859-1.
The following updates are available in the NKEE repository...
- nkee-installer 1.6.1
- Updated to write the etc/* configuration resources in UTF-8
- nkee-license-manager 1.5.1
- Fixes a bug in the licensee details form submission.
Monkey Reloaded
They let me out into the real world this week - hence the late delivery of this news letter. Its given me several things to think and write about for next week.
Making contact with the real world is a good thing, last weekend I got a ping from Jeff Rogers at Findlaw.com with some great observations of the consequences for caching of highly concurrent systems. It adds some valuable insight to last week's discussion so I hope he doesn't mind me quoting it in full...
While there are those who claim that "you have not experienced Shakespeare until you have read it in the original Klingon", my comment stays with the monkeys ... Requesting a single copy of shakespeare from the monkeys will take quite a bit of time (or quite a few monkeys), but once you have it requesting a second copy takes very little time, and since NK knows that it took quite a few monkey-months, it will hold on to it. However, what happens if you're putting on a production of hamlet, and every actor in the show asks the monkeys for their own copy at the same time? You now have 10 or 20 infinite hordes of monkeys on the job. (Which I'm aware is exactly the same size as one infinite horde, but that's beside the point) Worse, what if the the Bard does a minor rewrite (most people don't know that it was originally "To be, or not to be, that's what I'm wondering about.") Not only does the result need to be immediately scrapped, but the monkeys still have to finish up their work, not matter where they are on it. Like many of my comments, these concerns arise from real-world problems. I have a nontrivial processing job that can get requested many times, very often with subsequent requests coming in before the first has completed. (To make thing more interesting, the dependencies are not easily determined, since they reside on a different system, which means that the correct value is the last one computed, not necessarily the first. But I'll ignore that wrinkle for now.) With the straightforward implementation, the result is that the system is flooded with requests and starts running them all at the same time (overloading itself as well as the other systems it calls), only to discard most of what was computed. A first attempt is to use a throttle, restricting it to only a single job at a time, so that second and subsequent requests will get a cached response and bypass the processing step; but this results in choking the system too much, because the same accessor is used for many unrelated processing jobs. My solution was to create a delay accessor, where a request is not issued until some time after the last time it was requested. But I'm also curious what your approach to this would be. Cheers, J 
|
I sent him a quick first reply, but it was late on a Friday evening and the weekend was kicking off. So I thought I'd offer some more thoughts now...
As Jeff first tried, I think a throttle is the first best solution - since it can be used to hold back the horde of monkeys to allow the endpoint to produce a first representation. The problem is that in Jeff's situation there is an overloaded endpoint (more than one grammar interface to the same code) which means that the one service that is the hotspot cannot be throttled independently from the other logical services. (As a side topic, its generally "a good thing" to keep an endpoint simple and not compound the physical implementation - but I know very well myself that this is often pretty convenient).
In this case, the load requiring the resource is very large, but the life of that resource is limited by short-lived dependency relations. One approach that would ease some stress is to use the throttle but also to give the representation a transient timed expiry using one of the variants of CONSTANT expiry on the INKFResponse. Just remember that the constant value is an absolute time in milliseconds since 1970 - I made the mistake last weekend of forgetting it was not a relative time (like the DELTA expires I talked about on the HTTP caching two week ago).
However, using a throttle with an additional small timed expiry is effectively the same as Jeff's ultimate solution: to implement a software delay-line - a nice old school engineering solution, used in analogue and digital circuit designs.
Incidentally, its not modern and "social" not to have a user comment section at the bottom of these newsletters. But that's not because I don't value dialogue. Its just that writing these things takes up a good chunk of time and I would want to be able to do justice to the efforts of readers by responding to comments. Unfortunately I just don't have the time to monitor and reply to an open channel.
However Jeff has frequently taken the effort to send some detailed and thoughtful comments, I've not forgotten that I still owe him an article in reply to an email he sent just before Christmas on the considerations needed to select the different forms of pass-by-ref, pass-by-value and pass-by-request arguments. Anyway here's another old school idea: an occasional "correspondence" section for all you other budding Jeff's to get an airing? If you subscribe to the newsletter notification you know where to email me.
Fastest Possible Computer
Reading last week's article it occurred to me that I was being really conservative on the evolutionary possibilities of monkeys. Surely a universe of monkeys would reach a faster clock speed than 1kHz (assuming they type at one character per cycle). So giving the monkey some credit lets assume they evolve to have faster and faster clock rates - say that there's an evolutionary advantage to typing faster and faster: you pay peanuts, you get (faster) monkeys.
In quantum mechanics, you'll have heard of the Heisenberg uncertainty principle (HUP) - it basically says that when you try and measure something's position, you trade off your knowledge of its momentum (speed). The limit in the relation is Planck's constant. Well there's a lesser known form of the HUP - it says that Energy and time have the same uncertainty relation.
Planck realised that there are therefore boundary conditions on reality. There is a fundamental limit on how fast the physical world can change. Its called the Planck time and it is 10-43 seconds.
It follows that the fastest possible monkey would have a clock speed of 1043 Hz. That's one fast monkey (and would require a lot of peanuts).
Unfortunately even with a universe of Planck Monkeys we'll not get Hamlet. We'd need 10129,898 PMUAs (Planck Monkey Universe Ages - anyone for a new SI Unit for computation units? Incidentally a Planck Monkey Universe (PMU) does 1083 operations per second. Fast Forward: Intel CPU advertisement circa 2100, The new Intel Simeon with 10-62PMUs capabilitiy)
As a reality check, the fastest monkey so far is the Human. The Human brain "clock speed" is about 200Hz (thanks René!) but because of its massive parallelism it performs about 2x1016 operations† (neuron firings) per second which is about 10-67PMUs.
* Incidentally what do Intel do if quantum computing goes mainstream? If you offload all your processing to parallel universes you can no longer say "Intel Inside".
† Taken from this University of Alberta article, which seems like a credible source.
NetKernel West 2011
Don't monkey about - you need to grab your place at the conference. Its not long to April. Find out all about it here...
http://www.1060research.com/conference/NKWest2011/
Have a great weekend.
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.
NetKernel will ROC your world
 |