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.
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 <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in <11pla49cjbncqm5kso6h6pmil38tt60...@4ax.com>:
>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
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 a7yvm109gf...@netzero.com wrote in <a69efd5e-4046-42cd-a909-eb4edf5db...@m3g2000hsc.googlegroups.com>:
>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.
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 a7yvm109gf...@netzero.com wrote in <8a2dc199-2210-4056-b837-fbc9f193d...@k7g2000hsd.googlegroups.com>:
>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.
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.
> 1. A new programming language, accompanied with a new way of teaching > programming.
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.
> 2. A new OS, which uses a nanokernel approach and wastes processors in > the name of reliability.
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.
> 3. Ultimately, a new multicore cpu architecture that exerts much more > hardware control over the things that programmers tend to screw up.
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.
> The current generations of languages, programmers, methods, and OSs > are relics, and they don't scale.
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.
> It will take a long time to fix things, because the current computer > culture - academics, programmers, cpu makers, Microsoft - will fight > for its survival.
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.
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.
>> 1. A new programming language, accompanied with a new way of teaching >> programming.
>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.
>> 2. A new OS, which uses a nanokernel approach and wastes processors in >> the name of reliability.
>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.
>> 3. Ultimately, a new multicore cpu architecture that exerts much more >> hardware control over the things that programmers tend to screw up.
>You mean like enforcing bounds checking on array and pointer access?
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.
>> It will take a long time to fix things, because the current computer >> culture - academics, programmers, cpu makers, Microsoft - will fight >> for its survival.
>Academics are a lot more sanguine about things than you seem to think.
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.
>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.
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.
