Re: How to develop a random number generation device

On Tue, 18 Sep 2007 07:05:25 -0700, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

On Sep 18, 2:30 pm, MooseFET <kensm...@xxxxxxxxx> wrote:
On Sep 17, 7:55 pm, John Larkin<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

[....]

Programmers have pretty much proven that they cannot write bug-free
large systems.

In every other area, humans make mistakes and yet we seem surprised
that programmers do too.

In most other areas of endeavour small tolerance errors do not so
often lead to disaster. Boolean logic is less forgiving. And fence
post errors which even the best of us are inclined to make are very
hard to spot. You see what you intended to write and not what is
actually there. Walkthroughs and static analysis tools can find these
latent faults if budget permits.

Some practitioners, Donald Knuth for instance have managed to produce
virtually bug free non-trivial systems (TeX). OTOH the current
business paradigm is ship it and be damned. You can always sell
upgrades later. Excel 2007 is a pretty good current example of a
product shipped way before it was ready. Even Excel MVPs won't defend
it.

Unless there's some serious breakthrough - which is
really prohibited by the culture

I think there really is a fundamental limitation that makes it such
that the programming effort becomes infinite to make a bug free large
system. We do seem to be able to make bug free small systems,
however.

Software programming hasn't really had the true transition to a hard
engineering discipline yet. There hasn't been enough standardisation
of reliable component software parts for sale off the shelf equivalent
in complexity to electronic ICs that really do what they say on the
tin and do it well.

By comparison thanks to Whitworth & Co mechanical engineering has
standardised nuts and bolts out of a huge arbitrary parameter space.
Nobody these days would make their own nuts and bolts from scratch
with randomly chosen pitch, depth and diameter. Alas they still do in
software:(

Compare a software system to an FPGA. Both are complex, full of state
machines (implicit or explicit!), both are usually programmed in a
heirarichal language (C++ or VHDL) that has a library of available
modules, but the FPGAs rarely have bugs that get to the field, whereas
most software rarely is ever fully debugged.

So, computers should use more hardware and less software to manage
resources. In fact, the "OS kernal" of my multiple-CPU chip could be
entirely hardware. Should be, in fact.



This suggests a rephrasing of your point as "it is better to use
multiple simple systems" connected in some way rather than just
calling it multiple cores or CPUs.

How about calling them modules. Re-usable components with a clearly
defined and documented external interface that do a particular job
extremely well. NAGLIB, the IJG JPEG library or FFTW are good examples
although arguably in some cases the external user interface is more
than a bit opaque.

- the answer is to have the hardware,
which people *do* routinely get right, take over most of the functions
that an OS now performs.

Very complex hardware is likely to have the same problems as very
complex software. We need to link of ways to use many copies of a
much simpler hardware.

And the very complex hardware is invariably designed using software
tools. The problem is not that it is impossible to make reliable
software. The problem is that no-one wants to pay for it.

In hardware chip design the cost of fabricating a batch of total junk
is sufficiently high and painful that the suits will usually allow
sufficient time for testing before putting a new design into full
production. Not so for software where upgrade CDs and internet
downloads are seen as dirt cheap.

Yes. The bug level is proportional to the ease of making revisions.
That's why programmers type rapidly and debug, literally, forever.


Most CPUs in PCs these days are vastly overpowered for the normal day
to day work. Only a few power users and gamers really push them hard.

Yes. So let's use that horespower to buy reliability.

John


.

Loading