I have been reading some of Alan Turings works, specifically some of his work for the NPL in the late 40's and early 50's, before he went to Manchester in frustration with the NPL's lack of progress with his ideas.
One of the ideas Turing was pressing at the time was to do as much as he could in software, don't jump to hardware solutions; which at the time fixed the functionality of the machine to a single purpose; instead he wanted a general computing device he could put to any uses he desired.
Today the average programmer, hobbyist or indeed employed software worker, such as myself, don't have the opportunity to define new hardware for a bespoke task, indeed the machines we are driving are far more powerful than Turing ever imagined and we can do as Turing suggested, we can write software to get around an issue.
You need encryption, why pay to plug in a dongle doing this, when the processor you have is equipped to do the task for you, indeed some processors even have encryption instructions and powerful parallelism built into assist in such work!
So today's lesson is, take on board Turing's ideas, do in software as much as you can, even if you want to later move to real hardware emulate your idea now. Here's a very good example:
nVidia's emulation lab is an extreme example, however, it is indicative of the kind of problems we are meeting today as older engineers are coming away from dedicated hardware devices (because their machines were too slow in the 1990's) and we have today's extremely powerful machines right there at our finger tips.
Why does this exist?
Last week I set about looking at a quite old system (circa 2008 it was last attended to) it contains a message passing system, which allows passing of messages (events if you will) between producers in any process to consumers in any other process subscribed to the service. It did this with a windows service driver, which called down into a USB dongle to queue the message.
The consumers then polled the USB device (round robin style) to determine if the next message was for that consumer... You might imagine this was extremely slow.
It was also very complex, the code within the USB dongles was not mutable; being set in silicon; and the consumers could end up locked out of the service queue by a message being present for a consumer which was not able to consume the message.
This clearly needed replacing.... So, I had to look at it, a single afternoon, it was just extremely complex inside, so one had to take a step back, don't look at the contents of the code, look at the API, the functions being used....
The producer code relies on just three functions and the consumer relied on a thread safe queue which was woken up from a spin wait to call the registered consuming function... Not rocket science.
I set about writing new code with a very simple UDP server and clients, taking the message in, converting it to XML and posting it to the loopback IP Address of the master UDP listening port which then sent it out to the listening consumers on their loopback IP and port number.
Voila, in an afternoon, I had replaced five years (ish) of complex, hard to maintain code, with a working prototype of a solution. And it dropped straight into place. The dedicated, slow, old, hardware could be unplugged and the system just carried on as it always had.
The customer for this product is delighted to see it running faster, and the overhead of the hardware costs being removed. All by simply doing in software something which was being offloaded to hardware in yester-year.
No comments:
Post a Comment