NetKernel News Volume 6 Issue 2

February 20th 2015

• Repository Updates
• NKEE Install Jar Update
• Saving Energy with Contextual Caching

Repository Updates

We have released an update to the NKEE 5.2.1 distribution download (available from the NetKernel portal).

We have modified the encrypted module license verification to be significantly more tolerant. It now copes with dynamically assigned hostnames (such as seen on OSX and some cloud platforms). It also detects and manages multiple license files simultaneously. Hopefully this update makes everyone's life easier - you hate licenses, we hate licenses, but this should make things a lot smoother.

Due to the chicken and egg problem - this low-level update can't be applied through Apposite. So if you want to get a more chilled out and relaxed version of NKEE then please download a new copy and you're all set.

While we were at it, we made another small change to the distributions (both NKSE and NKEE) and now include the second generation HDS module out of the box. So there should be no need to pull it down from Apposite and from this point we can begin to implement the NK admin tools with HDS2.

By now you are probably aware that the way that we treat computational state in ROC/NK is "different".

This week, Tony has written a great article that uses some simple real world analogies to demonstrate why the NetKernel contextual cache is unique and extremely relevant to the quest for computational energy efficiency...

http://durablescope.blogspot.co.uk/2015/02/saving-energy-with-contextual-caching.html

Of course the corollary to saving energy is that you are not having to perform CPU operations - which is another way of saying ROC taps into a new level of computational performance.

As my small contribution this week, the way I sometimes explain ROC's contextual caching is as follows:

For the history of computer science we have created ever more refined computational engines that optimize the computational cost of moving from state A to state B (for example, optimising the call of methodB() from methodA()).

We have optimized processor architectures, compilers, linkers and JIT optimisation of the runtime... And every one of these optimisations has been about making the distance between A and B as small as possible...

What Tony is describing, and NetKernel has been demonstrating for over a decade, is that very frequently, the shortest route from A to B ... is to know that you are already at B!

Cache or The Realization

You know I can't resist inventing new words and, of course, I have issues with the word "caching". It has far too much baggage and is not really expressive enough to explain what we're doing with computational state in NetKernel.

One way to describe it is that we've created an algorithm (the ROC abstraction) which delivers systemmic memoization.

But "memoization" has baggage too - since it assumes that referential integrity cannot be asserted outside of the frame of reference of a given function in a given language.

As Tony describes, the NetKernel ROC cache shows that referential integrity and relevant contextual computational state can be determined even in a dynamic multi-dimensional state space!

The term I prefer for the NetKernel/ROC cache is "The Realization".

That is, it is the concrete realized computational state that occurs as you compute by reifying abstract resources.

Or if you prefer, it is the instantaneously relevant reality of the computational system...