A chip too far? Where is your solution Mr Larkin?

1. A new programming language, accompanied with a new way of teaching programming.
2. A new OS, which uses a nanokernel approach and wastes processors in the name of reliability.
3. Ultimately, a new multicore cpu architecture that exerts much more hardware control over the things that programmers tend to screw up.

The current generations of languages, programmers, methods, and OSs are relics, and they don't scale.

It will take a long time to fix things, because the current computer culture - academics, programmers, cpu makers, Microsoft - will fight for its survival.

John

FTA "Then the software brains figured out how to turn all that processing power into faster operations and cool new functions."

Uh, what? Usually the software monkeys squander every last bit of hardware performance in the name of their laziness.

I mean you know what blows my mind? In the era of GHz processors and terabyte drives, why do we even have a "file->save" menu? Just save the freaking thing as we go along and keep a journaling file system.

On a sunny day (Tue, 19 Aug 2008 08:24:56 -0700) it happened John Larkin wrote in :

No, I can only very partly agree. Starting at the end, it now seems survival is for those who solve this problem first, in the widest sense. I would expect MS and others to know this, they are investing into research into this.

As a second point, 'maybe' just 'maybe' the multi core approach is the fundamentally wrong one. In an other thread FPGA's rising over DSP's diminish is mentions. Sure, with so many gates, and reconfigurable logic, some parts of sequential programs are better done in FPGA then smearing out over many cores, my personal experience with this is fast DES.

As mentioned, in (3), I did mention this earlier in an other posting, it is very difficult to use a CPU for each thread, and, as the article on CNN says, it is very difficult to get 9 women to give birth to one child in 1 month. I had an old boss, he would ask, 'How many more men do you need to do this within 2 weeks (as opposed to 3 month). I had lengthy discussions about communication between workers being a factor that could slow things down (as bottleneck). Sure, the joke goes: How many Belgians does it take to screw in a light bulb?', and the answer is: 5, 1 to hold the bulb, and 4 to turn the ceiling. But something there says it all. Perhaps when we use FPGA as supplement to a sequential processor (where extra processors can be configured in hardware too), then we can gain speed. I fail to see an universal way to slice any sequential problem to a parallel one. But _if_ you do, you can become world famous, extremely rich, so I'd say: Call MS or IBM :-)

So, blaming it all on 'programmers' is a bit silly (with all respect). the first programs were hardwired anyways, blame it on the hardware guys...

The best way to optimise for speed, is to see where the system spends it time, and tackle that bottleneck, if must be put a FPGA there, not add yet an other core, with its communication issues.

On a sunny day (Tue, 19 Aug 2008 08:27:52 -0700 (PDT)) it happened snipped-for-privacy@netzero.com wrote in :

Not fair, some parts of for example mpeg decode were written and rewritten in asm for speed for x86. There are software developpers who know what counts.

On a sunny day (Tue, 19 Aug 2008 08:30:03 -0700 (PDT)) it happened snipped-for-privacy@netzero.com wrote in :

mm, many programs like editors (of text, video, other stuff) do automatic write backs every so many seconds, or can be instructed to do so. In the programs I write _any_ user action that changes config, updates the config files, so after a crash you are back where you were. Even this newsreader does that, and firefox does it too.

That might help a bit. But there are a lot of very important legacy applications already out there. Like it or not we are tied into the existing applications codebase.

Can't fault the idea of keeping the Ring0 protected kernel as small as possible, or giving users the least privileges needed to do their job. But wasting performance for reliablity though is never going to fly - not least because most times it would not have the desired effect.

Hardware enforced memory protection for threads on a timesliced CPU can be made every bit as reliable as giving each one a physical CPU just a SMOP.

You mean like enforcing bounds checking on array and pointer access? I am all in favour of that, current CPUs have some of the right instructions but most production code has these safety nets optimised out in final build. Performance, whizzy graphics and even mythical faster benchmark figures sell kit - sadly reliablity doesn't(*).

(*) except for certain high availability mission or saftey critical kit.

If you don't remember your history you are doomed to repeat the same mistakes. Do you not remember the Transputer and its lovely little parallel processing language Occam. Scaled really well but they went bust - probably because they were manufacturing in the UK.

I might even be tempted to agree with you that the time is now right for someone to try this route again. I predict lots of fun and games for desktops with Vista and N>4 x86 compatible CPU cores.

Academics are a lot more sanguine about things than you seem to think. Most that I know believe the market gets what the market deserves. If people will buy vacuous buggy software with a cute interface that crashes when the wind changes direction then manufacturers will oblige.

Regards, Martin Brown

..

The early computer were necessarily programmed directly in machine code. The development of the early assemblers created a priesthood of a few experts that knew how to get the most out of the assemblers because they had experience getting hte machines to work with machine code. Eventually, those experts were able to write "higher-level" programming languages (notably COBOL and FORTRAN) that appeared as laguage understood by a broader spectrum of users, and worked because they underlying code was written by the assembler/machine code experts.

It seems to me that the multicore effort is attempting to take existing high-level languages and graft them onto the new hardware without first growing a cadre of expert users who know how to get the most out of the processors at the elemental level.

Pointers have to be the first thing to go. And of course array bounds should be checked, but all that can do is crash a program, which was going to crash sooner or later anyhow.

We are programming antique hardware in antique languages.

The ideal programming language would be wordy, plodding, not a bit exciting - sort of like Cobol - and no fun for research or for coding. That's the point: we have to make programming not fun if we want it to be reliable. Modern programming attracts the wrong kind of people to teach and do reliable programming.

When later versions of programs are slower and buggier, "the market" will oblige by not upgrading. We have seen this here a few times - a new rev is worse than the current one - so we drop support and stick with the one that works. Or we go to a free equivalent, like PDF utilities or LT Spice, and dump the bloatware.

John

I think it's a fundamental problem of the U.S. (and perhaps the rest of the world as well). We've allowed ourselves to be hung up on _growth_, if earnings/whatever don't grow every quarter we think we're not succeeding... it's not satisfactory to have a steady profit... so we sink/sell companies willy-nilly.

Same with software... if there's not a periodic "upgrade" it must be a failure.

I've taken to asking for detailed reports on software improvements before I spend my "maintenance" money. Not surprisingly, I've not recently spent any money ;-)

...Jim Thompson

Faster chips (and the concomitant bloatware) have been making slower computers since CP/M. ;-)

Cheers! Rich

Anybody remember The Connection Machine?

ISTR the reason it never found any real applications is that nobody knew how to program it.

Cheers! Rich

That's Bill Gate's major innovation--his solution to the question "How can you make loads of money off a product that never breaks, and never wears out?"

His answer is a combination of making sure the thing you buy is defective, and or deficient, or of making it obsolete, and parcelling out improvements (and even fixes) as slowly as possible.

Hence changing Word and Excel's formats, changing the OS to break old applications, shipping bugs, security issues, etc.

It just hit me yesterday--I've oft noted the harm he's done selling lousy software, but I just realized...he breaks our tools. My superb DOS file compare, search routine, editor, directory utility, parallel port-operated interfaces, truly nifty ISA A/D board... broken.

The advance of civilization has been one of building tool upon tool, hand tools ==> machines ==> machine tools ==> better machines ==> better tools. Same for software. And he breaks ours.

Thanks Bill.

James Arthur

On a sunny day (Tue, 19 Aug 2008 18:41:38 GMT) it happened Rich Grise wrote in :

In my view, that professor, if he is real, must at one point be willing to say: YOU CANNOT ALWAYS CONVERT SEQUENTIAL CODE TO PARALLEL CODE. But if he is into his research grant, OK, that may take a while.

As a programmer I say: Find where the sequential program is spending [most of] it's time. Try to optimise that code area, use hardware if need be, FPGA is the perfect solution here. So we have then mother boards with on the fly programmable logic as part of the programs that run on it. Maybe the obstacle here is, that for both IBM and Intel, they have cores. More cores is simple for them, 'If I had a hammer, I would hammer in the morning, hammer in the evening, all over this land'. This land is my land .... Now this land WAS their land. They have an IP problem, have to team up with Altera, or Xilinx, others, and combine their forces to write a compiler that finds the time consuming part of the sequential code, checks the available hardware resources as in FPGA, and converts that time critical part to gates, unfolding as many loops as possible. Use gates (not the person ;-) ) as we now use memory resources. Now here is a solution that can WORK. I am no professor, but this can be realized. HELLO IBM? HELLO INTEL? Intel is lead by a sales druid, IBM too? Somebody should try that way.

Pointers are OK provided you can only trash your own memory space. Anything else and you should get squashed flat.

Speak for yourself. I program in the language that best fits the problem (or is dictated by the clients requirements). Sometimes both. The fastest way to develop really tricky algorithms is in a language where human errors and typos are mostly caught at compile time. The final version is then translated back into C (which is mostly what people seem to want). ISTR NAGLIB used this approach a very long time ago (when FORTRAN was the main language of choice for scientific computing).

I wish that a more robust language had won the language wars, but it is too late now to cry over spilt milk.

In the sense that the compiler protects the average user from themselves I have to agree with you. But you actually do need really good visualisation skills and a logical mathematical mind to produce reliable code. Good intentions are insufficient.

Even that isn't clear. I do have some sympathy for your argument that hardware engineers in general tend to be better at thinking through the details, unit testing and planning. But nobody wants to pay for truly reliable software when the law of diminishing returns sets in. You might want to take a look at Donald Knuths literate programming model used for TeX. It has one of the lowest bug rates of any program ever written.

And hardware implementation isn't really as robust as you like to pretend with your rose tinted glasses on. Various CPUs have had nasty bugs the worst one costing Intel a cool $0.5B (depsite being largely irrelevant for most users). I had a specimen dodgy PII - it even made a tiny difference for one regression test.

So far no-one has produced a full CPU with a formal proof of correctness. Components have been stratin with the Cyrix x87 copro. ISTR some bad liability lawsuits resulted from the Viper CPU debacle.

Not enough to change the market dynamics - at least so far.

XL2007 is a case in point. Slower, unreliable and in places downright flakey. I would not even recommend it to my worst enemy, but some of my clients insist on having the latest and greatest despite being given clear advice to avoid. XL2003 is a local optimum, as was NT3.51 - even a chaotic process can sometimes produce real gems...

Intel at least has had the good sense not to deploy Vista. YMMV

I notice that you quietly editted out all references to the ill fated Transputer hardware and its naturally parallel Occam language. That was a serious early attempt to adopt your world model. It failed big time.

Regards, Martin Brown

John

So, a hundred years from now, everybody will still be programming in C++? Writing billion-line programs with millions of bugs?

Something to look forward to.

John

Rumour has it Cyberdyne Systems has successfully applied this technology to their artificial intellegence project, apparently they really expect it to go over with a bang...

H.

Content-Transfer-Encoding: 8Bit

Jan Panteltje wrote:

The website above presents a problem.

The following website contains the solution:

Leaving aside the fact that the software brains actually *used up* all that processing power with *slower* operations and cool new functions, why do we need so many cool new functions? Sure, there are some cases (gaming, for example) where the bigger and newer programs actually deliver more, but why the need for more and more processing cycles to surf the web, send emails, and do word processing?

Consider this comparison of Microsoft Windows "Recommended System requirements" (and we all know that Windows really needs a lot more than the minimum to run fast and well):

Windows version Processor Memory Hard disk Windows 95 25 MHz 8 MB 50 MB Windows 98 66 MHz 24 MB 140?255 MB Windows Me 150 MHz 32 MB 320 MB Windows 2000 Server 133 MHz 64 MB 1 GB Windows XP 300 MHz 128 MB 1.5 GB Windows Vista 1 GHz 1 GB 15 GB

Source:

Are the new features in Vista really worth 40 times more cycles, 125 times more ram and 300 times more hard disk? Is Vista 40 times better? Am I 40 times more productive?

Why should a business have to keep buying new PCs, to support new bloatware when most of the workers are trying to complete the same tasks?

Meanwhile, I am running the latest version of Slackware Linux on a box that has:

...and it runs just fine -- in fact it runs faster than some of the older versions of Slackware Linux do. Yet I installed that same version of Slackware Linux on a 8-processor Xeon box with 4GB of RAM and a 1TB RAID array, and it worked great there as well.

Also see: