Ugh tired brain syndrome - off by an order of magnitude!

100 MB/sec over 40 GB/sec = 1/400th of the memory bandwidth. So a modern machine with 40 GB/sec of memory bandwidth and 1 gigabit ethernet has 1/80th of the network IO of the old PC.

Consider 10 mbit ethernet on an early PC. It could push maybe 500K/sec. Figure a 4.77 Mhz 8088 had about 2500 K/sec of memory bandwidth. Ratio - 1/5.

Now imagine if the common ethernet on your machine was 1/5th of the Memory bandwidth. Take a PC with 40 GB/sec of memory bandwidth. Imagine having 8 GB/sec over ethernet at a reasonable cost.

Imagine the things we would be doing if we had that. Instead we commonly have 100 MB/sec. 1/40th of the memory bandwidth.

Just think for a minute about how different things would be with a network that pushed 8 GB/sec. You could swap over the network, you could do all kinds of cool things.

So while I really *like* ethernet I wish we hadn't slipped so far down the slippery road of lousy I/O/

If it does become sentient or at least passes the turing test, will you kill it? If you do, and it passed the turing test you are killing something that can at worst simulate intelligence at the level of a human.

Do you give it a natural method of decay like a human brain? If you don't do you just keep it running forever or flip the switch.

A good engineer / programmer understands fundamental things that matter far more than the latest language trends, if you are dealing with non-trivial problems.

If you could magically have Knuth, Dijkstra or Hoare look at a hard problem do you think they'd do a lousy job? If you do, you need to go back and read the stuff those guys have written.

Having a soup of buzzwords is fine, but it is worth less than nothing if they don't understand how to look at a problem and determine the dependencies of the problem. The best case for the geewhiz person will be that they by-chance end up using a pattern someone else came up with that maps. The worst case is you get something that looks nice and seems nice but is neither correct or robust.

Concurrency didn't start with cheap desktop mult-icore microprocessors. Dijkstra wrote his stuff about Sempaphores in the mid sixties.

There's a hell of a lot to be said for sitting in a quiet place and thinking through a problem perhaps with a pencil and piece of paper. If you've never worked on a problem that required you to do that, then either your problems have been easy or you're an unsung genius.

It may NOT be the case at your company, but over the years I've seen total stupidity at many companies with regards to engineering budgets or lack thereof.

Consider an engineer - let's say that hypothetical engineer is paid $100K a year. They talk to their manager - and say 'Hey I if I could spend $20K I could quadruple the number of build,test,debug cycles I get done in a day - they currently take 5 hours on average. 4 hours of that is building and running the test suite.

Many managers would say 'You're out of your damn mind! - $20K that's a car!'. They are, of course, killing the company. Even if that engineer is out by a factor of two, and they can only double the number of cycles they get done in a day - you just basically turned down buying another 'magical engineer' who somehow instantly knew the problem-space, knew the details of the environment, and was instantly efficient for $20K.

The managers are ALSO forgetting is that many studies have shown that ruthlessly limiting the number of people working on a project is one way to improve chances of success. This was directly shown in spades to IBM when Control Data built the 6600 - the total CDC team was 34 people including the janitor.

A wise manager would say - 'Let's talk this through', and check the engineers thinking. Maybe ask another engineer. If it looks good then go for it. Even if it lets the engineer turn those 5 hour cycles into 4 hour cycles - it's paid for itself.

There Ain't No Such Thing As A Free Lunch.

Or Beer, as in Heinlein's example in "The Moon Is A Harsh Mistress". Understanding that would be a great thing for every kid to learn. I'm surprised by how many otherwise intelligent adults appear tongue-tied after rallying for some new subsidy when you just ask the simple question 'Fine, what will you cut to cover the cost?'

My brain nearly imploded once when a college educated friend said 'We should subsidize solar panels on houses' and I replied 'Groovy - So what would you cut?', and they said 'Nothing - Just print more money'

Good on you for doing the exercise! I agree dhrystone isn't perfect but I wanted a benchmark thats relatively easy to find numbers for a machine.

For the 286 there's about a 10:1 ratio. Your ratio is 230:1. So let's just scale it and see what that would have looked like: 4000 dhrystone mips / 230 ~= 17 K/sec.

So effectively your I/O to compute ratio of your laptop is about that of a 286/16 with a floppy disk.

The bad news is it gets *worse* than your laptop with typical x86 servers. I/O doesn't scale like compute. Take a x86 box people might throw VM's on. It's probably got worse I/O versus compute than your laptop or a 286/16 with a floppy.

Totally right about latency too. That's an even more depressing ratio.

What's worse is that they don't understand floating point.

They don't understand that in floating point you can totally have a situation where:

d = a + b + c != d= b + c + a

Try finding out yourself. Ask some kids some simple questions to the new kids:

Try asking them:
What's the memory bandwidth of that x86 desktop or laptop roughly? Special points if they break out cache.
Ask them how many dhrystone MIPS (very roughly) that uP has.
Ask them the ratio of the main system memory bandwidth to MIPS.
Ask them the ratio of the main system memory bandwidth to the I/O storage they have.

They just never get exposed to this stuff. They just have no reference. Now ask them to compare them even to a regular 286 era ISA bus PC: I'll even give you some numbers.

286/16 ~ 4K dhrystone MIPS on a good day
Disk (40 MB IDE on ISA) ~ 400K/sec

It's great to see these things still around. They are really fun to read. I actually am a bit of an atari 8 bit fan with some 8 bits I still use occasionally for fun.

They weren't always. Some model 360's were pretty decent. The CDC 6600 while called a 'super computer' nowadays was really a 'Large Computer'. It was a mainframe. The problem with mainframes is the same problem with every computer out there. The latency wall. There were only a few companies that really pushed the physics. That stuff has stopped at the 'system' level to a large degree. You see a few companies playing with the interconnect topology but it's not really pushing the physics stuff.

If you take the ratio of compute to I/O of any typical modern server it's horrendously bad. To anyone out there who thinks their x86 rocks - a few simple questions:

1) What's the ratio of memory bandwidth at various levels to I/O bandwidth? Compare that to a Mainframe from the 60's.
2) How long on a typical server would it take to swap out all of memory? You can use SSD if you want.

Hint) You will find 2) is many seconds to minutes for a decent sized x86 server even with SSD's. That IBM mainframe could maybe swap out all its memory in less than a second or a second or two.

Take someones description of their cloud computing service and compare it to the concept of the computing utility - like the MULTICS people talked about, it's pretty damn similar.

Some idiots will claim it's not - that they can get to their data! Which is total garbage because while technically they might be able to get to their data, it sucks to empty a swimming pool via a straw which is what the bandwidth of an internet connection is like when there's a tonne of data in the cloud.

So then they will say 'run your queries in the cloud', well that's awesome until the problems don't map efficiently to the topology the cloud vendor went for.

It's rarely required, until it is.

Back in the earlier days of micros it was loads of fun. BYTE was a great read. People wrote their own stuff on their own hardware. There were really fascinating choices in CPU's. Initially there were people using 2650's 8080's, 6502's, 6800's, LSI-11's, 1802's, 9900's. .

I can't remember the last time when someone actually said something outrageous like 'What architecture would be ideal'. Nowadays it's 'What software layer (implicitly running on x86 Linux boxes) should we use?'

The performance numbers people talk about are terrible too. Kids who just graduated think 100K interrupts per second is 'good!' on a multi Ghz multicore processor. They just have no context and don't understand how absolutely crappy that is and that even on an 8031 running at 11 Mhz with a /12 clock we could pull off > 20K interrupts per second in an ISR written in HLL!

Right and there are some big differences:

Mainframe CPU's tend to have far more error detection and correction. They have safeguards against errors in data shuffling and computation inside the CPU itself. Mainframes tend to offer robust job control, by the time you add decent job control of the level that mainframes offer your network of workstations/servers starts getting complicated
Mainframes tend to offer decent encryption and security.

Can you do all these things on a pile of VM's? Sure. Is it cheaper - maybe. Is it fun to manage - not particularly.

For the point about giving everyone access to all your stuff? Let's see the author prove his point by posting all his personal details, address age, credit card numbers, ssn, medical records, tax returns and let's see how that works out for them..