Hello donkey,
The point is, that while C allows aliasing, FORTRAN doesn't.
This allows a FORTRAN compiler to make optimizations that a C compiler can't. Therefore, a FORTRAN compiler will generate better code in this case (assuming both compilers generate optimal code for their respective languages -- which I'm saying, isn't the same). It might be interesting to notice that some 'C compilers' CAN have an option to ignore aliasing rules of C (never by default). This, of course will change the meaning of the program, and will limit the C programmer. C99 (partially?) solved this issue by adding a new keyword: restrict.
Posted on 2004-06-16 15:59:52 by death
Sun FORTRAN 90 allows aliasing, another good example speaking of C99, is the register keyword. It is supposed to place the value in a register for example..

register INT pArray

however most compilers will ignore this directive and take the optimal path even if it means placing that variable in a memory location instead. The language and the compiler have different interpretations.
Posted on 2004-06-16 16:03:56 by donkey

Sun FORTRAN 90 allows aliasing, another good example speaking of C99, is the register keyword. It is supposed to place the value in a register for example..

register INT pArray

however most compilers will ignore this directive and take the optimal path even if it means placing that variable in a memory location instead. The language and the compiler have different interpretations.

Maybe Sun FORTRAN allows aliasing. Originally, FORTRAN didn't allow aliasing. Do you agree that this is a language rule that affects performance of generated code?

As for the 'register' keyword - it has nothing to do with C99 in particular, it existed way before.
It is only a recommendation from the programmer, like 'inline' for example. Most modern compilers rightfully ignore it - in the old days it was more important than it is today. It was never a rule that 'register' will do what the programmer intends it to do.
Posted on 2004-06-16 16:13:40 by death
Do you agree that this is a language rule that affects performance of generated code?


I will concede that one point however, there is no specific requirement to design these types of things into a language. Given that it is required to meet some standard, I am still not sure that a good compiler cannot still make some very efficient compiled code out of it, at which point it is no longer dependant on the language but on the quality of the compiler. Granted that some language design decisions can make writing a decent compiler difficult but that is the challenge of writing an excellent optimizer. Many of these types of things can be treated as special cases by the compiler and some system can be put into place to handle them effectively.
Posted on 2004-06-16 17:40:32 by donkey
A lot of it is there are a lot of assumptions that the compiler can't make. And having things like pointers make other optimizations be forced to be less aggressive because they can't assume that the location isn't an alias for another variable. Also things like register spill code will be avoided for a hand-coded solution. If you're aware of the optimizations that most compilers go through then it's easier to avoid writing the unoptimized way of coding a block.

grv
Posted on 2004-06-16 21:32:37 by grv575



I will concede that one point however, there is no specific requirement to design these types of things into a language. Given that it is required to meet some standard, I am still not sure that a good compiler cannot still make some very efficient compiled code out of it, at which point it is no longer dependant on the language but on the quality of the compiler. Granted that some language design decisions can make writing a decent compiler difficult but that is the challenge of writing an excellent optimizer. Many of these types of things can be treated as special cases by the compiler and some system can be put into place to handle them effectively.


Java?
Posted on 2004-06-16 21:37:30 by Mecurius



Java?


You have to go back to my original post in this thread...

Originally posted by donkey

Assembly is not faster, and neither is C or C++ or any other compiled language (I am excluding JITs here)
Posted on 2004-06-16 23:37:21 by donkey
Java can be compiled to native code as well :) - I believe the GNU people have a java compiler that uses GCC as a backend (don't all their languages?)
Posted on 2004-06-17 05:12:47 by f0dder
I can't wait for DonkeyC!! *swoon*

:grin:
Posted on 2004-06-17 06:13:37 by The Beginner
To be honest, GCJ is crap. It compiles Java code into crap that has an even crappier file size (1.2 MB for a "Hello, world!"). No wonder GCJ is crap. Take a look at the platform itself. CRAP! A for loop for 10000 counts takes minutes, while the same written in C takes a few seconds. ;) I think this should be framed on my walls: "The Java API is the crappiest! =P".
Posted on 2004-06-17 14:25:32 by evil__donkey
Are you suggesting that a for-loop is an API?
Or that an API is the same as a language? Or that an API has an effect on the performance of a language in itself, even when not using the API?
Posted on 2004-06-17 14:39:09 by Scali

Hello donkey,
The point is, that while C allows aliasing, FORTRAN doesn't.

Hmmm....
It has been at least 25 years since I regularly programmed in FORTRAN,
but I distinctly remember this problem in a COMMON section that took me
weeks to figure out because the original programmer of some code aliased
a couple of variables in order to save a few bytes of memory.

Yes, aliasing *is* possible in FORTRAN. Has been ever since they had
the COMMON statement (and I'm pretty sure COMMON goes back to
the early days of FORTRAN).

Also, don't forget that prior to FORTRAN IV, most parameters were passed
by reference, which certainly allows aliasing. Later versions of FORTRAN
started using pass by value/returned (or pass by value/result if you prefer
that name), largely because of problems with aliased parameters.


This allows a FORTRAN compiler to make optimizations that a C compiler can't.

There are many reasons FORTRAN programs have opportunities for optimization
that don't exist in C. But a lack of aliasing is not one of them. Unless FORTRAN
has changed dramatically behind my back, you can still declare variables in
a COMMON section (it may have changed, I don't know, but this is one of those
things I'd doubt as COMMON was far too popular in FORTRAN programs).

Cheers,
Randy Hyde
Posted on 2004-06-17 15:01:03 by rhyde
What I was talking about, was aliasing of the arguments in CALL statements.


The FORTRAN standard prohibits using the same variable (or array
element) more than once in the same CALL statement, if one of the
associated formal arguments (i.e. associated with the aliased
actual arguments) is assigned a value during the subprogram call.


Taken from "User Notes on Fortran Programming" .
Posted on 2004-06-17 15:10:42 by death

What I was talking about, was aliasing of the arguments in CALL statements.



Taken from "User Notes on Fortran Programming" .


I would be careful about relying on this document.
Consider http://www.ibiblio.org/pub/languages/fortran/ch1-8.html#01
This was a problem common in FORTRAN II programs. This is why
FORTRAN IV switched from pass by reference to pass by value/result
parameters. Mind you, I was using FORTRAN in the middle 1970's and
this problem had been corrected back then.

As for the FORTRAN standard "disallowing" aliases in parameter
lists, this is just a simple way of saying "the compiler is broken
and doesn't detect this case, it may very well generate erroneous
code if you go ahead and do it." Maybe FORTRAN compilers have
gotten a bit smarter since the 1970's, bit *I've* never gotten
a diagnostic message when doing this stuff. Arrays, of course,
are passed by reference in FORTRAN (forgot about that), but
array elements are still passed by value/result. So, technically,
an alias does *not* exist when you pass a whole array and
an element of that same array in the same call. Passing COMMON
or EQUIVALENCE objects, of course, is a certain way to foul up
the compiler if it ignores the aliases. But as I said, the phrase
you quoted simply seems to suggest that FORTRAN compiler
writers can make unsafe optimizations and assume it's the
programmer's fault rather than the compiler's fault when
optimizations screw things up.

Bottom line: FORTRAN *does* allow aliases in parameter
lists. If the phrase you quote is actually from a standards
document for FORTRAN, this suggests that FORTRAN compiler
writers don't have to deal with aliases and it's the programmers'
responsibility to avoid them (sorta like it's the programmer's
responsibility to avoid changing loop control variables in Pascal
FOR loops).

Cheers,
Randy Hyde
Posted on 2004-06-17 15:59:51 by rhyde

Bottom line: FORTRAN *does* allow aliases in parameter
lists. If the phrase you quote is actually from a standards
document for FORTRAN, this suggests that FORTRAN compiler
writers don't have to deal with aliases and it's the programmers'
responsibility to avoid them (sorta like it's the programmer's
responsibility to avoid changing loop control variables in Pascal
FOR loops).

From the FORTRAN 77 Standard: "15.9.3.6 Restrictions and Association of Entities"

Whether it is the programmer's responsibility to avoid the aliasing or the compiler's is not the issue. This is a language rule, stated in the FORTRAN standard.

Some FORTRAN compilers do take advantage of this language rule and do optimize with the assumption that aliasing doesn't happen. If the results are not what the programmer expected because of that, it is the programmer's fault.
Posted on 2004-06-17 16:37:07 by death
lol Scali. No. I mean to say, the language is beautiful, but the API and it's platform is slow and bloat. That's all.
Posted on 2004-06-18 02:21:46 by evil__donkey
evildonkey, you can still get fairly decent things running in java... it's slower than native, sure, and the environment is somewhat bloated - because it supports a lot of stuff.

I don't want to see a lot of stuff written in JAVA, because we're more or less forced to use sun's *very* slow and bloated JVM after the MS settlement... but it works well for online interactive stuff.

Oh, and check out http://www.pouet.net/prod.php?which=10808 :)
Posted on 2004-06-21 03:51:04 by f0dder
I keep Java turned off almost all of the time. When I turn it on I get this from a surprising number of sites, I'm sick of that virus delivery system.

Source: C:\Documents and Settings\Administrator\Application Data\Sun\Java\Deployment\cache\javapi\v1.0\jar\classload.jar-1f5b6b54-24a83f49.zip
Click for more information about this virus : Trojan.ByteVerify

Not that it can do me any harm, it is always caught by NAV and the security patch has been around since September last year, but it always makes me worry if others might get by unnoticed. Now if a site uses Java I pretty much throw it into "never visit" bin.
Posted on 2004-06-21 05:58:51 by donkey
ewwww java :)
not that .net is any better ....
Posted on 2004-06-21 06:19:18 by wizzra


Wow f0dder, that absolutely rox!!!! :)
Posted on 2004-06-21 11:34:37 by Scali