Re: How to develop a random number generation device

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:(

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.

One simple way to do that is to have a CPU
per process. It's going to happen.

This is exactly the path or perhaps even N CPUs per process, where N
=1.

For N<=4 full multiprocessing is fairly tractable and after that it
suddenly gets a lot harder. And I have know one multiprocessing
mainframe box where N=3 was perfect and the advertised upgrade to N=4
was a dogs dinner. Worth pointing out here that very few software
programs these days are that heavily CPU bound.

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.

Regards,
Martin Brown

.

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... prejudices and the resentment of a literate style in programming, ... campaign on some assertions and a Web page created by Programmer Dude ... they were proven on multiple operating ... systems, compilers and CPU architectures. ...
    (comp.programming)
  • Re: Cpp Considered Harmful
    ... > Where sophisticated means things like: makes multiple concurrent TCP ... intended concurrent programming with resource locking and synchronization. ... of the same executable image by different 'processes', ...
    (comp.lang.cpp)
  • Threads Without the Pain? ACM Queue Vol 3, No 9 2005-11-01
    ... wonder what comp.programming.threads has to say about State Threads, ... Much of today's software deals with multiple concurrent tasks. ... Different approaches to concurrent programming offer different ...
    (comp.programming.threads)
  • Re: Parallel Processing Progress
    ... were claims of difficulty with software & programming, ... FPGA is cheap and a workable solution with a standard language. ... Cost ratio of fast cpus vs many cheap cpus. ... efficiently on any number of processors without any code change. ...
    (sci.electronics.design)
  • Re: Lengthy merge code
    ... but I don't have the programming skills to work ... Perl would be difficult because of the multiple ... the chances are that the problem has nothing to do with memory. ... proprietary software package - I don't dare name it - and the merge ...
    (microsoft.public.word.mailmerge.fields)
Loading