|
Prev: Survey on the Effects of Organizational Culture on Software Productivity
Next: Eclipse Ada Support - FYI
From: Dr. Adrian Wrigley on 28 Oct 2005 07:57 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 28 Oct 2005 17:24 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 28 Oct 2005 17:26 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 29 Oct 2005 08:25 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 30 Oct 2005 17:26
"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 |