How to write code which minimizes page faults?

[Keith Thompson]

Unless, of course, it is impossible to make an error. Consider an
assembly language with one-bit opcodes, NOOP and HALT, which can
be arranged in any order. (A HALT opcode is implied if you run
off the end of the program.) Of course, you can't do anything
USEFUL with it, either. All those ugly things that cause errors
like pointers, variables, arithmetic, loops, etc. are prohibited.

Or, equally useful, my own language "99".

<http://www.99-bottles-of-beer.net/language-99-804.html>

The real challenge would be to design a *useful* language in which
errors, or at least some significant class of errors, are impossible.
Such a language might be possible, but I wouldn't expect it to have C
as one of its direct ancestors.

 

[akarl]

Unless, of course, it is impossible to make an error. Consider an
assembly language with one-bit opcodes, NOOP and HALT, which can
be arranged in any order. (A HALT opcode is implied if you run
off the end of the program.) Of course, you can't do anything
USEFUL with it, either. All those ugly things that cause errors
like pointers, variables, arithmetic, loops, etc. are prohibited.

(You replied to the wrong message; *Malcolm* said: "All programming
languages are unsafe...")

 

[CBFalconer]

.... snip ...

The real challenge would be to design a *useful* language in which
errors, or at least some significant class of errors, are impossible.
Such a language might be possible, but I wouldn't expect it to have C
as one of its direct ancestors.

To my mind we have had that language for many years. Pascal. When
able to call C routines virtually all limitations disappear. And
for the last measure of flexibility, we allow C routines to call
assembly routines.

 

[Charles Richmond]

To my mind we have had that language for many years. Pascal. When
able to call C routines virtually all limitations disappear. And
for the last measure of flexibility, we allow C routines to call
assembly routines.

"It's often been said that C gives you all the power and
flexibility of assembly language combined with all the
readability and maintainability of assembly language."

--
+----------------------------------------------------------------+
| Charles and Francis Richmond It is moral cowardice to leave |
| undone what one perceives right |
| richmond at plano dot net to do. -- Confucius |
+----------------------------------------------------------------+

 

[Malcolm]

A safe language is a language where a large class of errors are detected
when they occur and not when data gets corrupted. Such a language provides
e.g. array bounds checking, garbage collection and restricted pointers.

A compiler can potentially pick it up when a programmer says "this plane's
altitude is a grabage value". What it can never pick up is when the
programmer inadvertently says "let's do a controlled flight into terrain".
The second class of error is far more dangerous. Many language introduce
complications to reduce the chance of the first type of error, but thereby
increase the chance of error type two.

 

[CBFalconer]

A compiler can potentially pick it up when a programmer says "this
plane's altitude is a grabage value". What it can never pick up is
when the programmer inadvertently says "let's do a controlled
flight into terrain". The second class of error is far more
dangerous. Many language introduce complications to reduce the
chance of the first type of error, but thereby increase the chance
of error type two.

Your last sentence is in error. You are really differentiating
between compile time and run time checks, IMO.

The problem is that most languages, apart from Ada and Pascal, are
not closely typed. In both of those a strict limit can be set on
values in a given object, and conclusions drawn from that at
compile time. Thus if an object is limited to the range 0..4, the
result of squaring that value is guaranteed to fit into an object
limited to 0..16. This allows run time checks to be very
efficient, since things that can be proven at compile time need not
be checked at all, and the compiler can detect these cases.

C is also complicated by the abandoned use of pointers, making many
things inherently non-checkable. You just don't get latitude to do
anything at all without penalty.

 

[Lawrence Kirby]

Use of object oriented programming should result it keeping related
code and data in close proximity.

Doubtful. OO code tends to use dynamic allocation more. This tends to make
it slower, larger with less memory reuse. Dynamic memory datastructures
(the heap or whatever you choose to call it) are not likely to be kept
close to or interleaved with code. This is particularly nasty in languages
like Java where all full objects are dynamically allocated, perhaps not so
bad in C++.

This would improve the locality
of reference for code as well as data.

It is common for code and data to have separate caches at least for to
level caches on high performance processors. It is generally better to
keep code and data separated.

Other than that, you should not worry about this issue. Do not
compromise readability and maintainability of code to achieve higher
locality of reference.

Locality of reference is more about design of datastructures and
algorithms than anything else. The langauge and programming paradigm you
use does have an effect on this.

Lawrence