From: Dr. Adrian Wrigley on
On Thu, 27 Oct 2005 19:28:36 +0000, Martin Dowie wrote:


> More error related than predictability I hope! Or is there some
> dangerous non-determinism associated with access types I haven't come
> across yet?! :-)

I did meet a case of non-determinism exposed through access types...

My stock trading software originally used very large arrays
of pricing data (around 1GB of data). This worked fine for many
months. One day, I decided to add a level of redirection, using
a large array of access values. After that, the program would
fail mysteriously every few months. But why?

It slowly became apparent that the memory was getting
single-bit errors. I remember from the early days of DRAM that
alpha particles in packaging could cause soft errors, and
researched the current reliability of DRAM. It seems that
packaging radiation is now negligable, but cosmic ray strikes
are still an issue (depending on altitude). Calculating the
rate of soft errors expected, I found that with a gigabyte
of non-ECC memory, soft errors might occur about every week.
I immediately switched to ECC and the problem vanished.

Anyone with a well specced PC should be aware that memory bits
will be flipping spontaneously every few days, unless ECC is used.
This means that large linked data structures are highly susceptible
to failure. Of course non-linked data also gets errors, but
these will often disappear, and are slightly less sensitive.
It becomes a question of how errors show up. With copious
use of access types, failures are often catastophic. Without,
they tend to be more insideous. Make your choice! Or get ECC!
--
Adrian


Quote:
"IBM has performed the most comprehensive characterization of soft error
rates in DRAM subsystems, collecting data on roughly 800 memory devices
over a 10-year period. These studies were performed at various altitudes,
including below sea level in underground caves, since the cosmic ray flux
increases with altitude. Using this data, a senior engineer for IBM
Microelectronics predicted that 256 Mbytes of memory would average one
soft error per month due to cosmic rays (EE Times, 6/22/98)."
From: Jeffrey R. Carter on
Robert A Duff wrote:

> An abstract syntax tree for Ada will have upwards of a hundred different
> tagged types (or variants, if you go the variant record route). And you
> need access types all over the place, because these things are highly
> recursive.

Sounds as if compilers need access types much more than many other kinds of
programs.

> You and I might have to wait a long time for that, given that I have to
> make a living. I can do so making compilers and other tools, but since
> the Ada 9X project, nobody seems interested in paying me to do language
> design. Sigh. For now, it's a hobby.

Sounds like a fun hobby. I've thought about trying to design a language (which I
would call NINA: NINA Is Not Ada), but every time someone posts a "why not add
this feature" question and I think about what it would entail, LLs like you come
up with several factors I hadn't thought of. So it seems I shouldn't be in the
language design business anytime soon.

> I don't even know what to call it. Not "Duff", for sure. ;-)

OK. I'll look forward to hearing more about Not "Duff" :)

> Just saying "You hardly ever need pointers in Ada" is misleading,
> IMHO.

Perhaps. To a certain extent, I intend it to provoke, so the person thinks about
the possibility that Ada is significantly different from C, and he's not going
to learn Ada by trying to do things the same way as in C.

--
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83
From: Jeffrey R. Carter on
Dr. Adrian Wrigley wrote:

> My stock trading software originally used very large arrays
> of pricing data (around 1GB of data). This worked fine for many
> months. One day, I decided to add a level of redirection, using
> a large array of access values. After that, the program would
> fail mysteriously every few months. But why?

So your stack was ECC memory, but your heap was not?

--
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83
From: Simon Wright on
David <kdgreen(a)fastmail.fm.au> writes:

> I develop larg'ish mission-critical systems in Ada and cannot use
> pointers, dynamic memory allocation, tasks, variants, recursion,
> etc. etc. You can always find a way to not use pointers as long as
> you stick to Ada (not interfacing C/C++). Memory mapped hardware can
> be accessed using an expression like "for x'address use at <hardware
> address>". You can declare one variable on top of another the same
> way.
>
> Trying to get code safety-certified with pointers is very difficult
> to impossible. Code that doesn't use pointers is invariably simpler
> and more reliable but it may require more thought depending upon
> mind-set.

Do the rules allow unchecked conversion?

Using "for x'address use" to "declare one variable on top of another"
is a way of trying to pretend to the auditor that you aren't doing
unchecked conversion ... much safer to do UC, at least the compiler
has a chance to tell you that (for instance) the things concerned
aren't the same size!
From: Robert A Duff on
"Jeffrey R. Carter" <spam(a)spam.com> writes:

> Dr. Adrian Wrigley wrote:
>
> > My stock trading software originally used very large arrays
> > of pricing data (around 1GB of data). This worked fine for many
> > months. One day, I decided to add a level of redirection, using
> > a large array of access values. After that, the program would
> > fail mysteriously every few months. But why?
>
> So your stack was ECC memory, but your heap was not?

That's hard to believe. Dr. Wrigley said the hardware failures turned
from "insideous" to "catastophic" when he changed some sort of Things to
pointers-to-Things. I take that to mean, he got wrong answers before,
and crashes after. Is that right, Dr. Wrigley?

Either way, the lesson should be "use reliable hardware"!

- Bob