Moore’s Law, SoC’s & Future Trends in Computing

Moore’s Law has continued inexorably driving the cost of computing down. It’s at the point now where folks are carrying around several thousand VAX 11/780’s in their pockets. I’m often surprised that *lots* of IT folks haven’t really spent ANY time thinking about where things are going… what will we see in twenty years time.

My personal views are that we are already in the midst of a new kind of a revolution in computing. The software-crisis occurred, not perhaps as ‘obviously’ catastrophically – but is writing ‘hard’ code any more easy? In some cases you could maybe say “Yes” – functional programming can help, but plenty of times you still need to think hard about what’s really going on – maybe now the dependencies are sorted out by your framework or language, but the efficiency may be terrible… Software quality doesn’t seem great, in fact I’d argue we are all still wading through the software-crises today.

We have two trends here: First Moore’s law keeps making computing cheaper and cheaper and secondly software continues to be hard to write, maybe it’s a tiny bit easier than before – better software tools, but for non-trivial problems a great development environment is surely nice but doesn’t make the thinking about algorithms, parallelism and locking all that much easier than it was 20 years ago.

Back in 1977 John Backus had something to say about programming
Backus on von neumann style What he writes here is more than thirty-five years old, and still damn relevant.

Now, what does that have to do with SoC’s and computing you may ask? I’d argue SoC’s will eventually make computing so cheap as to make it ubiquitous. Everyone, your competitors and yourself will have piles of compute. So here’s the question – in a world of ubiquitous compute, where it’s super-cheap what can you use to diffentiate yourself from a competitor?

I’d argue that software technology is where this will come from. The team that can write a better program, a better set of programs will be at a distinct advantage. You can’t hide things forever – there’s a price, and there’s huge dividends to be paid for really making the leap and applying a function-level programming style (not functional, function-level) like Backus talks about.

That’s a software technology that if mastered is significantly ahead of the standard way of doing things, and could pay huge dividends. It’s no silver bullet, but it’s a step in the right direction. In-fact it’s embracing that ‘there are no silver bullets’. It’s damn hard frankly to transition to this way of thinking. The silver bullets are frankeworks that try to hide the nastiness from you, at some point you just can’t hide it. At some point you need to “suck it up” and face the reality of the situation. FP does that.

DEFENDER – Classic Coinop

Back in the 80’s your FNE shovelled a fair amount of his GDP into arcade games. Even watching attract modes AMAZING graphics was fun.

Now what makes a good Coinop? That’s a really good question, and there’s probably someone, somewhere who has a matrix and has tried analyzing this objectively, but the truth is it’s subjective.

Some people hate DEFENDER because they just can’t handle the controls. I mean the first time you shovelled a coin into the coinbox of Defender it’s not like you would last very long. Just think about the controls compared to something like Pac-Man. One stick, no fire buttons, just move the stick, dodge the ghosts until they change color, eat the fruit, eat the dots.

Now some people might say that watching a really good Pac-Man operator is fun, but I’d argue watching a really good Defender operator in action is HEAPS BETTER THAN PAC-MAN.

The thing is both of them are still lots of fun. Defender I could spend hours/days on if I had the time. It’s that good of a game, and it sure as hell ain’t easy to master.

Defender ran on a nice 8-bit, the 6809 at 1 Mhz.

Defende information from

Williams also made Joust which is another favorite of mine.

What are your favorite coinops from the 80’s?

The Cloud, Dinosaurs and Security

Many industry pundits, and cloud vendors! would love you to believe that anyone who hasn’t migrated their infrastructure to the cloud is a dinosaur munching vegetation (or other dinosaurs) while the extinction-event rolls around the globe towards them.

If you believe the “Cloudies” they will tell you *Everything* should be in their wonderful Omnipotent magical pool of computing resources. Don’t let reality slow you down, just get your stuff into the Cloud.

So let’s say you are being asked to look at putting YOUR software stack in the cloud… what questions should you ask? It turns out you can just ask the normal, sane ones anyone would ask.

What’s the security model like? Who do you need to trust? Are your customers OK with you storing their data in the amorphous cloud? The cloud vendor may respond – ‘Sure, we use heavy duty crypto!”; That’s wonderful, but if your code is running in a VM then what’s to stop someone with access to the VM just snooping everything? Hint – Nothing!

What’s the bandwidth and latency like of the I/O subsystem? Hint – It probably sucks compared to a decently engineered real-iron stack. The truth of the matter is “There ain’t no such thing as a free lunch!” — TANSTAAFL applies. For any code-base that does serious I/O and serious processing – it will cost you big bucks.

Now let’s ask some questions around ‘the future’. SOC’s are here today. There’s more compute in your handset than in a desktop a decade ago – and flash storage keeps getting cheaper and cheaper. Now the cloud folks like to say – “hooray we can pack more of those into each rack and offer more compute and more IO cheaper!” Hooray…

…and yet there’s this thing called LATENCY and locality of reference. The *best* place to process data is right where you collected it – where the latencies are lowest if at all possible. Network bandwidth is pitiful compared to the bandwidth between your processor and memory, or even the bandwidth between the processor and well engineered flash storage. Plus SOC’s are cheap and getting cheaper and cheaper.

Why would you upload something over a slow (and power sucking) network link to the cloud when you can just process it locally, and store it locally on an encrypted device? Why wouldn’t everyone just carry around their data-set and processing requirements in their pocket? Access? So multiple people can use that data? – That’s not really a valid argument – because if the requirement was that then OF-COURSE it was uploaded to a place everyone can access it.

For security? OK maybe – but really why wouldn’t you upload encrypted transactional snapshots to the cloud – or to your own “private cloud” that consists of you and maybe your family members? Why rely on some mega corporation?

The cloud people will say ‘You get so much more though – we can scale compute!” that-s not really always true if latency matters. Your app has to be latency tolerant and your stack needs to handle that. There’s a cost to that kind of architecture – linear scaling is great when it works, but you need to do decent dependency analysis up-front, and many-many-many people don’t even understand how to do that at all…

There are good uses for the cloud, and some services make sense in the cloud, but it’s not perfect for everyone, and don’t ever let someone calling you a dinosaur convince you of anything if they can’t answer a few basic back of envelope engineering questions like ‘How many IOP’s can I get from your virtual storage?’, What kind of interconnect is there and what’s it’s latency and bandwidth?

Hipsters and Programming

I’ve met more than a few hipsters who are also programmers.  They seem remarkably keen on Javascript in general, and are excited to write everything in Javascript.  If you ask them what languages they know it’s usually something like Javascript, Ruby, Python.  Anyone seeing a pattern here?

Now there’s nothing intrinsically wrong with Javascript, Ruby or Python.  You can write an abomination in pretty much any language.  Some languages make it *easier* to produce your software version of a Lovecraftian horror story, but you can, if you try hard enough, actually write something decent.

Not that it’s easy sometimes – more on that another time.  The main point is that if you are writing in a language because it’s trendy, because it’s hip, then you are like the kid who watches Ninja movies and thinks they are now a Ninja.  Do you want to be a software Ninja?  If you answered ‘YES!’ – Then you just FAILED the first test.  Software Ninja’s suck.  Anyone who ever calls themselves a “Software Ninja!” is guaranteed to suck.  Do you think Donald Knuth (You know who he is right?) or Bill Joy would ever call themselves a Software Ninja?

An earlier version of this post was published ona a prior Tumblr blog – NOP CITY.

Complexity, or what does Itanium, the iAPX432 and the i860 all have in common?

The obvious thing of course is Intel… but there’s something else.

Each of these architectures in their own respective time was a titanic failure.   Each failed in different ways, but there’s a common thread to what went wrong…

When Intel announced the iAPX-432 “Micro-Mainframe” it sounded pretty amazing.  The 432 was a 32 bit microprocessor in the days of mostly 8 bit chips. Sure there were some 16 bit microprocessors out there; actually there were some half-way-decent 16 bit MPU’s, but they didn’t have marketing worth a 4 bitter… but that’s for another day.  The 432 supported all kinds of amazing things… They had multiprocessor support. built in. fault-tolerance, built in multitasking, built in. memory-protection. You guess it, you got it. What they didn’t have was respectable performance…

Now there are arguments about why the performance sucked so badly – some claimed it was the compilers – using the ‘high level’ instructions when low-level instructions would have sufficed… which is a bit of a strange argument really considering the iAPX-432 was a super-CISC. The 432 was CISC on steroids, so arguing that the super-CISC used instructions that were too CISCy is a bit like marketing your new wide body jet-liner as the future of jet-liners, and then saying the reason it sucks in fuel efficiency is because it’s a wide body.

Another common argument for why it performed so poorly, was it was far too complex. Whereas other MPU’s often fit in a single device, the iAPX-432 was a multiple chip ‘set’. Other arguments were that it was rushed to market before the engineers had enough time to add the small extra tweaks that would have fixed the performance issues – not least of which was related to caching. But anyway, the market decided and it didn’t decide for the 432.

Fast forward a decade and out comes the i860. Super fast RISC, paper benchmarks are amazing, the i860 can pump MFLOPS like a Cray. I mean it was such a leap forward on paper that operating Systems like NT were ported to it… people thought it would take over. I mean it was called the i860 (10 x x86 – N10 – NT…)…

Except it sucked too.  Not all the time, sometimes it was great, but it couldn’t handle things like interrupts. The pipelines were so complicated and so long that if anything screwed up perfect flow, the performance took a nosedive. There are reports of i860’s taking twenty thousand instructions on an interrupt. Just think about that.  So anyway, what happened to the i860 – well you just answered that question… The market decided against it.. It got used in some specialized apps, with hand-tuned code, and there – it performed great… but as a general purpose replacement for x86 it fell flat on it’s face.

Fast forward a decade – and it’s Itanium. Again, like the i860, on paper is a winner.  It’s such a winner it convinces some companies to give up the CPU game.  HP did – not surprisingly, as it did come from HP,  but it did the same for SGI. They stopped rolling MIPS and MIPS were not bad at all at CPU design.  Alpha was killed but we can discuss what happened there LATER…

Anyway, the Itanium has been a disaster. It’s been more successful than the iAPX 432, and probably more successful than the i860, but remember this was i64. This was to be the replacement for 32 bit x86. Are you running an Itanium box? If you are, good for you – hopefully you are at least using VMS on it… But the chances are that you aren’t reading this from an Itanium box (P.s. Send me a note if you ARE on an itanium box)…

Chances are, that you are using AMD64. But you are running on an Intel chip, oh sorry, you are using EMT-64. No make that Intel-64 – oh hell let’s just call it x86-64… but you can thank AMD for forcing Intel to come out with a 64 bit x86 extension, because AMD did, and they started eating Intels lunch. What was AMD64? It wasn’t like Itanium… it was a 64 bit extension to x86-32. Just like x86-32 (the 386) was a 32 bit extension to the 16 bit 8086…

Get to a point, get to a point. OK I hear you. The point is that complexity is often the enemy to what’s good. Even when the complexity promises great things (on paper) you need to check them out in reality. If it sounds too good to be true, it probably is.

None of this means Intel makes bad chips.  Far from it.  They make some of the best chips on the planet, the netbook I’m typing this on right-now is using one of them.

Have other companies made stinkers?  Oh – you bet.  Try reading up on the K5.  Sounded great in theory.  Take the 29K a decently respected AMD RISC chip and tie an x86 instruction decoder on the front-end.  Sounded great.  The real world performance was nowhere near what was touted, and did I mention it had serious thermal issues?

Or in other words. Only fools believe the marketing copy.


An earlier version of this post was published on a prior Tumblr blog – NOPCITY

The coming digital apocalypse

Among other things, the keyboard cowboy writing things has had a life debating (seriously) about a wide variety of doom & gloom situations.  Whether it’s discussing the  halving-thickness of that VAX/VMS pile of books behind you, or the effect of super volcanoes or gamma ray bursts there’s one subject that is guaranteed to give anyone who has half-a-clue-about-it the ‘We’re all doomed demeanor’.  That’s called “The Singularity”.

Or to put it another way, it’s the point-in-time when us humans aren’t really able to keep up with what’s going on. The idea of the singularity isn’t hard.  Draw an exponential curve on a napkin, label the Y access ‘knowledge’ and the X access time.  Eventually on that curve you hit a point where  it’s impossible to keep up.  You just can’t keep up – you can’t think fast enough. Now that may sound absurd, but it really is happening.  Even if you don’t believe it’s happening – it is happening.  Why can I say that so surely?  Because unless civilization collapses, we will hit a point where even the average cellphone can simulate a humans mind.  It will by definition have more neurons (or simulated neurons), and they will be much much faster. If that sounds like a far-out sci-fi idea, then you have NOT been paying attention to what Moore’s law has done.

Let me give you a simple example. 1981.  A cheap home computer was the ZX-81.  Some would say it was more of a toy than a computer,  it had 1K of RAM , and that included the screen buffer, but it was a computer…  You might know it better as the Timex Sinclair 1000.

So here’s the thing.  For the same cost as the ZX-81 you could now buy a laptop with 4 gigabytes of RAM, a nice bright LED back-lit display, an optical drive, and did I mention a dual core CPU that is unfathomably faster than it.

Oh yes, it comes with a half terabyte disk too.  Now let’s compare that to the ZX-81 from 1981.




Storage – Cassette tape at a god-awful slow bit-rate.

Clockspeed 3.5 Mhz 8 bit Z80, but the screen ate lots of that. Now:


Noname laptop

RAM-4194344 KB ROM- a few megs of ROM enough to use the HDD…

HDD – 500 GB.  Oops let me spell that out.  five-hundred thousand megabytes.  Or five hundred million kilo-bytes (OK a little less than KB due to SI unit junk but you get the idea).

CPU – Two 64 bit processors each running at ~2000 Mhz and way better IPC.  You know we used to call it CPI – cycles per instruction.  Now we call it instructions per cycle… that should give you the drift

That’s from now, 2014.  The ZX-81 was 1981.   Almost 35 years ago.  So now, add 35 years and if the growth rate is the same – well, let’s just say it’s more compute than is fathomable. It’s so fast you could probably emulate a humans neurons in a javascript emulator of an emulator of an emulator.

What I’m saying here is that even without some amazing ‘AI breakthrough’ we will get there.  The machines will be so fast and have so many cycles and be able to search so many different data sets that they will give a good answer to most questions with mostly brute-force versus ‘insightful programming’. Why does this scare me and and so many other people?  Because if you actually believe that this is likely, and that the machine will be this much more intelligent than any human, then all bets go out the door.  It is irresponsible to think we could even reason about what that kind of an intelligence might reason about.  It doesn’t matter if it isn’t ‘really thinking’ either, if it’s a close enough facsimile to it, and it beats humans routinely (easily) at problem solving.

For all you know it will decide to wipe out the entire human race and make a giant dead-meat pyramid of human corpses as art.  Really – as art.  It doesn’t sound like art to me, it probably doesn’t sound like art to you – but that’s the point I’m making.  We can’t even reason about what that pile of silicon (or graphene or whatever else) might think is art.

Still not convinced – OK let’s just say that the machine is 1.5 times as smart as a human.  What happens when it decides (or you tell it) to make the next version of itself?  By definition, it’s building something better than you could as a human.  Then it releases that machine.  Let’s say the first one is a dud, so it tries again and again, but eventually MK II number 7 is a success and is 5 x as powerful as it was.

Now it’s 7.5 times as smart as a human, and it decides to design the new machine.  We can never catch up, so who knows what it will do. None of this even covers nano-bots – or nanites, that’s a whole different post.