View mode: basic / threaded / horizontal-split · Log in · Help
April 21, 2004
Re: D in scientific computing
"lacs" <lacs_member@pathlink.com> wrote in message
news:c66dls$1mt5$1@digitaldaemon.com...
> Add primitive-units-checking to D and a lot of people who work with
numbers will
> fall in love with D.

That would be neat. I wonder how far D's template would go without modifying
the language. See
http://www2.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf
for an approach in C++. There are probably lots and lots of ways to support
"units" depending on what the user wants and dimension checking would be a
useful start.
April 21, 2004
Re: D in scientific computing
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
news:c65fmi$2js$1@digitaldaemon.com...
> From what I have read so far, D really has the potential to close the gap
> between C++ and Fortran and in this way gain a huge share in the
> scientific/high-performance area of computing. Anyway, to have any chance
> to go there, much care has to be taken now.

I agree totally with you, which is why D has several features with a
numerics focus. If there are any I missed, I want to know about it.
April 21, 2004
noalias, restrict, and Fortran optimizations
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
news:c65fmi$2js$1@digitaldaemon.com...
> From what I have read so far, D really has the potential to close the gap
> between C++ and Fortran and in this way gain a huge share in the
> scientific/high-performance area of computing. Anyway, to have any chance
> to go there, much care has to be taken now.
>
> People unfamiliar with numeric programming often wonder why Fortran still
> has such a huge share among scientists. Many scientists still use
Fortran77
> and even those who have moved to Fortran95 only use it for its modern
> syntax, never touching the advanced concepts of it. And this is not only
> because they don't know better, but also because it is extremely hard to
> match the performance of Fortran77! (OK, 99% of the reason might actually
> be the lazyness to learn a different language and the existing code-base,
> but still people usual argue based on the superior performance of the
> language)

What Fortran has over C is the 'noalias' on function parameters which allows
for aggressive optimization. What I'm thinking of is writing the spec for D
functions so that parameters are always 'noalias' (for extern (C) functions
this would not apply).

What do you think?

For reference: http://www.lysator.liu.se/c/restrict.html
April 21, 2004
Re: noalias, restrict, and Fortran optimizations
Walter wrote:
> What Fortran has over C is the 'noalias' on function parameters which
> allows for aggressive optimization. What I'm thinking of is writing the
> spec for D functions so that parameters are always 'noalias' (for extern
> (C) functions this would not apply).
> 
> What do you think?
> 
> For reference: http://www.lysator.liu.se/c/restrict.html

I only have some basic knowledge about the "restrict" problem and would not
want to judge any detailed language design decisions.

Anyhow, the problem of both, the Fortran- as well as the
C-"restrict"-solution, that I see is, that in both cases, you "demand" that
pointers are not aliased, without being able to check it.

Of course, it is not possible to check this in every case at compile time
(if it were possible, C compilers would not have a problem), but maybe, we
can at least identify a class of situations where it is possible? Or,
alternatively enforce nonaliasing parameters via preconditions, so it is
checked in debugging mode?

For plain pointers it rather hard to check for illegal aliasing, since you
never know how large the are is that is not allowed to overlap, but
pointers are rarely used in D anyway.

Object references on the other hand are far easier to check: objects cannot
overlap, so two references are either equal or noalias. If you want to
allow the compiler to optimize a routine for nonaliased arguments, just put
in a precondition prohibiting references to identical objects.

For arrays, the matter gets more tricky, but again, arrays have enough
semantics that I believe it should be possible to specify and check whether
to arrays or slices overlap in memory. The tricky question here is: are two
disjunct slices of the same array aliased? The simple way would be to say,
that two slices of the same array are always aliased (simple to check,
simple to specify, simple to enforce) The more powerful solution would
allow disjunct slices to be used as nonaliased objects. (Allowing stuff
like copying internal parts of arrays around with full optimization.)

So my uneducated suggestion would be:

* accept that pointers may always be aliased to anything and don't try to
optimize too much there.

* prohibit aliased object references by explicit preconditions/assertions

* check closely what "aliasing" means for arrays and slices and find a way
to prohibit this kind of aliasing in contracts as well.

The problem certainly is not trivial to solve, but looking at the time that
researchers have spent on working it out in C it certainly is worth some
more consideration in D...
April 21, 2004
Re: D in scientific computing
Is a neat idea, but I'm pretty sure, you can simply implement that in the
library with the language as it is now. A good language should not cover
everything, but it should be slim and still powerful enough to do
everything in the library.

lacs wrote:

> Add primitive-units-checking to D and a lot of people who work with
> numbers will fall in love with D. What is primitive-units-checking? It is
> something we miss in C++ or Java(I have never read a line of Fortran :$ ),
> that is being teach in physic 101 and that could have avoid a Nasa probe
> crash on Mars(not the digital one) few years ago(I dont remember the name
> of the probe sorry. It was a forgoten miles-kilometers convertion factor
> problems). Check the following code written in a fictive language and you
> will understand what was meant by primitive-units-checking
> float<meter>        distance = 100.0;
> float<second>       time     =   3.0;
> float<meter/second> speed1;
> float<second>       speed2;
> float<feet/second>  speed3;
> 
> speed1 = distance/time; // no error
> speed2 = distance/time; // generate compile-time error
> speed3 = distance/time; // ok only if the compiler knows the conversion
> 
> // factor between meters and foot because the
> //compiler can do the conversion for us automatically
> 
> As you migth have guessed, the notation float<meter> has nothing to do
> with c++ templates and wouldnt interfere with it since it can only be used
> with primitives. Notice that float<meter> still is a primitive. Of course,
> a lots of units are way more complex than meter/second in scientific
> equations. And its what would make primitive units checking a time-saving
> feature in D for scientific computing.
> 
> 
> newbie11234
April 21, 2004
Re: D in scientific computing
Norbert Nemec wrote:

> Hi there,
> 
> as you might have gathered from my previous posts, I am quite interested in
> numerical/scientific computing.
> 
> 
> Ciao,
> Nobbi

It would be nice to have classes for really big numbers inside phobos.
April 21, 2004
Re: noalias, restrict, and Fortran optimizations
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
news:c66quv$2fe5$1@digitaldaemon.com...
> Anyhow, the problem of both, the Fortran- as well as the
> C-"restrict"-solution, that I see is, that in both cases, you "demand"
that
> pointers are not aliased, without being able to check it.

Correct.

> Of course, it is not possible to check this in every case at compile time
> (if it were possible, C compilers would not have a problem),

Correct.

> but maybe, we
> can at least identify a class of situations where it is possible? Or,
> alternatively enforce nonaliasing parameters via preconditions, so it is
> checked in debugging mode?

This is a possibility.

> For plain pointers it rather hard to check for illegal aliasing, since you
> never know how large the are is that is not allowed to overlap, but
> pointers are rarely used in D anyway.

It might be reasonable to constrain the requirement to be just for arrays
and objects, not pointers.

> Object references on the other hand are far easier to check: objects
cannot
> overlap, so two references are either equal or noalias.

This is, unfortunately, not true when you get into interfaces. It's also
possible for pointers into class objects, as well as arrays referencing into
class objects.

> If you want to
> allow the compiler to optimize a routine for nonaliased arguments, just
put
> in a precondition prohibiting references to identical objects.

Historically, adding in special keywords for such optimizations has not
worked out well. That's why I was thinking of making it implicit for D
function parameters.

> For arrays, the matter gets more tricky, but again, arrays have enough
> semantics that I believe it should be possible to specify and check
whether
> to arrays or slices overlap in memory. The tricky question here is: are
two
> disjunct slices of the same array aliased? The simple way would be to say,
> that two slices of the same array are always aliased (simple to check,
> simple to specify, simple to enforce) The more powerful solution would
> allow disjunct slices to be used as nonaliased objects. (Allowing stuff
> like copying internal parts of arrays around with full optimization.)

Yes, it should be possible to have disjoint slices treated as noaliased.

> So my uneducated suggestion would be:
>
> * accept that pointers may always be aliased to anything and don't try to
> optimize too much there.

This is a good idea, but I'm concerned it may not be sufficient.

> * prohibit aliased object references by explicit preconditions/assertions

Having the compiler insert runtime checks for debug builds is a good idea.
Unfortunately, as you pointed out, adding runtime checks for aliased
pointers is impossible.

> * check closely what "aliasing" means for arrays and slices and find a way
> to prohibit this kind of aliasing in contracts as well.
>
> The problem certainly is not trivial to solve, but looking at the time
that
> researchers have spent on working it out in C it certainly is worth some
> more consideration in D...

Solving it is worthwhile, as it removes a major barrier to the Fortran crowd
being interested in upgrading to D. C/C++ failed to supplant Fortran largely
for this reason. C99's "restrict" keyword is an ugly kludge (and D users all
know how much I hate type modifiers <g>).
April 21, 2004
Re: D in scientific computing
I agree with that.

Want to write them?

"Stephan Wienczny" <wienczny@web.de> wrote in message
news:c66tm4$2k9o$1@digitaldaemon.com...
> Norbert Nemec wrote:
>
> > Hi there,
> >
> > as you might have gathered from my previous posts, I am quite interested in
> > numerical/scientific computing.
> >
> >
> > Ciao,
> > Nobbi
>
> It would be nice to have classes for really big numbers inside phobos.
April 21, 2004
Re: D in scientific computing
Matthew wrote:

> I agree with that.
> 
> Want to write them?
> 

> 
I actually started to months ago, but then wanted to wait until DTL 
finishes ;-)
April 21, 2004
Re: D in scientific computing
Stephan Wienczny wrote:

> Matthew wrote:
>
> I actually started to months ago, but then wanted to wait until DTL 
> finishes ;-)

Your quick. <g>

-- 
-Anderson: http://badmama.com.au/~anderson/
1 2 3 4
Top | Discussion index | About this forum | D home