Hi all,

Please, allow me to ask this naive question...

I am mainly a programmer in Matlab. Often times for the sake of speed, I 
convert my Matlab program into C/C++, often with the aid of numerical 
libraries such as GSL, IMSL, MKL, etc.

Now I am facing a numerical computation task which need quadruple precison. 
Please see below for a detailed description.

I guess Intel Visual Fortran or other Fortran has natural support for the 
quadruple precision.

I probably will have to pick up my Fortran book and do some Fortran 
programming. (I've touched a little bit of it some years ago).

Now, speed if critical for my application. If somebody tells me that 
Fortran's support of Quadruple precision is about 10% faster than any other 
quadruple solution in any other libraries in C/C++, then I am going to turn 
to Fortran.

If the consensus is that Fortran for numerical calculations is only 5% 
faster than C/C++, then I won't bother turn to Fortran.

Thanks!

-------------------------------
Seeking the fastest numerical library for quadruple precision in 
C/C++/Fortran
Hi all,

I have some computation and simulation which need quadruple precision. I
mean, the double precision is not enough, while high precision such as 1000
digits is not needed, and that's too slow. I guess quadruple precision
exactly fits my problem and should be much faster than double precision.

Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
already got quadruple precision in them and they are fully supported on
Intel based cpus? I guess Intel Fortran has quadruple precision, but since I
prefer C/C++ so my first choices are within C/C++ languages.

Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
support? I only need +, -, *, /, exp, and log.

I eventually have to do everything in C/C++ so I am primarily looking for
numerical libraries, instead of Matlab or Maple or Mathematica's symbolic
capability.

But if you know how to "simulate" quadruple precision in Matlab or Maple, or
Mathematica, in order to see if an algorithm will overslow when converting
into C/C++/Fortran, please let me know. I want to do the algorithm design in
Matlab, and test if it will overflow, before converting everything into
C/C++/Fortran.

If you know how to "simulate" quadruple precision in Matlab, Maple or
Mathematica even with the symbolic toolbox, please let me know too... this
is for algorithm design and testing...

Moreover, are there popular quadruple precision packages? Please recommend
the fastest one. I am really in huge need of speed.

Thank you very much!
------------------------------------------------ 

Vista writes:

> I guess Intel Visual Fortran or other Fortran has natural support for the 
> quadruple precision.

What do you mean by "natural" support?  My concept involves having a
128-bit floating point unit and a compiler that can use it.  When the
requested precision exceeds the capabilities of the hardware, it needs
to be emulated in software, which can be extremely slow.

Vista <abc@gmai.com> wrote:

> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any other
> quadruple solution in any other libraries in C/C++, then I am going to turn
> to Fortran.
> 
> If the consensus is that Fortran for numerical calculations is only 5%
> faster than C/C++, then I won't bother turn to Fortran.

I'm going to tell you that if you are looking for such a simple-minded
metric, then you aren't going to find it. Well, you can probably find
people who will tell you anything, but I'm assuming you actually want it
to be accurate.

The variation from one compiler to another, one application to another,
and a whole lot of other factors will dwarf any generic language
difference.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

<tholen@antispam.ham> wrote in message 
news:468b04e9$0$16592$4c368faf@roadrunner.com...
> Vista writes:
>
>> I guess Intel Visual Fortran or other Fortran has natural support for the
>> quadruple precision.
>
> What do you mean by "natural" support?  My concept involves having a
> 128-bit floating point unit and a compiler that can use it.  When the
> requested precision exceeds the capabilities of the hardware, it needs
> to be emulated in software, which can be extremely slow.
>

But is there a 128-bit floating point unit in Intel CPU and supported by the 
compiler?

And how slow is the software emulation?

I would imagine that the "double double" (quad) will be still much faster 
than multiple/high precision package... 

Vista writes:

>>> I guess Intel Visual Fortran or other Fortran has natural support for the
>>> quadruple precision.

>> What do you mean by "natural" support?  My concept involves having a
>> 128-bit floating point unit and a compiler that can use it.  When the
>> requested precision exceeds the capabilities of the hardware, it needs
>> to be emulated in software, which can be extremely slow.

> But is there a 128-bit floating point unit in Intel CPU and supported by the 
> compiler?

Not to my knowledge.  The 32-bit Intel processors have had an 80-bit
floating point unit for quite a few years now.  I'm not aware of any
expansion in the FPU with the newer 64-bit processors.

> And how slow is the software emulation?

Many times slower than hardware.  Can you remember back to the 80386 days
without a 80387 FPU, or even the 8086 days without an 8087 FPU?

> I would imagine that the "double double" (quad) will be still much faster 
> than multiple/high precision package... 

That's not obvious.  Extended precision software packages simply do it
in software, just like quad precision.

Vista wrote:
> 
> I guess Intel Visual Fortran or other Fortran has natural support for the 
> quadruple precision.

Intel (and a few other brands) of Fortran support quad without 
additional add-ons, as a standard Fortran data type, even on platforms 
where it is not a hardware supported data type. On a few platforms, such 
as Itanium and Power, there is sufficient hardware support for quad 
precision that it can be carried out in less than 3 times the time 
required for double, for applications which don't spend much time on 
divide or transcendentals.  On Itanium, this is done under reasonable 
compliance with IEEE standard for IEEE 128-bit floating point. On more 
popular platforms like x86-64, the loss of opportunity for vectorization 
makes the penalty for quad precision more like an order of magnitude. 
It is still possible to show reasonable compliance with IEEE standard.
> 
> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any other 
> quadruple solution in any other libraries in C/C++, then I am going to turn 
> to Fortran.
> 
> If the consensus is that Fortran for numerical calculations is only 5% 
> faster than C/C++, then I won't bother turn to Fortran.
> 

When you use software floating point, in principle, any differences 
among languages become less important, compared to the quality of the 
floating point emulation.  While some C/C++ compilers include some 
hidden support for quad precision, I don't know of any where it's a 
vendor supported data type.  So it will be difficult to make a 
meaningful comparison such as you request.
> 
> I have some computation and simulation which need quadruple precision. I
> mean, the double precision is not enough, while high precision such as 1000
> digits is not needed, and that's too slow. I guess quadruple precision
> exactly fits my problem and should be much faster than double precision.
It's difficult to guess what you are getting at here.  Certainly, if the 
quad precision of several Fortran compilers satisfies your needs, it 
should be more convenient and possibly more efficient than multiple 
precision libraries such as GMP, particularly if you are restricting 
your usage to Windows.
> 
> Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
> already got quadruple precision in them and they are fully supported on
> Intel based cpus? I guess Intel Fortran has quadruple precision, but since I
> prefer C/C++ so my first choices are within C/C++ languages.
> 
> Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
> support? I only need +, -, *, /, exp, and log.
Up to now, I thought you were thinking along the lines of GMP.  MKL does 
incorporate a GMP work-alike.
> 
> Moreover, are there popular quadruple precision packages? Please recommend
> the fastest one. I am really in huge need of speed.
> 
As already stated, GMP and compatible packages seem to be the closest 
match to your ideas in terms of add-on libraries.  Of course, they 
present a significant performance and coding difficulty penalty, 
compared to native hardware supported floating point.

Your questions aren't precise enough to admit of meaningful answers. 
There is plenty of preliminary research you could do quickly to improve 
on this.

"Tim Prince" <timothyprince@sbcglobal.net> wrote in message 
news:NwEii.20482$RX.11048@newssvr11.news.prodigy.net...
> Vista wrote:
>>
>> I guess Intel Visual Fortran or other Fortran has natural support for the 
>> quadruple precision.
>
> Intel (and a few other brands) of Fortran support quad without additional 
> add-ons, as a standard Fortran data type, even on platforms where it is 
> not a hardware supported data type. On a few platforms, such as Itanium 
> and Power, there is sufficient hardware support for quad precision that it 
> can be carried out in less than 3 times the time required for double, for 
> applications which don't spend much time on divide or transcendentals.  On 
> Itanium, this is done under reasonable compliance with IEEE standard for 
> IEEE 128-bit floating point. On more popular platforms like x86-64, the 
> loss of opportunity for vectorization makes the penalty for quad precision 
> more like an order of magnitude. It is still possible to show reasonable 
> compliance with IEEE standard.

Why loss of vectorization?

How about X86-32 Intel CPU, which is in my laptop?

>>
>> Now, speed if critical for my application. If somebody tells me that 
>> Fortran's support of Quadruple precision is about 10% faster than any 
>> other quadruple solution in any other libraries in C/C++, then I am going 
>> to turn to Fortran.
>>
>> If the consensus is that Fortran for numerical calculations is only 5% 
>> faster than C/C++, then I won't bother turn to Fortran.
>>
>
> When you use software floating point, in principle, any differences among 
> languages become less important, compared to the quality of the floating 
> point emulation.  While some C/C++ compilers include some hidden support 
> for quad precision, I don't know of any where it's a vendor supported data 
> type.  So it will be difficult to make a meaningful comparison such as you 
> request.

I would imagine a 3rd-party quad library in C/C++ be slower than a native 
Fortran code?

>>
>> I have some computation and simulation which need quadruple precision. I
>> mean, the double precision is not enough, while high precision such as 
>> 1000
>> digits is not needed, and that's too slow. I guess quadruple precision
>> exactly fits my problem and should be much faster than double precision.
> It's difficult to guess what you are getting at here.  Certainly, if the 
> quad precision of several Fortran compilers satisfies your needs, it 
> should be more convenient and possibly more efficient than multiple 
> precision libraries such as GMP, particularly if you are restricting your 
> usage to Windows.

GMP and MPFR can also be compiled under Windows XP.

I have an implementation using MPFR.

But it is just slow.

I want to turn to quad precision.

I would guess setting "number-of-precision-digits" to be 50 digits in MPFR 
will still be slower than using "quad" data type. Since MPFR's 
implementation is mainly for high precision support and it is a complete 
different structure....


>>
>> Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
>> already got quadruple precision in them and they are fully supported on
>> Intel based cpus? I guess Intel Fortran has quadruple precision, but 
>> since I
>> prefer C/C++ so my first choices are within C/C++ languages.
>>
>> Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
>> support? I only need +, -, *, /, exp, and log.
> Up to now, I thought you were thinking along the lines of GMP.  MKL does 
> incorporate a GMP work-alike.
>>
>> Moreover, are there popular quadruple precision packages? Please 
>> recommend
>> the fastest one. I am really in huge need of speed.
>>
> As already stated, GMP and compatible packages seem to be the closest 
> match to your ideas in terms of add-on libraries.  Of course, they present 
> a significant performance and coding difficulty penalty, compared to 
> native hardware supported floating point.
>
> Your questions aren't precise enough to admit of meaningful answers. There 
> is plenty of preliminary research you could do quickly to improve on this.

Could you specify what shall I add to make the questions more precise?

Thanks! 

<tholen@antispam.ham> wrote in message 
news:468b12fc$0$30605$4c368faf@roadrunner.com...
> Vista writes:
>
>>>> I guess Intel Visual Fortran or other Fortran has natural support for 
>>>> the
>>>> quadruple precision.
>
>>> What do you mean by "natural" support?  My concept involves having a
>>> 128-bit floating point unit and a compiler that can use it.  When the
>>> requested precision exceeds the capabilities of the hardware, it needs
>>> to be emulated in software, which can be extremely slow.
>
>> But is there a 128-bit floating point unit in Intel CPU and supported by 
>> the
>> compiler?
>
> Not to my knowledge.  The 32-bit Intel processors have had an 80-bit
> floating point unit for quite a few years now.  I'm not aware of any
> expansion in the FPU with the newer 64-bit processors.
>
>> And how slow is the software emulation?
>
> Many times slower than hardware.  Can you remember back to the 80386 days
> without a 80387 FPU, or even the 8086 days without an 8087 FPU?
>
>> I would imagine that the "double double" (quad) will be still much faster
>> than multiple/high precision package...
>
> That's not obvious.  Extended precision software packages simply do it
> in software, just like quad precision.
>

Yes, but perhaps with different data structure. I remember multiple 
precision packages reprement numbers using array of digits, while "quad" 
should represent numbers smarter?

Thanks! 

"Vista" <abc@gmai.com> wrote in message 
news:f6ev6r$4b8$1@news.Stanford.EDU...
> Hi all,
>
> Please, allow me to ask this naive question...
>

It's not the language, it's the compiler.



> I am mainly a programmer in Matlab. Often times for the sake of speed, I 
> convert my Matlab program into C/C++, often with the aid of numerical 
> libraries such as GSL, IMSL, MKL, etc.
>
> Now I am facing a numerical computation task which need quadruple 
> precison. Please see below for a detailed description.
>
> I guess Intel Visual Fortran or other Fortran has natural support for the 
> quadruple precision.
>
> I probably will have to pick up my Fortran book and do some Fortran 
> programming. (I've touched a little bit of it some years ago).
>
> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any 
> other quadruple solution in any other libraries in C/C++, then I am going 
> to turn to Fortran.
>
> If the consensus is that Fortran for numerical calculations is only 5% 
> faster than C/C++, then I won't bother turn to Fortran.
>
> Thanks!
>
> -------------------------------
> Seeking the fastest numerical library for quadruple precision in 
> C/C++/Fortran
> Hi all,
>
> I have some computation and simulation which need quadruple precision. I
> mean, the double precision is not enough, while high precision such as 
> 1000
> digits is not needed, and that's too slow. I guess quadruple precision
> exactly fits my problem and should be much faster than double precision.
>
> Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
> already got quadruple precision in them and they are fully supported on
> Intel based cpus? I guess Intel Fortran has quadruple precision, but since 
> I
> prefer C/C++ so my first choices are within C/C++ languages.
>
> Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
> support? I only need +, -, *, /, exp, and log.
>
> I eventually have to do everything in C/C++ so I am primarily looking for
> numerical libraries, instead of Matlab or Maple or Mathematica's symbolic
> capability.
>
> But if you know how to "simulate" quadruple precision in Matlab or Maple, 
> or
> Mathematica, in order to see if an algorithm will overslow when converting
> into C/C++/Fortran, please let me know. I want to do the algorithm design 
> in
> Matlab, and test if it will overflow, before converting everything into
> C/C++/Fortran.
>
> If you know how to "simulate" quadruple precision in Matlab, Maple or
> Mathematica even with the symbolic toolbox, please let me know too... this
> is for algorithm design and testing...
>
> Moreover, are there popular quadruple precision packages? Please recommend
> the fastest one. I am really in huge need of speed.
>
> Thank you very much!
> ------------------------------------------------ 
>
> 

Richard Maine wrote:
> Vista <abc@gmai.com> wrote:

>>Now, speed if critical for my application. If somebody tells me that 
>>Fortran's support of Quadruple precision is about 10% faster than any other
>>quadruple solution in any other libraries in C/C++, then I am going to turn
>>to Fortran.
(snip)

> The variation from one compiler to another, one application to another,
> and a whole lot of other factors will dwarf any generic language
> difference.

I was about to write something similar.  Actually, though, it should
probably be compiler and processor, and the specific program.

I was just yesterday reading in "Computer Architecture: A Quantitative
Approach" by Hennessy and Patterson, 3rd edition, a comparison between
Itanium, Alpha 21264, and Pentium 4 on Spec2000 benchmarks.

One example is the SPECfp2000 for the above processors, where Itanium
is 1.08 times faster than Pentium 4.  (Sounds good.)  It turns out
that Itanium is 4x faster one one SPEC program, and pretty close
on the rest, most a little slower, some a lot slower.  SPEC uses
geometric mean (the only one that makes sense on ratios).

With different programs varying by a factor of about eight
between two processors (some are Fortran, some C) it doesn't
make much sense to worry about a few percent between languages.

To continue, Itanium is about 60% of Pentium 4 for SPECint2000.

I would recommend the Hennessy and Patterson books to anyone
interested in processor design, including interest in speed.

-- glen

Vista wrote:

> <tholen@antispam.ham> wrote in message 
(snip)

>>Not to my knowledge.  The 32-bit Intel processors have had an 80-bit
>>floating point unit for quite a few years now.  I'm not aware of any
>>expansion in the FPU with the newer 64-bit processors.

IA64 (Itanium) supports quad precision (128 bit) in the architecture,
but, according to the book I have from intel, it is done through
software emulation.  I believe that means both Itanium and Itanium2
processors.
(snip)

> Yes, but perhaps with different data structure. I remember multiple 
> precision packages reprement numbers using array of digits, while "quad" 
> should represent numbers smarter?

It might be that specifically programming for quad is faster than
the general programming of a multiple precision package.  The
"array of digits" method includes digits that are 32 bits long.

-- glen

Vista wrote:
>=20
> Now I am facing a numerical computation task which need quadruple
> precison.=20

Have you given sufficient thought to whether you really do need =
quadruple precision? That is, have you looked at ways of reformulating =
your problem/approach/algorithm to avoid precision loss wherever =
necessary?

David Jones

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:kP-dnTD5VrhKoRbbnZ2dnUVZ_s6onZ2d@comcast.com...
> Richard Maine wrote:
>> Vista <abc@gmai.com> wrote:
>
>>>Now, speed if critical for my application. If somebody tells me that 
>>>Fortran's support of Quadruple precision is about 10% faster than any 
>>>other
>>>quadruple solution in any other libraries in C/C++, then I am going to 
>>>turn
>>>to Fortran.
> (snip)
>
>> The variation from one compiler to another, one application to another,
>> and a whole lot of other factors will dwarf any generic language
>> difference.
>
> I was about to write something similar.  Actually, though, it should
> probably be compiler and processor, and the specific program.
>
> I was just yesterday reading in "Computer Architecture: A Quantitative
> Approach" by Hennessy and Patterson, 3rd edition, a comparison between
> Itanium, Alpha 21264, and Pentium 4 on Spec2000 benchmarks.
>
> One example is the SPECfp2000 for the above processors, where Itanium
> is 1.08 times faster than Pentium 4.  (Sounds good.)  It turns out
> that Itanium is 4x faster one one SPEC program, and pretty close
> on the rest, most a little slower, some a lot slower.  SPEC uses
> geometric mean (the only one that makes sense on ratios).
>
> With different programs varying by a factor of about eight
> between two processors (some are Fortran, some C) it doesn't
> make much sense to worry about a few percent between languages.
>
> To continue, Itanium is about 60% of Pentium 4 for SPECint2000.
>
> I would recommend the Hennessy and Patterson books to anyone
> interested in processor design, including interest in speed.
>
> -- glen
>

But I am stuck with my laptop which is Intel Centrino CPU. I don't have the 
luxury of trying all kinds of CPUs. That's why I care about the languages 
and efficiency of software... 

Vista wrote:
> "Tim Prince" <timothyprince@sbcglobal.net> wrote in message 
> news:NwEii.20482$RX.11048@newssvr11.news.prodigy.net...
> Why loss of vectorization?
> 
> How about X86-32 Intel CPU, which is in my laptop?
> 
>>> Now, speed if critical for my application. If somebody tells me that 
>>> Fortran's support of Quadruple precision is about 10% faster than any 
>>> other quadruple solution in any other libraries in C/C++, then I am going 
>>> to turn to Fortran.
>>>

<--- CUT --->

>> Your questions aren't precise enough to admit of meaningful answers. There 
>> is plenty of preliminary research you could do quickly to improve on this.
> 
> Could you specify what shall I add to make the questions more precise?
> 

All this talk about Fortran versus C, "native" versus "3rd-party" 
support for quad precision leaves an important question untouched.

Convince us that you need quad precision. Convince us that you need a 
software-only solution, rather than an upgrade to a more powerful 
processor than a Centrino. Convince us that your algorithms are already 
good enough that quad precision will be necessary and sufficient.

Years ago we had a young programmer who impressed us by running Unix on 
a Commodore-64 using only floppies. Would most of us want to emulate that?

-- mecej4

Vista wrote:
> "Tim Prince" <timothyprince@sbcglobal.net> wrote in message 
> news:NwEii.20482$RX.11048@newssvr11.news.prodigy.net...
>> Vista wrote:
>>> I guess Intel Visual Fortran or other Fortran has natural support for the 
>>> quadruple precision.
>> Intel (and a few other brands) of Fortran support quad without additional 
>> add-ons, as a standard Fortran data type, even on platforms where it is 
>> not a hardware supported data type. On a few platforms, such as Itanium 
>> and Power, there is sufficient hardware support for quad precision that it 
>> can be carried out in less than 3 times the time required for double, for 
>> applications which don't spend much time on divide or transcendentals.  On 
>> Itanium, this is done under reasonable compliance with IEEE standard for 
>> IEEE 128-bit floating point. On more popular platforms like x86-64, the 
>> loss of opportunity for vectorization makes the penalty for quad precision 
>> more like an order of magnitude. It is still possible to show reasonable 
>> compliance with IEEE standard.
> 
> Why loss of vectorization?

All right, try writing a vector quad software floating point library 
yourself.  You'll have to give up the IEEE extended exponent range and 
113 bit precision, and you'll still be a while.

> How about X86-32 Intel CPU, which is in my laptop?
Livermore Fortran Kernel ifort geo mean performance on early Centrino 
laptop:
double: 546 Mflops
quad:    10 Mflops

Core 2 Duo desktop using single thread is at least 60% faster than the 
above numbers.  I'm thinking of swapping in a Core 2 Quad.

> Could you specify what shall I add to make the questions more precise?
> 

Since then, you mentioned that you did try mpfr, and found it too slow. 
  You can't have it both ways.

glen herrmannsfeldt wrote:
> Vista wrote:
> 
>> <tholen@antispam.ham> wrote in message 
> (snip)
> 
>>> Not to my knowledge.  The 32-bit Intel processors have had an 80-bit
>>> floating point unit for quite a few years now.  I'm not aware of any
>>> expansion in the FPU with the newer 64-bit processors.
Newer SSE2+ CPUs have ability to perform 2 64-bit operations fully in 
parallel.  This may be somewhat useful in 128-bit floating point 
emulation.
> 
> IA64 (Itanium) supports quad precision (128 bit) in the architecture,
> but, according to the book I have from intel, it is done through
> software emulation.  I believe that means both Itanium and Itanium2
> processors.

I believe the add/subtract/multiply emulation can be expanded in line. 
Divide/sqrt clearly must be function calls (quite slow).  Single 
instruction floating point operations are 82 bits wide, so it requires 
combinations to extend to 128 bits.  80-bit mode should be at least 
twice as fast as 128-bit mode, not that it's easy to compare them 
directly.  80-bit long double is fully supported in C, 128-bit quad 
fully supported in Fortran.  Evidently, all this support for extended 
precisions has not made a fully successful market for these CPUs.

Vista wrote:
> I eventually have to do everything in C/C++ so I am primarily looking for
> numerical libraries, instead of Matlab or Maple or Mathematica's symbolic
> capability.

Extended float precision is easy in Mathematica but ~100x slower.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

In article <f6ev6r$4b8$1@news.Stanford.EDU>, Vista wrote:
> Hi all,
> 
> Please, allow me to ask this naive question...
> 
> I am mainly a programmer in Matlab. Often times for the sake of speed, I 
> convert my Matlab program into C/C++, often with the aid of numerical 
> libraries such as GSL, IMSL, MKL, etc.
> 
> Now I am facing a numerical computation task which need quadruple precison. 
> Please see below for a detailed description.
> 
> I guess Intel Visual Fortran or other Fortran has natural support for the 
> quadruple precision.
> 
> I probably will have to pick up my Fortran book and do some Fortran 
> programming. (I've touched a little bit of it some years ago).
> 
> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any other 
> quadruple solution in any other libraries in C/C++, then I am going to turn 
> to Fortran.
> 
> If the consensus is that Fortran for numerical calculations is only 5% 
> faster than C/C++, then I won't bother turn to Fortran.
> 
> Thanks!
> 
> -------------------------------
> Seeking the fastest numerical library for quadruple precision in 
> C/C++/Fortran
> Hi all,
> 
> I have some computation and simulation which need quadruple precision. I
> mean, the double precision is not enough, while high precision such as 1000
> digits is not needed, and that's too slow. I guess quadruple precision
> exactly fits my problem and should be much faster than double precision.
> 
> Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
> already got quadruple precision in them and they are fully supported on
> Intel based cpus? I guess Intel Fortran has quadruple precision, but since I
> prefer C/C++ so my first choices are within C/C++ languages.
> 
> Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
> support? I only need +, -, *, /, exp, and log.
> 
> I eventually have to do everything in C/C++ so I am primarily looking for
> numerical libraries, instead of Matlab or Maple or Mathematica's symbolic
> capability.
> 
> But if you know how to "simulate" quadruple precision in Matlab or Maple, or
> Mathematica, in order to see if an algorithm will overslow when converting
> into C/C++/Fortran, please let me know. I want to do the algorithm design in
> Matlab, and test if it will overflow, before converting everything into
> C/C++/Fortran.
> 
> If you know how to "simulate" quadruple precision in Matlab, Maple or
> Mathematica even with the symbolic toolbox, please let me know too... this
> is for algorithm design and testing...
> 
> Moreover, are there popular quadruple precision packages? Please recommend
> the fastest one. I am really in huge need of speed.
> 
> Thank you very much!
> ------------------------------------------------ 
> 
> 

I remember in years past on a VAX that used different front ends for parsing
C and FORTRAN and the same back end for the actual compile to machine code,
the same program in C and FORTRAN was faster in FORTRAN. It was explained to
me that the contraints of the languages allowed the FORTRAN front-end to make
assumptions about the code that the C front-end was unable to make, so the
FORTRAN front-end could generate tighter intermediate code.

Mike

Mike wrote:

> In article <f6ev6r$4b8$1@news.Stanford.EDU>, Vista wrote:
> 
>>Hi all,
>>
>>Please, allow me to ask this naive question...
>>
>>I am mainly a programmer in Matlab. Often times for the sake of speed, I 
>>convert my Matlab program into C/C++, often with the aid of numerical 
>>libraries such as GSL, IMSL, MKL, etc.
>>
>>Now I am facing a numerical computation task which need quadruple precison. 
>>Please see below for a detailed description.
>>
>>I guess Intel Visual Fortran or other Fortran has natural support for the 
>>quadruple precision.
>>
>>I probably will have to pick up my Fortran book and do some Fortran 
>>programming. (I've touched a little bit of it some years ago).
>>
>>Now, speed if critical for my application. If somebody tells me that 
>>Fortran's support of Quadruple precision is about 10% faster than any other 
>>quadruple solution in any other libraries in C/C++, then I am going to turn 
>>to Fortran.
>>
>>If the consensus is that Fortran for numerical calculations is only 5% 
>>faster than C/C++, then I won't bother turn to Fortran.
>>
>>Thanks!
>>
>>-------------------------------
>>Seeking the fastest numerical library for quadruple precision in 
>>C/C++/Fortran
>>Hi all,
>>
>>I have some computation and simulation which need quadruple precision. I
>>mean, the double precision is not enough, while high precision such as 1000
>>digits is not needed, and that's too slow. I guess quadruple precision
>>exactly fits my problem and should be much faster than double precision.
>>
>>Could anybody tell me if MS Visual C++, or Intel C, Intel Fortran have
>>already got quadruple precision in them and they are fully supported on
>>Intel based cpus? I guess Intel Fortran has quadruple precision, but since I
>>prefer C/C++ so my first choices are within C/C++ languages.
>>
>>Moreover, do GSL, Intel MKL, and IMSL etc. have got quadruple precision
>>support? I only need +, -, *, /, exp, and log.
>>
>>I eventually have to do everything in C/C++ so I am primarily looking for
>>numerical libraries, instead of Matlab or Maple or Mathematica's symbolic
>>capability.
>>
>>But if you know how to "simulate" quadruple precision in Matlab or Maple, or
>>Mathematica, in order to see if an algorithm will overslow when converting
>>into C/C++/Fortran, please let me know. I want to do the algorithm design in
>>Matlab, and test if it will overflow, before converting everything into
>>C/C++/Fortran.
>>
>>If you know how to "simulate" quadruple precision in Matlab, Maple or
>>Mathematica even with the symbolic toolbox, please let me know too... this
>>is for algorithm design and testing...
>>
>>Moreover, are there popular quadruple precision packages? Please recommend
>>the fastest one. I am really in huge need of speed.
>>
>>Thank you very much!
>>------------------------------------------------ 
>>
>>
> 
> 
> I remember in years past on a VAX that used different front ends for parsing
> C and FORTRAN and the same back end for the actual compile to machine code,
> the same program in C and FORTRAN was faster in FORTRAN. It was explained to
> me that the contraints of the languages allowed the FORTRAN front-end to make
> assumptions about the code that the C front-end was unable to make, so the
> FORTRAN front-end could generate tighter intermediate code.

....at the expense of "language expressiveness and flexibility"...

> 
> Mike


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

On 4 Jul, 08:26, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
....
> I was just yesterday reading in "Computer Architecture: A Quantitative
> Approach" by Hennessy and Patterson, 3rd edition, a comparison between
> Itanium, Alpha 21264, and Pentium 4 on Spec2000 benchmarks.
....
> I would recommend the Hennessy and Patterson books to anyone
> interested in processor design, including interest in speed.

Thks. Looks like a good book.

glen herrmannsfeldt wrote:

> Richard Maine wrote:
> 
>> Vista <abc@gmai.com> wrote:
> 
> 
>>> Now, speed if critical for my application. If somebody tells me that 
>>> Fortran's support of Quadruple precision is about 10% faster than any 
>>> other
>>> quadruple solution in any other libraries in C/C++, then I am going 
>>> to turn
>>> to Fortran.
> 
> (snip)
> 
>> The variation from one compiler to another, one application to another,
>> and a whole lot of other factors will dwarf any generic language
>> difference.
> 
> 
> I was about to write something similar.  Actually, though, it should
> probably be compiler and processor, and the specific program.
> 
> I was just yesterday reading in "Computer Architecture: A Quantitative
> Approach" by Hennessy and Patterson, 3rd edition, a comparison between
> Itanium, Alpha 21264, and Pentium 4 on Spec2000 benchmarks.
> 
> One example is the SPECfp2000 for the above processors, where Itanium
> is 1.08 times faster than Pentium 4.  (Sounds good.)  It turns out
> that Itanium is 4x faster one one SPEC program, and pretty close
> on the rest, most a little slower, some a lot slower.  SPEC uses
> geometric mean (the only one that makes sense on ratios).
> 
> With different programs varying by a factor of about eight
> between two processors (some are Fortran, some C) it doesn't
> make much sense to worry about a few percent between languages.
> 
> To continue, Itanium is about 60% of Pentium 4 for SPECint2000.
> 
> I would recommend the Hennessy and Patterson books to anyone
> interested in processor design, including interest in speed.

It has always been disappointing to me that VAX-on-a-chip or Harris 
H-series-on-a-chip never caught on.  Was there something fundamentally 
flawed in those mini architectures that didn't translate well?

> 
> -- glen
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
> Mike wrote:
....
>> I remember in years past on a VAX that used different front ends for
>> parsing C and FORTRAN and the same back end for the actual compile
>> to machine code, the same program in C and FORTRAN was faster in
>> FORTRAN. It was explained to me that the contraints of the languages
>> allowed the FORTRAN front-end to make assumptions about the code
>> that the C front-end was unable to make, so the FORTRAN front-end
>> could generate tighter intermediate code.
>
> ...at the expense of "language expressiveness and flexibility"...

C's expressiveness and flexibility are dubious qualities at best.

If you want to express the concept that two array arguments to a
procedure are *not* aliased, C didin't have a way to do it until
C99.  It was the default behavior in fortran.  And, being the most
commonly desired characteristic, it should be the default.  The
less common need for the arguments to be allowed to be aliased
can be accomplished in Fortran, it's just not the default.  Ironically,
C99's new feature 'restrict' (which is not default) has semantics
that mostly copy Fortran's default rules.

If you want the flexibility to do string assignment, string concatenation,
or extract substrings without using a clumsy function call syntax,
C doesn't have that.  Indeed, the only additional "flexibility" that
C strings have is the increased likelyhood of buffer overruns.

Etc.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

Gary Scott wrote:
> glen herrmannsfeldt wrote:
> 
> 
> It has always been disappointing to me that VAX-on-a-chip or Harris 
> H-series-on-a-chip never caught on.  Was there something fundamentally 
> flawed in those mini architectures that didn't translate well?
> 
By the time they would have been widely available they weren't 
competitive in price or performance.  Harris was way out of line with 
IEEE standards and in not supporting a widely used OS.

nos...@see.signature (Richard Maine) wrote:
> Vista <a...@gmai.com> wrote:
> > ...
> > If the consensus is that Fortran for numerical
> > calculations is only 5% faster than C/C++, then I won't
> > bother turn to Fortran.
>
> I'm going to tell you that if you are looking for such a
> simple-minded metric, then you aren't going to find it.

Agreed.

> Well, you can probably find people who will tell you
> anything, but I'm assuming you actually want it to be
> accurate.
>
> The variation from one compiler to another, one application
> to another, and a whole lot of other factors will dwarf any
> generic language difference.

Yes and no. Fact is, aliasing limitations of C90 mean that
Fortran has the potential for greater optimisations. This
stems from the fact that C was not designed with heavy
numerical computation in mind.

--
Peter

In article <vfTii.173$MV5.153@newsfe04.lga>, Mike  <mikee@mikee.ath.cx> wrote:

>I remember in years past on a VAX that used different front ends for parsing
>C and FORTRAN and the same back end for the actual compile to machine code,

I'm not sure why you're hearkening back; that's the way most modern
compilers work, too.

The sign of a good compiler engineer is one that likes Fortran,
because it's so easy to optimize.

-- greg

On Jul 4, 5:25 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:

> It has always been disappointing to me that VAX-on-a-chip or Harris
> H-series-on-a-chip never caught on.  Was there something fundamentally
> flawed in those mini architectures that didn't translate well?

In the case of VAX, it was simple stubbornness on the part of DEC's
management which did not want to license the VAX architecture nor
produce chips for others' products.  There are many who think that VAX
(or even the LSI-11) would have been very successful and stunted the
growth of the 68000.

Steve

James Giles wrote:

> Gary Scott wrote:
> 
>>Mike wrote:
> 
> ...
> 
>>>I remember in years past on a VAX that used different front ends for
>>>parsing C and FORTRAN and the same back end for the actual compile
>>>to machine code, the same program in C and FORTRAN was faster in
>>>FORTRAN. It was explained to me that the contraints of the languages
>>>allowed the FORTRAN front-end to make assumptions about the code
>>>that the C front-end was unable to make, so the FORTRAN front-end
>>>could generate tighter intermediate code.
>>
>>...at the expense of "language expressiveness and flexibility"...
> 
> 
> C's expressiveness and flexibility are dubious qualities at best.
> 
> If you want to express the concept that two array arguments to a
> procedure are *not* aliased, C didin't have a way to do it until
> C99.  It was the default behavior in fortran.  And, being the most
> commonly desired characteristic, it should be the default.  The
> less common need for the arguments to be allowed to be aliased
> can be accomplished in Fortran, it's just not the default.  Ironically,
> C99's new feature 'restrict' (which is not default) has semantics
> that mostly copy Fortran's default rules.
> 
> If you want the flexibility to do string assignment, string concatenation,
> or extract substrings without using a clumsy function call syntax,
> C doesn't have that.  Indeed, the only additional "flexibility" that
> C strings have is the increased likelyhood of buffer overruns.

I was being facetious.  Everytime I've queried the hacker types at work, 
they always want to discuss pointers ("FORTRAN doesn't even have 
pointers!", laughs).  I tended to discount them from then on.

> 
> Etc.
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Gary Scott wrote:
....

> It has always been disappointing to me that VAX-on-a-chip or Harris 
> H-series-on-a-chip never caught on.  Was there something fundamentally 
> flawed in those mini architectures that didn't translate well?

Harris seemed to have had a knack... :)

The RTX Forth chip was really neat for Forth, but immediately people 
demanded C compilers for it... :(

--

Gary Scott wrote:
> James Giles wrote:
....
>> C's expressiveness and flexibility are dubious qualities at best.
....
> I was being facetious.  Everytime I've queried the hacker types at
> work, they always want to discuss pointers ("FORTRAN doesn't even have
> pointers!", laughs).  I tended to discount them from then on.

I figured that you were being facetious.  But, the sad case is that
many people would recognize it.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

"James Giles" <jamesgiles@worldnet.att.net> wrote in message 
news:MlUii.145683$Sa4.12449@bgtnsc05-news.ops.worldnet.att.net...
> Gary Scott wrote:
>> Mike wrote:

>> ...at the expense of "language expressiveness and flexibility"...
> C's expressiveness and flexibility are dubious qualities at best.
snip
> If you want the flexibility to do string assignment, string concatenation,
> or extract substrings without using a clumsy function call syntax,
> C doesn't have that.  Indeed, the only additional "flexibility" that
> C strings have is the increased likelyhood of buffer overruns.
I'm not sure what you mean.  This sounds like K&R stuff, which I thought 
everyone basically liked.  I must say, with the few concatenation's I've 
done in fortran, that the syntax was immediate.
-- 
WW

Wade Ward wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:MlUii.145683$Sa4.12449@bgtnsc05-news.ops.worldnet.att.net...
>> Gary Scott wrote:
>>> Mike wrote:
>
>>> ...at the expense of "language expressiveness and flexibility"...
>> C's expressiveness and flexibility are dubious qualities at best.
> snip
>> If you want the flexibility to do string assignment, string
>> concatenation, or extract substrings without using a clumsy function
>> call syntax, C doesn't have that.  Indeed, the only additional 
>> "flexibility" that
>> C strings have is the increased likelyhood of buffer overruns.
> I'm not sure what you mean.  This sounds like K&R stuff, which I
> thought everyone basically liked.  I must say, with the few
> concatenation's I've done in fortran, that the syntax was immediate.

I find pretty much nothing in K&R to like.  But then, I've always
been more impressed by objective evidence of quality than by
popularity.  There's always seemed to be an anticorrelation
between popularity and quality.  In any case, the ability to
write simply:

   my_str = a_str(1:5) // "stuff"

is very convenient.  The C equivalent is a set of nested function
calls much less legible.  And unless you're very careful indeed,
the result of the concatenate may be longer than the space allotted
for the result - but C intrinsics don't care and go ahead and wipe
out whatever follows the result variable in memory.  The Fortran
statement above doesn't have those problems.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

"James Giles" <jamesgiles@worldnet.att.net> wrote in message 
news:f7Xii.276023$p47.273675@bgtnsc04-news.ops.worldnet.att.net...
> Wade Ward wrote:
>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
>> news:MlUii.145683$Sa4.12449@bgtnsc05-news.ops.worldnet.att.net...
>>> Gary Scott wrote:
>>>> Mike wrote:
>>
>>>> ...at the expense of "language expressiveness and flexibility"...
>>> C's expressiveness and flexibility are dubious qualities at best.
>> snip
>>> If you want the flexibility to do string assignment, string
>>> concatenation, or extract substrings without using a clumsy function
>>> call syntax, C doesn't have that.  Indeed, the only additional 
>>> "flexibility" that
>>> C strings have is the increased likelyhood of buffer overruns.
>> I'm not sure what you mean.  This sounds like K&R stuff, which I
>> thought everyone basically liked.  I must say, with the few
>> concatenation's I've done in fortran, that the syntax was immediate.
>
> I find pretty much nothing in K&R to like.  But then, I've always
> been more impressed by objective evidence of quality than by
> popularity.  There's always seemed to be an anticorrelation
> between popularity and quality.  In any case, the ability to
> write simply:
>
>   my_str = a_str(1:5) // "stuff"
>
> is very convenient.  The C equivalent is a set of nested function
> calls much less legible.  And unless you're very careful indeed,
> the result of the concatenate may be longer than the space allotted
> for the result - but C intrinsics don't care and go ahead and wipe
> out whatever follows the result variable in memory.  The Fortran
> statement above doesn't have those problems.
I see.  Since I'm relatively new to fortran, I'm not mature in my ability to 
work with strings, but don't get me wrong, when I left C for Fortran, I 
burned my ships and don't regret it.
-- 
WW 

Tim Prince wrote:

(snip on 128 bit floating point)

> I believe the add/subtract/multiply emulation can be expanded in line. 

I have the three book set from Intel, but I only have one out now.

> Divide/sqrt clearly must be function calls (quite slow).

It seems like even single and double divide are multiple
instructions long, but probably are still done inline.

>  Single 
> instruction floating point operations are 82 bits wide, so it requires 
> combinations to extend to 128 bits.  80-bit mode should be at least 
> twice as fast as 128-bit mode, not that it's easy to compare them 
> directly.  80-bit long double is fully supported in C, 128-bit quad 
> fully supported in Fortran.  Evidently, all this support for extended 
> precisions has not made a fully successful market for these CPUs.

It seems that IBM S/370 is the only one with good support for
128 bit, though even they didn't do divide in hardware until
half way through ESA/390, about 10 years ago.  But the format was
designed to make software emulation relatively easy, either for all
instructions (S/360 other than the 360/85) or divide.

Only a few VAX models seem to have hardware support for H float,
the 11/730 was the first one I knew about.

-- glen

James Giles wrote:
> Gary Scott wrote:
>> James Giles wrote:
> ...
>>> C's expressiveness and flexibility are dubious qualities at best.
> ...
>> I was being facetious.  Everytime I've queried the hacker types at
>> work, they always want to discuss pointers ("FORTRAN doesn't even have
>> pointers!", laughs).  I tended to discount them from then on.
> 
> I figured that you were being facetious.  But, the sad case is that
> many people would recognize it.
> 
  Or not ...

On Jul 4, 9:45 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Only a few VAX models seem to have hardware support for H float,
> the 11/730 was the first one I knew about.

And if memory serves me correctly, the only one until the VAX 9000
came out, though the 9000's H-float support was later partially gutted
in order to better support packed decimal for COBOL.

Steve

On Wed, 4 Jul 2007, Peter Nilsson wrote:
> 
> Yes and no. Fact is, aliasing limitations of C90 mean that
> Fortran has the potential for greater optimisations.

I think you mean C89 (the original ANSI standard C).  C99 includes the 
"restrict" keyword which is a promise from the programmer to the compiler 
that pointers do not point to overlapping memory regions, e.g.

void copy(double * restrict a, double * restrict b, int n)
{
  int i;

  for (i=0; i<n; i++)
    a[i] = b[i];
}

without the "restrict" keyword, the compiler could not auto-parallelize 
the loop due to the possibility that the two arrays of doubles could 
overlap.  With it, the loop iterations can be performed in any order, even 
simultaneously.

Chip

-- 
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"

Vista wrote:
> Hi all,
> 
> Please, allow me to ask this naive question...
> 
> I am mainly a programmer in Matlab. Often times for the sake of speed, I 
> convert my Matlab program into C/C++, often with the aid of numerical 
> libraries such as GSL, IMSL, MKL, etc.
> 
> Now I am facing a numerical computation task which need quadruple precison.

Hello,

I am immediately suspicious of an algorithm that "requires" quadruple precision. That's 
not to say that quadruple (or higher) precision isn't required in some cases, but in my 
(albeit limited) experience, it's usually an indication of an unsophisticated approach to 
a numerical problem.

> Please see below for a detailed description.
> 
> I guess Intel Visual Fortran or other Fortran has natural support for the 
> quadruple precision.
> 
> I probably will have to pick up my Fortran book and do some Fortran 
> programming. (I've touched a little bit of it some years ago).
> 
> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any other 
> quadruple solution in any other libraries in C/C++, then I am going to turn 
> to Fortran.

If speed is critical -- though I assume getting the correct answer is the prime 
requirement? :o) -- then spend some time on developing your algorithm so it doesn't need 
quad precision. Then you don't have to worry about red herrings such as "is <language X> 
faster than <language Y>?"

More info on the problem you're trying to solve, and how you've approached it so far, 
would help.

cheers,

paulv

-- 
Paul van Delst             Ride lots.
CIMSS @ NOAA/NCEP/EMC               Eddy Merckx

Chip Coldwell wrote:

> On Wed, 4 Jul 2007, Peter Nilsson wrote:

>>Yes and no. Fact is, aliasing limitations of C90 mean that
>>Fortran has the potential for greater optimisations.

> I think you mean C89 (the original ANSI standard C).

He said C90, not C99.  It seems that the ANSI standard was
in 1989, and the ISO standard in 1990.  Some call it C89,
and some C90.

http://en.wikipedia.org/wiki/ANSI_C

-- glen

Gib Bogle wrote:
> James Giles wrote:
....
>> I figured that you were being facetious.  But, the sad case is that
>> many people would recognize it.
>>
>  Or not ...

It's a strange thing that on my notebook's keyboard I seem to omit
keystrokes while typing - whole sequences of them.  Indeed, I touch
the keys, but not hard enough to work.  The effect is most noticable
with the omission of things like n't from the end of words.  Or 's
when possessive is intended.  I do know why (Oh, I mean don't).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

On 4 Jul, 03:05, "Vista" <a...@gmai.com> wrote:
....
....(re. 128-bit reals in Fortran and C)
....

> If the consensus is that Fortran for numerical calculations is only 5%
> faster than C/C++, then I won't bother turn to Fortran.

Having seen the replies I doubt you will get the 'consensus' you asked
for. Your requirement is quite specific and really, I would say,
demands support from the language implementation for the data types
that interest you.

Given that consensus is not available you could try the language
shootout (Google for it) for broadly similar routines to the ones you
need. That shows comparitive timings.

Failing that, if you have access to the compilers you could go to the
bother of writing one routine in both languages. Once compared you
will have some idea of what to use. (It would be cool if you reported
back.)

Failing all that you could take the third and simplest option, write
in C.

--
HTH,
James

cc. comp.lang.misc. Folks there may have some thoughts on this.
Language performance comparisons are always a good source of debate!

James Harris wrote:
> On 4 Jul, 03:05, "Vista" <a...@gmai.com> wrote:

>>If the consensus is that Fortran for numerical calculations is only 5%
>>faster than C/C++, then I won't bother turn to Fortran.

> Having seen the replies I doubt you will get the 'consensus' you asked
> for. Your requirement is quite specific and really, I would say,
> demands support from the language implementation for the data types
> that interest you.

I would probably agree that on the average (geometric mean for
ratios) that the difference is less than 5%, but it could be anywhere
from four times faster to four times slower depending on program,
compiler, and processor.

-- glen

On 5 Jul, 21:21, James Harris <james.harri...@googlemail.com> wrote:
> On 4 Jul, 03:05, "Vista" <a...@gmai.com> wrote:
> ...
> ...(re. 128-bit reals in Fortran and C)
> ...
>
> > If the consensus is that Fortran for numerical calculations is only 5%
> > faster than C/C++, then I won't bother turn to Fortran.

Here is a link from the language shootout I mentioned. It shows
comparisons between a Fortran and a C implementation: <http://
shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
that is as close as possible to your intended app. It's not a panacea
but might go some way to answering the original question you posed.
It's not too clear but grey means C is faster.

The C code is almost universally quicker. If you have an implementaion
that supports the data type you want to use, then as they say, write
in C: <http://www.poppyfields.net/filks/00259.html>

Steve Lionel wrote:
> On Jul 4, 9:45 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 
>> Only a few VAX models seem to have hardware support for H float,
>> the 11/730 was the first one I knew about.
> 
> And if memory serves me correctly, the only one until the VAX 9000
> came out, though the 9000's H-float support was later partially gutted
> in order to better support packed decimal for COBOL.

I thought the 11/780 had an option, i.e., a hardware card that
plugged into the Masbus(?), that implemented H-float.  Do I
misremember?

    -Ken
-- 
Ken & Ann Fairfield
What:  Ken dot And dot Ann
Where: Gmail dot Com

In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
James Harris  <james.harris.1@googlemail.com> wrote:

>Here is a link from the language shootout I mentioned. It shows
>comparisons between a Fortran and a C implementation: <http://
>shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>that is as close as possible to your intended app.

.... he might also want to use a compiler better than a very early
version of g95. You'd have to go out of your way to try to make
this "comparison" less useful.

-- greg

Greg Lindahl wrote:
> In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
> James Harris  <james.harris.1@googlemail.com> wrote:
>> Here is a link from the language shootout I mentioned. It shows
>> comparisons between a Fortran and a C implementation: <http://
>> shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>> that is as close as possible to your intended app.
> 
> ... he might also want to use a compiler better than a very early
> version of g95. You'd have to go out of your way to try to make
> this "comparison" less useful.

Indeed.

It seems to me that, if one actually wants a language shootout, one 
needs to at least make a token handwave at a reasonable statistical 
test.  That means taking a sampling of language implementations for each 
language, timing the compilations of all of them, and comparing the 
difference in the language averages to the variation within each 
langauge to see if the results are actually statistically significant.

Given the very wide range of results reported for various Fortran 
compilers in the Polyhedron test suite, I would be extremely surprised 
to find any differences between C and Fortran that even began to 
approach statistical significance, much less attained it.

At the very least, if one insists on trying to draw conclusions from a 
single implementation in each language, one should at least compare 
compilers with the same backend.  The shootout results linked to above 
compare g95 with a 4.0.1 GCC backend to a 4.1.2 version of GCC -- and 
there was quite a lot of middle- and back-end optimization that happened 
between those two GCC versions, which has nothing at all to do with 
Fortran versus C.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.

"Brooks Moses" <bmoses-nospam@cits1.stanford.edu> wrote in message 
news:468D9FAB.2070807@cits1.stanford.edu...
> Greg Lindahl wrote:
>> In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
>> James Harris  <james.harris.1@googlemail.com> wrote:
>>> Here is a link from the language shootout I mentioned. It shows
>>> comparisons between a Fortran and a C implementation: <http://
>>> shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>>> that is as close as possible to your intended app.
>>
>> ... he might also want to use a compiler better than a very early
>> version of g95. You'd have to go out of your way to try to make
>> this "comparison" less useful.
>
> Indeed.
>
> It seems to me that, if one actually wants a language shootout, one needs 
> to at least make a token handwave at a reasonable statistical test.  That 
> means taking a sampling of language implementations for each language, 
> timing the compilations of all of them, and comparing the difference in 
> the language averages to the variation within each langauge to see if the 
> results are actually statistically significant.
>
> Given the very wide range of results reported for various Fortran 
> compilers in the Polyhedron test suite, I would be extremely surprised to 
> find any differences between C and Fortran that even began to approach 
> statistical significance, much less attained it.
>
> At the very least, if one insists on trying to draw conclusions from a 
> single implementation in each language, one should at least compare 
> compilers with the same backend.  The shootout results linked to above 
> compare g95 with a 4.0.1 GCC backend to a 4.1.2 version of GCC -- and 
> there was quite a lot of middle- and back-end optimization that happened 
> between those two GCC versions, which has nothing at all to do with 
> Fortran versus C.
I think it's funny how people look for speed in one blindingly-fast language 
as opposed to another.  You might think that it might come from the people 
30 years ago for whom computing was a lot of time and money, but it's not. 
It's usually asked by newcomers to a syntax.
-- 
Wade Ward 

I can't think of a human problem that needs anywhere near 128 bits of
floating point.
Some integer problems I can believe do require absolute accuracy (e.g.
checking you really have found the factores of a very large integer or
for being prime. Also accountants count the very largest amounts in
the most worthless currencies down to the cents that only exist on
paper - even when the thousands denominated tokens are worthless tiny
impure metal objects.

There ARE problems where it is mportant to not lose so much
calculation precision as to not achieve the final objctive with any
accuracy. But as far as I know, all these problema can be resolved in
a way where an approximate solution, with variables being assigned
values which bear close relationship to the truth, allow moving the
starting point of the algorithm to this new startimg approximation and
making another calculation pass. (Normalization). The solutions
usually converge at a reasonable rate to the desired solution with any
desired degre of accureacy, if you proceed.

Wade Ward wrote:

(snip)

> I think it's funny how people look for speed in one blindingly-fast language 
> as opposed to another.  You might think that it might come from the people 
> 30 years ago for whom computing was a lot of time and money, but it's not. 
> It's usually asked by newcomers to a syntax.

Even as computers get faster, people are more interested in fast
hardware and fast software then 20 or 30 years ago.

I keep noticing processors that are 10% faster than the
previous model by the same company.

20 or 30 years ago, a new processor would be at least twice
as fast or they wouldn't bother trying to sell it.

-- glen

Terence wrote:

> I can't think of a human problem that needs anywhere near 128 bits of
> floating point.

(snip)

> There ARE problems where it is mportant to not lose so much
> calculation precision as to not achieve the final objctive with any
> accuracy. But as far as I know, all these problema can be resolved in
> a way where an approximate solution, with variables being assigned
> values which bear close relationship to the truth, allow moving the
> starting point of the algorithm to this new startimg approximation and
> making another calculation pass. (Normalization). The solutions
> usually converge at a reasonable rate to the desired solution with any
> desired degre of accureacy, if you proceed.

Yes, those kind of problems.  It might be possible to do other
ways, but sometimes high precision is the best way when you can't
be sure of another way.  Or sometimes just to verify that the
other way does give the appropriately close answer.

-- glen

"Vista" <abc@gmai.com> writes:


> If the consensus is that Fortran for numerical calculations is only 5% 
> faster than C/C++, then I won't bother turn to Fortran.

This really depends on what you want to do.  Fortran compilers
typically optimize for loops over large arrays, often employing loop
interchange, prefetching and blocking, which few (if any?) C/C++
compilers do.  C++ can do some of the same optimisations by carefully
writing template libraries that instantiate code to specific array
sizes.  I have heard of (at least) FFT and matrix multiply functions
made this way.

So, with good libraries, C++ may match Fortran on large array
operations, but if you need large-array code that isn't matched by an
existing optimized library, you might get more speed out of an
optimizing Fortran compiler.

For code that isn't dominated by loops over large arrays, I doubt
there is much speed difference between a good C/C++ compiler and a
good Fortran compiler.

You could also consider more modern languages like Clean, OCaml or
SML.

	Torben

> Now, speed if critical for my application. If somebody tells me that 
> Fortran's support of Quadruple precision is about 10% faster than any 
> other quadruple solution in any other libraries in C/C++, then I am going 
> to turn to Fortran.
>
> If the consensus is that Fortran for numerical calculations is only 5% 
> faster than C/C++, then I won't bother turn to Fortran.

I think that is a false criteria on the whole.

One aspect where Fortran per se, has the edge over C, is that Fortran does 
not allow aliasing but C does.
So technically a Fotran compiler could make extra optimisations that a C 
compiler cannot make.
But this academic, as every C compiler I have seen has switches that allow 
the compiler to make some assumptions about aliasing, so in practice, they 
are level.

But in terms of  support for "Quadruple precision", really that depends on 
the compiler implementation not language.
You could easily find a compiler of different languages - ADA, Delphi, C++ 
that might be faster here.

These days , it is hard for one lanaguage to outstrip another.
Only if a language has a particular strength in one area or some "killer 
feature" that gives it the edge should you use that langauge.
Most languages have particular strengths and weaknesses and you should pick 
the language that best meets yoru current projects requirements.

Stephen Howe

On Fri, 06 Jul 2007 13:29:28 +0100, Stephen Howe wrote:

>> Now, speed if critical for my application. If somebody tells me that
>> Fortran's support of Quadruple precision is about 10% faster than any
>> other quadruple solution in any other libraries in C/C++, then I am
>> going to turn to Fortran.
>>
>> If the consensus is that Fortran for numerical calculations is only 5%
>> faster than C/C++, then I won't bother turn to Fortran.
> 
> I think that is a false criteria on the whole.
> 
> One aspect where Fortran per se, has the edge over C, is that Fortran
> does not allow aliasing but C does.
> So technically a Fotran compiler could make extra optimisations that a C
> compiler cannot make.
> But this academic, as every C compiler I have seen has switches that
> allow the compiler to make some assumptions about aliasing, so in
> practice, they are level.

C99 has the type qualifier keyword 'restrict' which informs the compiler 
that a pointer will not be aliased. This hasn't made it into the current  
C++ standard (yet), although probably most C++ compilers implement it 
already as an extension (eg. G++ allows the type qualifier __restrict__).

-- 
Lionel B

On Jul 5, 6:49 pm, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
wrote:
> Greg Lindahl wrote:
> > In article <1183673566.649269.73...@o61g2000hsh.googlegroups.com>,
> > James Harris  <james.harri...@googlemail.com> wrote:
> >> Here is a link from the languageshootoutI mentioned. It shows
> >> comparisons between a Fortran and a C implementation: <http://
> >>shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
> >> that is as close as possible to your intended app.
>
> > ... he might also want to use a compiler better than a very early
> > version of g95. You'd have to go out of your way to try to make
> > this "comparison" less useful.
>
> Indeed.
>
> It seems to me that, if one actually wants a languageshootout, one
> needs to at least make a token handwave at a reasonable statistical
> test.  That means taking a sampling of language implementations for each
> language, timing the compilations of all of them, and comparing the
> difference in the language averages to the variation within each
> langauge to see if the results are actually statistically significant.


Perhaps one did not actually want a /language/ shootout in that sense.
I think the home page is quite clear about this - http://shootout.alioth.debian.org/


> Given the very wide range of results reported for various Fortran
> compilers in the Polyhedron test suite, I would be extremely surprised
> to find any differences between C and Fortran that even began to
> approach statistical significance, much less attained it.
>
> At the very least, if one insists on trying to draw conclusions from a
> single implementation in each language, one should at least compare
> compilers with the same backend.  Theshootoutresults linked to above
> compare g95 with a 4.0.1 GCC backend to a 4.1.2 version of GCC -- and
> there was quite a lot of middle- and back-end optimization that happened
> between those two GCC versions, which has nothing at all to do with
> Fortran versus C.


Fortran in the benchmarks game is sadly unloved - no one's sending
Features Requests asking for a different language implementation, no
one's working on the programs ...

http://shootout.alioth.debian.org/gp4/faq.php#report

>
> - Brooks
>
> --
> The "bmoses-nospam" address is valid; no unmunging needed.

"Isaac Gouy" <igouy2@yahoo.com> wrote in message 
news:1183741034.825083.266470@d30g2000prg.googlegroups.com...

> Fortran in the benchmarks game is sadly unloved - no one's sending
> Features Requests asking for a different language implementation, no
> one's working on the programs ...

> http://shootout.alioth.debian.org/gp4/faq.php#report

The shootout rules are designed for C programmers, not Fortran
programmers.  Whereas a Fortran programmer would look at a
problem statement, carry out some analysis, then compose a
brilliant innovative solution, a C programmer would have to
search for a pre-existing solution, likely in Fortran, then
code it up in C.  The pre-existing solutions prescribed in the
shootout page are at least in some cases a couple of orders of
magnitude slower than optimal algorithms.

C programmers are severely constrained by the fact that the
language is actually an assembly language for a long-dead
CPU and so as an assembly language is extra difficult to
master, a problem which is compounded by the fact that
students don't have ready access to a machine where they can
trace program execution instruction by instruction because the
target machine is so out of date.

The result is that it takes a one-year undergraduate course to
learn to do anything in C, while it is expected that Fortran
programmers become productive in a couple of weeks of working
with the language on their own.  This cuts into the time the
programmer should be spending learning useful things like
physics and also results in C occupying more of the "tip-of-the
tongue" knowledge a person can have at one time, driving out
the good physics once again.

Strangely as it might seem at first, the difficulty of C has
helped make it so successful as a language: since one has to
take an actual computer science course to become even
minimally proficient in it, a poor C programmer tends to know
a lot more about computer science than an average Fortran
programmer.  Thus he can state his case to management in a
more articulate way and get the company to convert to C even
when this is typically an antiprofitable venture.  Presentation
is more important than substance.

Um, let's see... wasn't this thread about quad precision?  In
Fortran templates, single-, double-, and quad-precision literals
are identical.  I've got lots to Fortran template code that looks
like this.  Oh, what's a reasonable example?  Maybe
http://home.comcast.net/~new-fft/conv2c.f90  If that isn't the
right one, I'll spend more time searching for a more suitable
example.  Don't literals for different floating point kinds
look different in C making it more difficult to switch precision?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <7zr6nmvty4.fsf@app-5.diku.dk>,
Torben �gidius Mogensen <torbenm@app-5.diku.dk> wrote:

>This really depends on what you want to do.  Fortran compilers
>typically optimize for loops over large arrays, often employing loop
>interchange, prefetching and blocking, which few (if any?) C/C++
>compilers do.

Eh? Lots of compilers do both Fortran and C/C++, and these compilers
pretty much all have the same optimizations for all languages. Whether
the compiler can see through all your pointers to effectively apply
them is a separate issue.

> C++ can do some of the same optimisations by carefully
>writing template libraries that instantiate code to specific array
>sizes.  I have heard of (at least) FFT and matrix multiply functions
>made this way.

.... and such code is probably outperformed by ATLAS and fftw.

-- greg

On Jul 6, 10:32 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
> "Isaac Gouy" <igo...@yahoo.com> wrote in message
>
> news:1183741034.825083.266470@d30g2000prg.googlegroups.com...
>
> > Fortran in the benchmarks game is sadly unloved - no one's sending
> > Features Requests asking for a different language implementation, no
> > one's working on the programs ...
> >http://shootout.alioth.debian.org/gp4/faq.php#report
>
> The shootout rules are designed for C programmers, not Fortran
> programmers.  Whereas a Fortran programmer would look at a
> problem statement, carry out some analysis, then compose a
> brilliant innovative solution, a C programmer would have to
> search for a pre-existing solution, likely in Fortran, then
> code it up in C.
-snip-

Once upon a time the Haskell guys repeated the excuse that the
shootout problems were designed to make C look good and make Haskell
look bad, then along came some exceptionally awesome Haskell
programmers who didn't see any reason why they couldn't write good
programs for those problems.

Incidentally, did you intend your comment to convey more than your
empty contempt for anyone who would program in C? I've never done it
myself - my hands are clean :-)

James Van Buskirk wrote:

> The shootout rules are designed for C programmers, not Fortran
> programmers.  Whereas a Fortran programmer would look at a
> problem statement, carry out some analysis, then compose a
> brilliant innovative solution, a C programmer would have to
> search for a pre-existing solution, likely in Fortran, then
> code it up in C.

<snip />

You sure say a lot of nonsense in that post. From the imaginary class
difference between Fortran programmers and C programmers and the imaginary
border which separates both groups, to the claim that C is " an assembly
language for a long-dead CPU", not to mention that ridiculous assertion
about the learning curve of both languages. For a troll you sure put up a
whole lot of efford into that post.


Rui Maciel

On 6 Jul, 02:49, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
wrote:
....
> > ... he might also want to use a compiler better than a very early
> > version of g95. You'd have to go out of your way to try to make
> > this "comparison" less useful.
>
> Indeed.

I think you are both missing the point. The OP had not received an
answer to his query for comparison between C (which he already knows)
and Fortran. He didn't want to learn Fortran unless it would yield a
significant performance improvement. In the absence of a better answer
I think the shootout tests are relevant, if only for showing that a)
the difference in speed depends on the test, and b) the difference for
numerical calcs - albeit with the versions the shootout covers - is
not great. I grant you that the real answers depend on much more but
in the absence of that I think the tests do justify the OP in sticking
with C and not investing the time in Fortran. (My other suggestion was
more thorough: to code a sample routine in both and time them. He
could do that if he has the time.)

Rui Maciel <rui.maciel@gmail.com> writes:

> James Van Buskirk wrote:
>
>> The shootout rules are designed for C programmers, not Fortran
>> programmers. �Whereas a Fortran programmer would look at a
>> problem statement, carry out some analysis, then compose a
>> brilliant innovative solution, a C programmer would have to
>> search for a pre-existing solution, likely in Fortran, then
>> code it up in C.
>
> <snip />
>
> You sure say a lot of nonsense in that post. From the imaginary class
> difference between Fortran programmers and C programmers and the imaginary
> border which separates both groups, to the claim that C is " an assembly
> language for a long-dead CPU", not to mention that ridiculous assertion
> about the learning curve of both languages. For a troll you sure put up a
> whole lot of efford into that post.
>
>
> Rui Maciel

Come on!  It was funny!


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.

Wade Ward wrote:

> I think it's funny how people look for speed in one blindingly-fast language 
> as opposed to another.  You might think that it might come from the people 
> 30 years ago for whom computing was a lot of time and money, but it's not. 
> It's usually asked by newcomers to a syntax.

As blindingly fast as they are, there are still interesting problems to 
solve that take a week or a month of computer time.  At those 
timescales, a difference of even 10% is significant.

In article <1183747422.601285.185940@w3g2000hsg.googlegroups.com>,
James Harris  <james.harris.1@googlemail.com> wrote:

>I think you are both missing the point.

.... I wasn't addressing that point. I was addressing a different one.

The tests you suggest are so unreliable that I wouldn't draw any
conclusion from them. That's the different point.

As for the OP, I'd write in C if he's comfortable in C. But it's
likely that he's wanting 128 bit FP for the wrong reason. Which may be
yet another example of why answering the question can often be
unhelpful, because the question was the wrong one.

I have run into customers who wanted 128 bit fp for the right
reason. But they're very rare.

-- greg

In article <468e90fa$0$63186$a726171b@news.hal-pc.org>,
Craig Powers  <enigma@hal-pc.org> wrote:

>As blindingly fast as they are, there are still interesting problems to 
>solve that take a week or a month of computer time.  At those 
>timescales, a difference of even 10% is significant.

Not to mention the interesting problems that take a year on 10,000
node machines. 10% of $50 million dollars is real money. You guys did
note that this thread is cross-posted to comp.lang.fortran, right?

-- greg

Greg Lindahl wrote:
> In article <468e90fa$0$63186$a726171b@news.hal-pc.org>,
> Craig Powers  <enigma@hal-pc.org> wrote:
> 
>> As blindingly fast as they are, there are still interesting problems to 
>> solve that take a week or a month of computer time.  At those 
>> timescales, a difference of even 10% is significant.
> 
> Not to mention the interesting problems that take a year on 10,000
> node machines. 10% of $50 million dollars is real money. You guys did
> note that this thread is cross-posted to comp.lang.fortran, right?

I was following up on comp.lang.fortran. :)

(And yeah, 10% of $50 MM is real money, but also I would guess a lot 
rarer than 10% of a couple hundred thousand, which is also real money.)

James Giles wrote:
> Gib Bogle wrote:
>> James Giles wrote:
> ...
>>> I figured that you were being facetious.  But, the sad case is that
>>> many people would recognize it.
>>>
>>  Or not ...
> 
> It's a strange thing that on my notebook's keyboard I seem to omit
> keystrokes while typing - whole sequences of them.  Indeed, I touch
> the keys, but not hard enough to work.  The effect is most noticable
> with the omission of things like n't from the end of words.  Or 's
> when possessive is intended.  I do know why (Oh, I mean don't).
> 

I've developed a special typing technique that prevents this, using just 
one finger.  :-)

Greg Lindahl wrote:
> In article <1183747422.601285.185940@w3g2000hsg.googlegroups.com>,
> James Harris  <james.harris.1@googlemail.com> wrote:
> 
>> I think you are both missing the point.
> 
> ... I wasn't addressing that point. I was addressing a different one.
> 
> The tests you suggest are so unreliable that I wouldn't draw any
> conclusion from them. That's the different point.
> 
> As for the OP, I'd write in C if he's comfortable in C. But it's
> likely that he's wanting 128 bit FP for the wrong reason. 

He has been asked by a couple of people (on different groups) what 
problem he is trying to solve, but he doesn't reply, so it's impossible 
to judge what he really needs.

Greg Lindahl <lindahl@pbm.com> wrote:

> I have run into customers who wanted 128 bit fp for the right
> reason. But they're very rare.

Same here. Most often they have an ill-posed problem, but they don't
diagnose that as the root cause. All they see is the loss of precision
and they think that adding more precision will solve it. Of course, it
won't. That's classic trying to treat the symptom instead of the
problem.

That's not always what is happening, but it sure is common. Way more
common than actually needing 128-bit floats.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

"Greg Lindahl" <lindahl@pbm.com> wrote in message 
news:468ea5bd$1@news.meer.net...
> In article <468e90fa$0$63186$a726171b@news.hal-pc.org>,
> Craig Powers  <enigma@hal-pc.org> wrote:
>
>>As blindingly fast as they are, there are still interesting problems to
>>solve that take a week or a month of computer time.  At those
>>timescales, a difference of even 10% is significant.
>
> Not to mention the interesting problems that take a year on 10,000
> node machines. 10% of $50 million dollars is real money. You guys did
> note that this thread is cross-posted to comp.lang.fortran, right?
That's the complete other side of the spectrum than the one in which the 
original question occured.  As I recall, OP was asking about a program that 
was otherwise done in matlab.

But since OP has split, I'd be interested to look at the economics of a 
project like the one you mention.  Is there an example you can give that a 
person can research on the net?
-- 
Wade Ward 

James Harris wrote:
> On 6 Jul, 02:49, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
> wrote:
> ...
>>> ... he might also want to use a compiler better than a very early
>>> version of g95. You'd have to go out of your way to try to make
>>> this "comparison" less useful.
>> Indeed.
> 
> I think you are both missing the point. The OP had not received an
> answer to his query for comparison between C (which he already knows)
> and Fortran. He didn't want to learn Fortran unless it would yield a
> significant performance improvement. In the absence of a better answer
> I think the shootout tests are relevant, if only for showing that a)
> the difference in speed depends on the test, and b) the difference for
> numerical calcs - albeit with the versions the shootout covers - is
> not great. I grant you that the real answers depend on much more but
> in the absence of that I think the tests do justify the OP in sticking
> with C and not investing the time in Fortran. (My other suggestion was
> more thorough: to code a sample routine in both and time them. He
> could do that if he has the time.)
> 
I take it that the OP did get answers and began to face reality.  The OP 
shut up after I pointed showed from actual test that software quad takes 
50 times as long as double precision on the style of laptop proposed. 
We did pry out that mpfr had been tried, as the closest 
more-than-long-double solution available in C, and found slow.

Wade Ward <invalid@invalid.nyet> wrote:

> "Greg Lindahl" <lindahl@pbm.com> wrote in message 
> news:468ea5bd$1@news.meer.net...
> > In article <468e90fa$0$63186$a726171b@news.hal-pc.org>,
> > Craig Powers  <enigma@hal-pc.org> wrote:
> >
> >>As blindingly fast as they are, there are still interesting problems to
> >>solve that take a week or a month of computer time.  At those
> >>timescales, a difference of even 10% is significant.
> >
> > Not to mention the interesting problems that take a year on 10,000
> > node machines. 10% of $50 million dollars is real money. You guys did
> > note that this thread is cross-posted to comp.lang.fortran, right?

> But since OP has split, I'd be interested to look at the economics of a
> project like the one you mention.  Is there an example you can give that a
> person can research on the net?

Computational fluid dynamics (typically abbreviated to CFD) is very much
that way. There are "interesting" problems in CFD that are multiple
orders of magnitude from practical today, even on the biggest machines.
Weather simulations, though that has many similarities to CFD. The
scales tend to be quite a bit different, but some of the same stuff
comes up. I know oil field stuff is big, though I haven't seen it first
hand. Nuclear reaction simulations.

In short, pretty much anything that involves 3D simulation of
complicated fields. Three space dimensions, plus one of time, means you
have this exponent of 4 on grid sizes. So if you want, say, a grid with
1000 points on each axis, you are dealing with a billion points. A grid
of 1000 points on each axis is way too small for many useful problems.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

glen herrmannsfeldt wrote:
> Wade Ward wrote:
> 
> (snip)
> 
>> I think it's funny how people look for speed in one blindingly-fast language 
>> as opposed to another.  You might think that it might come from the people 
>> 30 years ago for whom computing was a lot of time and money, but it's not. 
>> It's usually asked by newcomers to a syntax.
> 
> Even as computers get faster, people are more interested in fast
> hardware and fast software then 20 or 30 years ago.
> 
> I keep noticing processors that are 10% faster than the
> previous model by the same company.
> 
> 20 or 30 years ago, a new processor would be at least twice
> as fast or they wouldn't bother trying to sell it.

Today the market is much larger and much more diverse than 20-30 years
ago. And a large fraction of the market is consumers, some of which
seem to upgrade much more often than any kind of common sense suggests
is reasonable. And vendors do speed binning and market segmentation.


-- 
Janne Blomqvist

Greg Lindahl wrote:
> Torben �gidius Mogensen wrote:
> > This really depends on what you want to do.  Fortran compilers
> > typically optimize for loops over large arrays, often employing loop
> > interchange, prefetching and blocking, which few (if any?) C/C++
> > compilers do.
> 
> Eh? Lots of compilers do both Fortran and C/C++, and these compilers
> pretty much all have the same optimizations for all languages. Whether
> the compiler can see through all your pointers to effectively apply
> them is a separate issue.

On the contrary, that is precisely the issue.

> > C++ can do some of the same optimisations by carefully
> > writing template libraries that instantiate code to specific array
> > sizes.  I have heard of (at least) FFT and matrix multiply functions
> > made this way.
> 
> ... and such code is probably outperformed by ATLAS and fftw.

DDJ had an article about an FFT implementation written in C++ that used
templates to expand code and claimed to provide excellent performance. I
benchmarked it against FFTW and it was much slower in every case (contrary
to the claims in DDJ).

As the authors of FFTW well know, why bother metaprogramming in C++
templates when you can use a vastly superior language like OCaml?

> > You could also consider more modern languages like Clean, OCaml or 
> > SML. 

Amen to that. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Isaac Gouy wrote:
> Once upon a time the Haskell guys repeated the excuse that the
> shootout problems were designed to make C look good and make Haskell
> look bad, then along came some exceptionally awesome Haskell
> programmers who didn't see any reason why they couldn't write good
> programs for those problems.

Indeed, the benchmarks are so poorly designed that most can be completely
optimized away and what better language to do that than a lazy one?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Isaac Gouy wrote:
> Fortran in the benchmarks game is sadly unloved - no one's sending
> Features Requests asking for a different language implementation, no
> one's working on the programs ...
> 
> http://shootout.alioth.debian.org/gp4/faq.php#report

Several people submitted improved Fortran code for the ray tracer benchmark
that was taken down.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

On Jul 7, 6:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> Isaac Gouy wrote:
> > Fortran in the benchmarks game is sadly unloved - no one's sending
> > Features Requests asking for a differentlanguageimplementation, no
> > one's working on the programs ...
>
> >http://shootout.alioth.debian.org/gp4/faq.php#report
>
> Several people submitted improved Fortran code for the ray tracer benchmark
> that was taken down.


You make my point well - Fortran in the benchmarks game is sadly
unloved - that problem hasn't been shown for a couple of years.


>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet

Stephen Howe wrote:

> One aspect where Fortran per se, has the edge over C, is that Fortran does 
> not allow aliasing but C does.

I'm a biginning C programmer not familiar with this concept. In 
the context of the above statement, can someone show an example 
of "aliasing" in C (the sort which Fortran doesn't allow).

David Marsh <dmarsh@mail.com> wrote:

> Stephen Howe wrote:
> 
> > One aspect where Fortran per se, has the edge over C, is that Fortran does
> > not allow aliasing but C does.
> 
> I'm a biginning C programmer not familiar with this concept. In 
> the context of the above statement, can someone show an example 
> of "aliasing" in C (the sort which Fortran doesn't allow).

If you aren't familliar with the concept, odds are that you aren't
familliar with the Fortran rules related to it either. So I'll give a
Fortran example. (If I try to do it in C, I'll make a syntax error
unless I spend more time on it than I care to).

  program maine
    integer :: x(3,3)
    read(*,*) x
    call sub(x,x)
    write (*,*) x
  end program maine

  subroutine sub(x,y)
    integer :: x(3,3),y(3,3)
    integer :: i,j
    do i = 1 , 3
      do j = 1 , 3
        y(i,j) = x(j,i)
      end do
    end do
  end subroutine sub

This code is invalid Fortran. The call to sub aliases the two dummy
arguments. Aliasing is ok in some cases (people fairly often get that
wrong, stating incorrectly that aliasing is disallowed in general).
However, this is one case where it is not allowed - because one of the
aliased arguments is defined in the subroutine.

Note that compilers are *NOT* required to catch this error; indeed most
compilers probably won't. (I made the subroutine external in a
deliberate attempt to decrease the odds of it getting caught). They will
probably just generate "incorrect" answers, where I have quoted the
"incorrect" because it is not defined what a correct answer would be. It
might be better for me to say that the answer will likely be surprising.

This is a junk example for many reasons. It is just something that was
trivial to throw together off the top of my head and would probably
illustrate wrong results from aliasing.

Basically, the standard says that aliasing in this case is not allowed
and the compiler may therefore compile code without needing to worry
about the possibility. This means that the compiler has more
opportunities for optimization... or one might even say that the
compiler doesn't have to pessimize. If the standard allowed code like
this, and made it give what some might think to be the expected answers,
the compiler might be forced to do something like make a temporary copy
of the arguments... at least if that is the expected behavior. In other
cases, that would not be the behavior people would expect.

I will not comment on the Fortran vs C aspects here. I consider that
flamewar material of the kind that I decline to get involved in. I am
replying solely to give an example of what illegal aliasing is in
Fortran. It is important to know this when programming in Fortran,
completely independent of any language comparison issues.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Isaac Gouy wrote:
> On Jul 7, 6:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Isaac Gouy wrote:
>>> Fortran in the benchmarks game is sadly unloved - no one's sending
>>> Features Requests asking for a differentlanguageimplementation, no
>>> one's working on the programs ...
>>> http://shootout.alioth.debian.org/gp4/faq.php#report
>> Several people submitted improved Fortran code for the ray tracer benchmark
>> that was taken down.
> 
> 
> You make my point well - Fortran in the benchmarks game is sadly
> unloved - that problem hasn't been shown for a couple of years.

Maybe there are better things to do w/ their time????

--

David Marsh wrote:
> 
> Stephen Howe wrote:
> 
> > One aspect where Fortran per se, has the edge over C, is that Fortran does
> > not allow aliasing but C does.
> 
> I'm a biginning C programmer not familiar with this concept.

	http://en.wikipedia.org/wiki/Aliasing_%28computing%29

C evangelists like to pretend 'it doesn't really matter'.  I've seen whole
chapters on C optimizations written by otherwise credible authors that totally
ignore the impacts of aliasing and side-effects on optimization.  But it really
is a very important issue.

> In
> the context of the above statement, can someone show an example
> of "aliasing" in C (the sort which Fortran doesn't allow).

Fortran allows 'aliasing' - but only when the programmer asserts that
it is wanted.  E.g., via EQUIVALENCE in the olden days, and F90 pointers
in modern times.  So the compiler is generally free to create optimal
code.

In C, things are the other way 'round.  With its overuse of unrestricted
pointers for just about anything, data aliasing must very often be assumed,
whether it is there or not.  This can seriously inhibit optimizations an
optimizer could otherwise make.

In my experience, few C programmers are aware of C99s 'restrict'
keyword.  (Heck, most don't even know there is a C99...)  Very few
understand where 'restrict' can be used and actually bother use it.
C++ has totally ignored the issue.

Yes there are often compiler flags to tell the compiler not to worry about
aliasing.  But very often programs which are compiled this way stop working...

W.

Walter Spector wrote:
> David Marsh wrote:
>> Stephen Howe wrote:
>>
>>> One aspect where Fortran per se, has the edge over C, is that Fortran does
>>> not allow aliasing but C does.
>> I'm a biginning C programmer not familiar with this concept.
> 
> 	http://en.wikipedia.org/wiki/Aliasing_%28computing%29
> 
> C evangelists like to pretend 'it doesn't really matter'.  I've seen whole
> chapters on C optimizations written by otherwise credible authors that totally
> ignore the impacts of aliasing and side-effects on optimization.  But it really
> is a very important issue.
Microsoft compatible C compilers have all aliasing related optimization 
shut off by default, I suppose to spare their instructors from having to 
cover the subject.  Generally speaking, it is impossible for C compilers 
to generate efficient code for arrays of arrays (nearest equivalent of 
multiple dimensioned Fortran arrays) when these optimizations are 
disabled.  So, Walter is entirely correct about the importance of the 
issue.  It will bite the careless C or C++ programmer who uses gcc, for 
example.
gcc will error out on violations when it is able to detect them.  The 
case analogous to the one Richard Maine showed for Fortran, however, is 
entirely legal in C, and the compiler must not perform optimizations 
which would break with aliasing.
Both C and Fortran aliasing rules were set in the first published 
standards, but the Fortran standard has been around long enough (>40 
years) for people to get used to it.  C was not standardized until 18 
years ago. As Walter says, the textbook authors have not all caught up.

dpb wrote:

> Maybe there are better things to do w/ their time????

If your unfounded exageration was even slightly close to reality, the fact
that the entire community believes it is too much of a burden to present a
small piece of code which gives decent results... Well, that would speak
for itself.


Rui Maciel

David Marsh wrote:

> I'm a biginning C programmer not familiar with this concept. In the 
> context of the above statement, can someone show an example of 
> "aliasing" in C (the sort which Fortran doesn't allow).


       subroutine add(x,y,z,n)
       real x(n),y(n),z(n)
       do i=1,n
          x(i)=y(i)+z(i)
       enddo
       return
       end

! Fortran can assume that x is not the same array as
! (or overlaps in any way) arrays y and z.

       real a(10),b(10)
       b=3
       a=4
       call add(a,b,a,10)
       call add(a,a(3),a,5)
       call add(a(2),a,a(4),4)
       write(*,*) a
       stop
       end

-- glen

Richard Maine wrote:

(snip)

> Computational fluid dynamics (typically abbreviated to CFD) is very much
> that way. There are "interesting" problems in CFD that are multiple
> orders of magnitude from practical today, even on the biggest machines.
> Weather simulations, though that has many similarities to CFD. The
> scales tend to be quite a bit different, but some of the same stuff
> comes up. I know oil field stuff is big, though I haven't seen it first
> hand. Nuclear reaction simulations.

I agree with this, but still find it interesting that people are
more concerned about speed than they were 20 or 30 or 40 years ago.
These problems (on a smaller scale) were being done years ago, when
computer time was much more expensive.

One that I notice is much work being done to speed up subroutine
and function calls, keeping arguments in registers when
they previously would have gone on a stack or other data structure
in memory.

-- glen

Isaac Gouy wrote:
> You make my point well - Fortran in the benchmarks game is sadly
> unloved - that problem hasn't been shown for a couple of years.

Deleting the Fortran entries from your shootout doesn't make
Fortran "unloved".

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Walter Spector wrote:

(snip)

> In C, things are the other way 'round.  With its overuse of unrestricted
> pointers for just about anything, data aliasing must very often be assumed,
> whether it is there or not.  This can seriously inhibit optimizations an
> optimizer could otherwise make.

> In my experience, few C programmers are aware of C99s 'restrict'
> keyword.  (Heck, most don't even know there is a C99...)  Very few
> understand where 'restrict' can be used and actually bother use it.
> C++ has totally ignored the issue.

�We should forget about small efficiencies, say about 97% of the time: 
premature optimization is the root of all evil. Yet we should not pass 
up our opportunities in that critical 3%.�[1] - Knuth, paraphrasing 
Hoare  See:

http://en.wikipedia.org/wiki/Optimization_(computer_science)

Note that in C all functions are considered recursive, which could
also inhibit some optimizations.  It might be that unintended
aliasing in Fortran is more common than unneeded reduced
optimization in C allowing for it.

-- glen

glen herrmannsfeldt wrote:
> Richard Maine wrote:
> 
> (snip)
> 
>> Computational fluid dynamics (typically abbreviated to CFD) is very much
>> that way. There are "interesting" problems in CFD that are multiple
>> orders of magnitude from practical today, even on the biggest machines.
>> Weather simulations, though that has many similarities to CFD. The
>> scales tend to be quite a bit different, but some of the same stuff
>> comes up. I know oil field stuff is big, though I haven't seen it first
>> hand. Nuclear reaction simulations.
> 
> I agree with this, but still find it interesting that people are
> more concerned about speed than they were 20 or 30 or 40 years ago.
> These problems (on a smaller scale) were being done years ago, when
> computer time was much more expensive.
....

I don't think the people _doing_ those computations (and I was one in 
the nuclear field gosh! almost 40 yrs ago now! gee, now that I actually 
figure it, next year will be 40.  :( ) were any less concerned then than 
now.  What I think is there is a whole different class of people worried 
about speed for mostly superficial reasons that didn't have access to 
_any_ computing back then...

imo, ymmv, $0.02, etc., ...

--

Richard Maine wrote:

(snip on aliasing)

> If you aren't familliar with the concept, odds are that you aren't
> familliar with the Fortran rules related to it either. So I'll give a
> Fortran example. (If I try to do it in C, I'll make a syntax error
> unless I spend more time on it than I care to).

>   program maine
>     integer :: x(3,3)
>     read(*,*) x
>     call sub(x,x)
>     write (*,*) x
>   end program maine

>   subroutine sub(x,y)
>     integer :: x(3,3),y(3,3)
>     integer :: i,j
>     do i = 1 , 3
>       do j = 1 , 3
>         y(i,j) = x(j,i)
>       end do
>     end do
>   end subroutine sub

> This code is invalid Fortran. The call to sub aliases the two dummy
> arguments. Aliasing is ok in some cases (people fairly often get that
> wrong, stating incorrectly that aliasing is disallowed in general).
> However, this is one case where it is not allowed - because one of the
> aliased arguments is defined in the subroutine.

Yes this is illegal aliasing.  Still, it gets the wrong answer
(assuming that the goal is a matrix transpose) even if done one
element at a time, with each stored back to the original array.
Assuming one believe in pass by reference, it isn't hard to see the
problem in this case.

In addition, as far as I know aliasing is still disallowed even
in cases where one element at a time or operating on a copy of
the array and then copying it back would both give the right answer.

My previously posted:

       subroutine add(x,y,z,n)
       real x(n),y(n),z(n)
       do i=1,n
          x(i)=y(i)+z(i)
       enddo
       return
       end

If x and y are the same array, with the same offset, then it
gives the same answer with either pass by reference or pass
by value result (copy in/out).  It gives different answers with
aliasing and an offset between the starting points.

(snip)

> Basically, the standard says that aliasing in this case is not allowed
> and the compiler may therefore compile code without needing to worry
> about the possibility. This means that the compiler has more
> opportunities for optimization... or one might even say that the
> compiler doesn't have to pessimize. If the standard allowed code like
> this, and made it give what some might think to be the expected answers,
> the compiler might be forced to do something like make a temporary copy
> of the arguments... at least if that is the expected behavior. In other
> cases, that would not be the behavior people would expect.

As a more specific example, in array operations such as:

       x=y+z

the result is supposed to be the same as computing all the elements of
y+z before modifying x.  If the compiler assumed aliasing, a temporary 
array would be needed.  With aliasing disallowed the temporary isn't
needed.

On the other hand, PL/I array expressions are defined to be done one
element at a time, with the modifications visible.  If one does

       x=x+x(5);

in PL/I the modified x(5) is used for subsequent elements, unlike
in Fortran.  (This probably reduces possible optimizations.)

> I will not comment on the Fortran vs C aspects here. I consider that
> flamewar material of the kind that I decline to get involved in. I am
> replying solely to give an example of what illegal aliasing is in
> Fortran. It is important to know this when programming in Fortran,
> completely independent of any language comparison issues.

I agree.

-- glen

Rui Maciel wrote:
> dpb wrote:
> 
>> Maybe there are better things to do w/ their time????
> 
> If your unfounded exageration was even slightly close to reality, the fact
> that the entire community believes it is too much of a burden to present a
> small piece of code which gives decent results... Well, that would speak
> for itself.

Not a "burden" per se, just pointless...some vague thing about windmills 
seems to come to mind... :)

--

glen herrmannsfeldt wrote:
> ...
> �We should forget about small efficiencies, say about 97% of the time:
> premature optimization is the root of all evil. Yet we should not pass
> up our opportunities in that critical 3%.�[1] - Knuth, paraphrasing
> Hoare ...

Exactly.  In Fortran, I don't have to worry about simple things like:
"why didn't the compiler pull this seemingly invariant expression out
of the loop?".  Or "why didn't the compiler find this 'obvious' common
subexpression?"  (Answer: Because the compiler had to worry about potential
aliasing issues...)  I can concentrate on my application issues instead.

> Note that in C all functions are considered recursive, which could
> also inhibit some optimizations.  It might be that unintended
> aliasing in Fortran is more common than unneeded reduced
> optimization in C allowing for it.

Fortran allows a compiler to generate recursive code for any procedure - not
just those with the RECURSIVE attribute.  Indeed there have been some very
good Fortran compilers available, for many years, which do exactly that.
Think about it for a second:  by placing local data 'on the stack', rather
than statically allocating it, one is reducing the 'memory footprint' of the
application.  This tends to improve cache efficiency, lower paging requirements,
etc.  Nice systemwide effects.

W.

In article <468fe133$0$3456$a729d347@news.telepac.pt>,
Rui Maciel  <rui.maciel@gmail.com> wrote:

>If your unfounded exageration was even slightly close to reality, the fact
>that the entire community believes it is too much of a burden to present a
>small piece of code which gives decent results... Well, that would speak
>for itself.

Don't you think it's fair to say that 99.99% of both the C and Fortran
communities have no idea that the "shootout" exists? So if the remaining
0.01% think that using an ancient, immature version of g95 to run tests
is dumb, there you have it.

-- greg

"Richard Maine" <nospam@see.signature> wrote in message 
news:1i0vm88.ad0dvommy5v1N%nospam@see.signature...
> David Marsh <dmarsh@mail.com> wrote:
>
>> Stephen Howe wrote:
>>
>> > One aspect where Fortran per se, has the edge over C, is that Fortran 
>> > does
>> > not allow aliasing but C does.
>>
>> I'm a biginning C programmer not familiar with this concept. In
>> the context of the above statement, can someone show an example
>> of "aliasing" in C (the sort which Fortran doesn't allow).
>
> If you aren't familliar with the concept, odds are that you aren't
> familliar with the Fortran rules related to it either. So I'll give a
> Fortran example. (If I try to do it in C, I'll make a syntax error
> unless I spend more time on it than I care to).
[ code elided]
> This code is invalid Fortran. The call to sub aliases the two dummy
> arguments. Aliasing is ok in some cases (people fairly often get that
> wrong, stating incorrectly that aliasing is disallowed in general).
> However, this is one case where it is not allowed - because one of the
> aliased arguments is defined in the subroutine.
>
> Note that compilers are *NOT* required to catch this error; indeed most
> compilers probably won't. (I made the subroutine external in a
> deliberate attempt to decrease the odds of it getting caught). They will
> probably just generate "incorrect" answers, where I have quoted the
> "incorrect" because it is not defined what a correct answer would be. It
> might be better for me to say that the answer will likely be surprising.
>
> This is a junk example for many reasons. It is just something that was
> trivial to throw together off the top of my head and would probably
> illustrate wrong results from aliasing.
>
> Basically, the standard says that aliasing in this case is not allowed
> and the compiler may therefore compile code without needing to worry
> about the possibility. This means that the compiler has more
> opportunities for optimization... or one might even say that the
> compiler doesn't have to pessimize. If the standard allowed code like
> this, and made it give what some might think to be the expected answers,
> the compiler might be forced to do something like make a temporary copy
> of the arguments... at least if that is the expected behavior. In other
> cases, that would not be the behavior people would expect.
>
> I will not comment on the Fortran vs C aspects here. I consider that
> flamewar material of the kind that I decline to get involved in. I am
> replying solely to give an example of what illegal aliasing is in
> Fortran. It is important to know this when programming in Fortran,
> completely independent of any language comparison issues.
I don't care for inter-syntax flamewars either.  It brings out the worst in 
people.
  program maine1
    integer :: x(3,3)
    write (*,'(a)',advance='no') 'Give me  9 ints: '
    read(*,*) x
    call sub(x,x)
    write (*,*) x
  end program maine1

  subroutine sub(x,y)
    integer :: x(3,3),y(3,3)
    integer :: i,j
    do i = 1 , 3
      do j = 1 , 3
        y(i,j) = x(j,i)
      end do
    end do
  end subroutine sub
! end source
If it's illegal, then why aren't compilers required to at least say so?  The 
above accepts 9 ints from me and gives me 9 ints as output.  Where's the 
rub?
-- 
Wade Ward 

Greg Lindahl wrote:
> Don't you think it's fair to say that 99.99% of both the C and Fortran
> communities have no idea that the "shootout" exists? So if the remaining
> 0.01% think that using an ancient, immature version of g95 to run tests
> is dumb, there you have it.

On the contrary, the Fortran implementations of the ray tracer benchmark
that were all deleted were the fastest of all the implementations even when
compiled with g95.

The fact that they were deleted by the shootout maintainers has no bearing
on Fortran itself.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Wade Ward wrote:
....
> I don't care for inter-syntax flamewars either.  It brings out the
> worst in people.
>  program maine1
>    integer :: x(3,3)
>    write (*,'(a)',advance='no') 'Give me  9 ints: '
>    read(*,*) x
>    call sub(x,x)
>    write (*,*) x
>  end program maine1
>
>  subroutine sub(x,y)
>    integer :: x(3,3),y(3,3)
>    integer :: i,j
>    do i = 1 , 3
>      do j = 1 , 3
>        y(i,j) = x(j,i)
>      end do
>    end do
>  end subroutine sub
> ! end source

Well, even if it were legal, it would almost certainly not
produce the expected answer.  On some compilers, under
some optimization levels it *might* accidentally give the
expected answer.  But you can't count on it.  (By the way,
what answer do you expect and why?  What answer does
your code give when you test run it?)

The corresponding C code would be regarded as legal, and
would be required to give a particular answer.  But, that
answer *wouldn't* be the transpose of the numbers you typed
in!  Aliasing is usually wrong even in languages that permit it.
It's better not to permit it and allow the compiler to optimize.
At least, that should be the default behavior of the language.

> If it's illegal, then why aren't compilers required to at least say
> so?  [...]

Because the test is computationally intractable.  Consider the
following call to your very same SUB:

    program test
    integer :: a(6,3)
    write (*,'(a)',advance='no') 'Give me  9 ints: '
    read(*,*)  a(1:5:2,:)
    call sub(a(2:6:2, :), a(1:5:2, :))
    write (*,*) a
  end program test

The actual arguments interleave, but they *aren't* aliased.  The
program is comletely legal.  And that's one of the simpler cases
of non-aliased, but interleaved arguments.  How do you expect the
compiler to comprehensively test for aliased arguments in any
efficient manner?

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

Wade Ward <invalid@invalid.nyet> wrote:

> If it's illegal, then why aren't compilers required to at least say so?

This is an absolutely critical point that gets repeated here many times.
I suppose it has been a while. Time for the next repeat. :-)

There is a specific list of things that compilers are required to
detect. It is a tiny fraction of the requirements of the standard. The
general philosophy is that the compiler is required to diagnose things
that are always easily detectable at compile time. That's not the actual
rule, but that's the flavor of the motivation. There turn out to be many
rules where the simple cases are detectable at compile time, but
complicated cases aren't. The standard doesn't tend to require detection
of violation of those rules, but many compilers do detect the simple
ones.

Note that the f77 standard had *NO* required diagostics. I repeat
*NONE*. That doesn't mean that the f77 standard didn't have lots of
rules; the compiler just wasn't required to diagnose them.

Do not make the mistake of equating things that are illegal with things
that the compiler is required to diagnose. One is a rather small subset
of the other.


> The 
> above accepts 9 ints from me and gives me 9 ints as output.  Where's the
> rub?

That they are the wrong numbers?

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Walter Spector wrote:
(snip)

> Fortran allows a compiler to generate recursive code for any procedure - not
> just those with the RECURSIVE attribute.  Indeed there have been some very
> good Fortran compilers available, for many years, which do exactly that.
> Think about it for a second:  by placing local data 'on the stack', rather
> than statically allocating it, one is reducing the 'memory footprint' of the
> application.  This tends to improve cache efficiency, lower paging requirements,
> etc.  Nice systemwide effects.

In the past, it was harder to address automatic data than static data,
such as on the early Fortran processors, and even S/360.  Many now have
instructions to make stack addressing easy, though it may or may not
be faster than static addressing.

-- glen

In article <APudnR8XoKsQjQ3bnZ2dnUVZ_gadnZ2d@comcast.com>,
Wade Ward <invalid@invalid.nyet> wrote:

>If it's illegal, then why aren't compilers required to at least say so?

call sub(x,x) is illegal only if sub() does something with x and x
such that aliasing takes place. That's often impossible to figure out
unless you execute sub(), so no one even tries.

PathScale added a flag to make Fortran behave like C, and it was one
of the "throw these dozen flags to see if you've made a common mistake
before sending us a bug report" flags.

-- greg

Craig Powers wrote:
> Wade Ward wrote:
>> I think it's funny how people look for speed in one blindingly-fast
>> language
>> as opposed to another.  You might think that it might come from the
>> people 30 years ago for whom computing was a lot of time and money, but
>> it's not. It's usually asked by newcomers to a syntax.
> 
> As blindingly fast as they are, there are still interesting problems to
> solve that take a week or a month of computer time.  At those
> timescales, a difference of even 10% is significant.

On tasks that large, the bottleneck is not likely to be looping over float
arrays (the only forte of Fortran). If data structures are pivotal then
Fortran is probably the worst possible language...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

In article <46905c5c$0$8725$ed2619ec@ptn-nntp-reader02.plus.net>,
Jon Harrop  <jon@ffconsultancy.com> wrote:

>On tasks that large, the bottleneck is not likely to be looping over float
>arrays (the only forte of Fortran). If data structures are pivotal then
>Fortran is probably the worst possible language...

That is sometimes a good argument against Fortran 77. You are aware
that Fortran has changed a bit in the last 30 years?

It's always fun trying to explain to data structure-driven programmers
that sometimes a structure of arrays is better than an array of
structures. Arrays tend to vectorize better than structures, for example.

Then again, if you really think loping over float arrays is the only
forte of Fortran, then you're just another troll. Please stop
cross-posting into comp.lang.fortran.

-- greg

"Richard Maine" <nospam@see.signature> wrote in message 
news:1i0w2b8.1yg3e511o0w59vN%nospam@see.signature...
> Wade Ward <invalid@invalid.nyet> wrote:
>
>> If it's illegal, then why aren't compilers required to at least say so?
>
> This is an absolutely critical point that gets repeated here many times.
> I suppose it has been a while. Time for the next repeat. :-)
>
> There is a specific list of things that compilers are required to
> detect. It is a tiny fraction of the requirements of the standard. The
> general philosophy is that the compiler is required to diagnose things
> that are always easily detectable at compile time. That's not the actual
> rule, but that's the flavor of the motivation. There turn out to be many
> rules where the simple cases are detectable at compile time, but
> complicated cases aren't. The standard doesn't tend to require detection
> of violation of those rules, but many compilers do detect the simple
> ones.
>
> Note that the f77 standard had *NO* required diagostics. I repeat
> *NONE*. That doesn't mean that the f77 standard didn't have lots of
> rules; the compiler just wasn't required to diagnose them.
>
> Do not make the mistake of equating things that are illegal with things
> that the compiler is required to diagnose. One is a rather small subset
> of the other.
>
>
>> The
>> above accepts 9 ints from me and gives me 9 ints as output.  Where's the
>> rub?
>
> That they are the wrong numbers?
For input I used 123456789.
1 2 3
4 5 6
7 8 9
I believe.  Before I embarrass myself, I want to make sure that this is the 
input matrix.  I think it is, not because I know things about fortran, but I 
taught kids to use the mnemonic RC-cola for contemporary represention of a 
square matrix.  Actually, they taught that to me.  Is it, in this case, 
correct?
-- 
Wade Ward 

"Greg Lindahl" <lindahl@pbm.com> wrote in message 
news:469070ae$1@news.meer.net...
> In article <46905c5c$0$8725$ed2619ec@ptn-nntp-reader02.plus.net>,
> Jon Harrop  <jon@ffconsultancy.com> wrote:
>
>>On tasks that large, the bottleneck is not likely to be looping over float
>>arrays (the only forte of Fortran). If data structures are pivotal then
>>Fortran is probably the worst possible language...
>
> That is sometimes a good argument against Fortran 77. You are aware
> that Fortran has changed a bit in the last 30 years?
>
> It's always fun trying to explain to data structure-driven programmers
> that sometimes a structure of arrays is better than an array of
> structures. Arrays tend to vectorize better than structures, for example.
>
> Then again, if you really think loping over float arrays is the only
> forte of Fortran, then you're just another troll. Please stop
> cross-posting into comp.lang.fortran.
Forte's are, by their nature, singular.  F'up set.
-- 
Wade Ward 

Wade Ward <invalid@invalid.nyet> wrote:

> "Richard Maine" <nospam@see.signature> wrote in message 
> news:1i0w2b8.1yg3e511o0w59vN%nospam@see.signature...
> > Wade Ward <invalid@invalid.nyet> wrote:
> >> The
> >> above accepts 9 ints from me and gives me 9 ints as output.  Where's the
> >> rub?
> >
> > That they are the wrong numbers?
> For input I used 123456789.
> 1 2 3
> 4 5 6
> 7 8 9

How did you manage to get output like that from the program as shown and
with input like that? If you ran some different program, then I can't
usefully comment without seeing what you actully ran. If this isn't he
actual input and output, then I can't comment based on that either.

Um. Oh. Strike the above. I see. Or I think I do. You aren't even
showing an output at all... I don't think. But then I'm afraid I don't
understand your question at all. It doesn't even sound like you are
asking about anything related to what the program is doing with the
data, but just about the read statement, which is a pretty unrelated
subject. Perhaps I still misunderstand. Anyway...

The program as shown used list-directed input and output. With
list-directed input, your 123456789 should have been interpreted as a
single (largish) number and then given an end-of-file error. If I
interpret you to have meant 1 2 3 4 5 6 7 8 9, then no, that does not
result in the above matrix. I'm afraid I don't understand the RC-cola
allusion; I suppose the R and C probably have something to do with rows
and columns, but that doesn't help me. In any case, though I don't
understand the mnemonic, I do understand the Fortran. That input would
give an array

  1 4 7
  2 5 8
  3 6 9

That's just the input, before calling the subroutine.

When *I* ran the program, using g95 on my Mac, the input of

  1 2 3 4 5 6 7 8 9

gave an output of

  1 2 3 2 5 6 3 6 9

I didn't actually go through and check by hand whether this is the
output I would expect, but it is plausible at first glance. It  doesn't
look much like a transpose; note among other things that some numbers
appear twice and others not at all. This output represents the array

   1 2 3
   2 5 6
   3 6 9

Of course, since the program is illegal, *ANY* output would be "valid"
for a standard-conforming compiler to produce.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

"Richard Maine" <nospam@see.signature> wrote in message 
news:1i0wnfh.1oh7lf61epwydtN%nospam@see.signature...
> Wade Ward <invalid@invalid.nyet> wrote:
>
>> "Richard Maine" <nospam@see.signature> wrote in message
>> news:1i0w2b8.1yg3e511o0w59vN%nospam@see.signature...
>> > Wade Ward <invalid@invalid.nyet> wrote:
>> >> The
>> >> above accepts 9 ints from me and gives me 9 ints as output.  Where's 
>> >> the
>> >> rub?
>> >
>> > That they are the wrong numbers?
>> For input I used 123456789.
>> 1 2 3
>> 4 5 6
>> 7 8 9
>
> How did you manage to get output like that from the program as shown and
> with input like that? If you ran some different program, then I can't
> usefully comment without seeing what you actully ran. If this isn't he
> actual input and output, then I can't comment based on that either.
>
> Um. Oh. Strike the above. I see. Or I think I do. You aren't even
> showing an output at all... I don't think. But then I'm afraid I don't
> understand your question at all. It doesn't even sound like you are
> asking about anything related to what the program is doing with the
> data, but just about the read statement, which is a pretty unrelated
> subject. Perhaps I still misunderstand. Anyway...
>
> The program as shown used list-directed input and output. With
> list-directed input, your 123456789 should have been interpreted as a
> single (largish) number and then given an end-of-file error. If I
> interpret you to have meant 1 2 3 4 5 6 7 8 9, then no, that does not
> result in the above matrix. I'm afraid I don't understand the RC-cola
> allusion; I suppose the R and C probably have something to do with rows
> and columns, but that doesn't help me. In any case, though I don't
> understand the mnemonic, I do understand the Fortran. That input would
> give an array
>
>  1 4 7
>  2 5 8
>  3 6 9
>
> That's just the input, before calling the subroutine.
>
> When *I* ran the program, using g95 on my Mac, the input of
>
>  1 2 3 4 5 6 7 8 9
>
> gave an output of
>
>  1 2 3 2 5 6 3 6 9
>
> I didn't actually go through and check by hand whether this is the
> output I would expect, but it is plausible at first glance. It  doesn't
> look much like a transpose; note among other things that some numbers
> appear twice and others not at all. This output represents the array
>
>   1 2 3
>   2 5 6
>   3 6 9
>
> Of course, since the program is illegal, *ANY* output would be "valid"
> for a standard-conforming compiler to produce.
I get the same output: 123256369 .  If this is the transpose of the input, 
with errors, then I do think that an input of 123456789 is, for this read:
1 4 7
2 5 8
3 6 9
, which maps to:
>   1 2 3
>   2 5 6
>   3 6 9 .
-- 
Wade Ward 

Greg Lindahl wrote:

> Don't you think it's fair to say that 99.99% of both the C and Fortran
> communities have no idea that the "shootout" exists? So if the remaining
> 0.01% think that using an ancient, immature version of g95 to run tests
> is dumb, there you have it.

It seems you've entirely missed the point. The claim made by "dpb" was not
that the whole Fortran community (whatever that is) doesn't know about the
existence of the "shootout" project. The claim was that it actively refused
to contribute to it due to having "better things to do w/ their time". That
scenario does not hold any resemblance to reality and is very very silly,
to say the least.


Rui Maciel

Vista wrote:
> Please, allow me to ask this naive question...

The question implied by the title of your post, of course, is a naive
one; and the answer is, of course, that one *language* is not
intrinsically faster than another.

A good BASIC compiler could be faster than a poor FORTRAN compiler.
But usually FORTRAN is implemented by very good compilers, and BASIC
is implemented by slow interpreters.

> Now, speed if critical for my application. If somebody tells me that
> Fortran's support of Quadruple precision is about 10% faster than any other
> quadruple solution in any other libraries in C/C++, then I am going to turn
> to Fortran.
>
> If the consensus is that Fortran for numerical calculations is only 5%
> faster than C/C++, then I won't bother turn to Fortran.

FORTRAN is faster than C for *single* precision - that is one
generalization that is almost always true. That's because,
conventionally, the math libraries for c only provide things like sin,
cos, log and so on in double precision. They don't figure you would
need faster single-precision versions of those functions for anything.

Calling a *subroutine* every time you want to perform a *single
machine instruction* - to multiply or divide 128-bit floats, as _some_
chips supporting the newest changes to the IEEE-754 standard now
support, has *got* to be really slow.

But any generalizations we make about "FORTRAN" and "C" aren't going
to answer the question if you're in that situation or not. You'll have
to look at the specs for...

the chip in your computer,

and the FORTRAN compiler available to you

to figure out if you will make gains of 200% by going to FORTRAN, or
not even 5%.

John Savard

Gary Scott wrote:
> It has always been disappointing to me that VAX-on-a-chip or Harris
> H-series-on-a-chip never caught on.  Was there something fundamentally
> flawed in those mini architectures that didn't translate well?
..
In the case of the VAX, DEC seemed to think so, which was why it put
the Alpha on a chip instead.

The DEC Alpha chip was a RISC design, praised as perhaps one of the
highest-performing RISC designs; the VAX was a CISC design, perhaps as
complex as a CISC design could get (in the real world*, that is).

The Harris H-series computers were derived from the Datacraft 6024. As
a 24-bit computer, it belongs to a genre to which I have a certain
general sentimental attachment (except for their execrable floating-
point formats).

The problem there was one of history.

First, there were 8-bit microprocessors.

Then, gradually, the 16-bit microprocessors emerged. One of the first
was the Texas Instruments 9900, which cheated a bit by not having the
registers on-chip. Big-endian, twice the registers, half the
addressing modes, but boy, it still looked a lot like a PDP-11. Then
more conventional 16-bit microprocessors came along. The Intel 8086,
which made an effort to look a lot like an 8-bit 8080. The Motorola
68000, which was a cleaner design, but which was expensive at first
and of limited availability.

So the 68000 first started out in workstations, while the 8086 came
out in 8088 form - the 8086 SX, if you will - and took over the world.

A 24-bit microprocessor would have been possible *after* a 16-bit
microprocessor. At that point, people would ask "what's the point",
since the 8087 already showed that it would be possible to, in an
*upwards-compatible* manner, go from 16-bit mini-like performance to
full-bore mainframe, like the IBM 360, performance with those popular
architectures.

To me, the tragedy is that we lost the 68000. ColdFire doesn't cut it,
because it doesn't have the support for full base-index addressing
that came in with the 68020. Recent high-megahertz versions of the
PowerPC are all very nice, but since that platform seems to have been
abandoned...

Oh, yes. I was doing a search on ClearPath recently.

Unisys has dropped making its own CMOS chips supporting the 1107 and
Burroughs architectures. Its current ClearPath machines use Intel
processors exclusively.

Which is something like if IBM decided to take the route that it's
suing Platform Solutions for. Except that ClearPath is using Xeon and
not Itanium chips, so they're taking very much the same route as the
Macintosh. (But then, there are Xeon Itaniums as well as Xeon
Pentiums, if I'm not mistaken...)

John Savard

*those who've seen my pages at

http://www.quadibloc.com/arch/arcint.htm

will know why this qualification is required. If only an architecture
like this had become the standard - it would have had native support
for 36-bit data formats, and Unisys would have been much better off,
legacy software taking a much smaller performance hit.

Rui Maciel wrote:
> Greg Lindahl wrote:
> 
>> Don't you think it's fair to say that 99.99% of both the C and Fortran
>> communities have no idea that the "shootout" exists? So if the remaining
>> 0.01% think that using an ancient, immature version of g95 to run tests
>> is dumb, there you have it.
> 
> It seems you've entirely missed the point. The claim made by "dpb" was not
> that the whole Fortran community (whatever that is) doesn't know about the
> existence of the "shootout" project. The claim was that it actively refused
> to contribute to it due to having "better things to do w/ their time". That
> scenario does not hold any resemblance to reality and is very very silly,
> to say the least.

No more silly than the claim the "shootout" is of any significance..

--

Quadibloc wrote:
> Vista wrote:
>> Please, allow me to ask this naive question...
> 
> The question implied by the title of your post, of course, is a naive
> one; and the answer is, of course, that one *language* is not
> intrinsically faster than another.
> 
> A good BASIC compiler could be faster than a poor FORTRAN compiler.
> But usually FORTRAN is implemented by very good compilers, and BASIC
> is implemented by slow interpreters.
> 
>> Now, speed if critical for my application. If somebody tells me that
>> Fortran's support of Quadruple precision is about 10% faster than any other
>> quadruple solution in any other libraries in C/C++, then I am going to turn
>> to Fortran.
>>
>> If the consensus is that Fortran for numerical calculations is only 5%
>> faster than C/C++, then I won't bother turn to Fortran.
> 
> FORTRAN is faster than C for *single* precision - that is one
> generalization that is almost always true. That's because,
> conventionally, the math libraries for c only provide things like sin,
> cos, log and so on in double precision. They don't figure you would
> need faster single-precision versions of those functions for anything.
> 
This digresses in another direction from the topics of this thread.  The 
C float math functions have been defined in the standard for 18 years, 
and required for 7 years.  That's one standard requirement which is 
observed by most C implementations, even those using newlib. Microsoft 
is a bit strange, with the float functions visible by default only in 
C++.  We still see code which mixes data types by invoking double typed 
functions in float code.  This was reasonable on popular platforms of 10 
years ago.  Type generic functions aren't widely used, but OP didn't 
make that an obstacle.  Anyway, it would be difficult to find a current 
C compiler which agrees with your statement.  OP did not make a 
restriction to compilers of 20 years ago, although there were some 
nonsensical restrictions.
Closer to the original topic, C compilers aren't required to support 
long double as a data type distinct from double, even on platforms which 
have hardware support for it.  You have even situations where the same 
compiler on the same hardware supports it one one OS and not on another. 
   It wasn't clear whether OP had restrictions on choice of OS, though 
there was a stated preference for C. Nor does the Fortran standard 
require implementations to have an efficient quad precision, as OP 
hoped, although many do have it to the extent the hardware supports.  OP 
made it clear he was unwilling to consider the implications of choice of 
hardware.

dpb wrote:
> Rui Maciel wrote:
> 
>> Greg Lindahl wrote:
>>
>>> Don't you think it's fair to say that 99.99% of both the C and Fortran
>>> communities have no idea that the "shootout" exists? So if the remaining
>>> 0.01% think that using an ancient, immature version of g95 to run tests
>>> is dumb, there you have it.
>>
>>
>> It seems you've entirely missed the point. The claim made by "dpb" was 
>> not
>> that the whole Fortran community (whatever that is) doesn't know about 
>> the
>> existence of the "shootout" project. The claim was that it actively 
>> refused
>> to contribute to it due to having "better things to do w/ their time". 
>> That
>> scenario does not hold any resemblance to reality and is very very silly,
>> to say the least.
> 
> 
> No more silly than the claim the "shootout" is of any significance..

Yeah, that was the key point.  Nearly everyone recognized it as a waste 
of time.

> 
> -- 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Greg Lindahl wrote:
> That is sometimes a good argument against Fortran 77. You are aware
> that Fortran has changed a bit in the last 30 years?

Yes.

> It's always fun trying to explain to data structure-driven programmers
> that sometimes a structure of arrays is better than an array of
> structures. Arrays tend to vectorize better than structures, for example.

Google for immutable trees.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

In article <1183897035.435215.104530@x35g2000prf.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:

>In the case of the VAX, DEC seemed to think so, which was why it put
>the Alpha on a chip instead.

You're batting 0.000 these days. DEC put both the VAX and the PDP-11
on a single chip. However, this is pretty much off-topic for both
groups it's posted in.

- greg

In article <46912388$0$8744$ed2619ec@ptn-nntp-reader02.plus.net>,
Jon Harrop  <jon@ffconsultancy.com> wrote:
>Greg Lindahl wrote:
>> That is sometimes a good argument against Fortran 77. You are aware
>> that Fortran has changed a bit in the last 30 years?
>
>Yes.

OK, so you don't make any sense. Bye!

-- g

Greg Lindahl wrote:
> In article <46912388$0$8744$ed2619ec@ptn-nntp-reader02.plus.net>,
> Jon Harrop  <jon@ffconsultancy.com> wrote:
>>Greg Lindahl wrote:
>>> That is sometimes a good argument against Fortran 77. You are aware
>>> that Fortran has changed a bit in the last 30 years?
>>
>>Yes.
> 
> OK, so you don't make any sense.

The improvements made to Fortran over the past 30 years are mundane and
insignificant compared to the features adopted by other languages. Garbage
collection, regular expressions, metaprogramming, pattern matching and so
on.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Jon Harrop writes:

> The improvements made to Fortran over the past 30 years are mundane and
> insignificant

Classic unsubstantiated and erroneous claim.

You're obviously unaware of the improvements made to Fortran.

It never ceases to amaze me how readily some people make complete fools
of themselves with their public pronouncements, as you just did, Harrop.

> I thought the 11/780 had an option, i.e., a hardware card that
> plugged into the Masbus(?), that implemented H-float.  Do I
> misremember?

Somewhat. The 78x had WCC - writeable control store - and that could be used 
to implement H float in microcode on the hardware. Or you could write your own 
instructions....

	Jan

On Jul 7, 10:51 am, dpb <n...@non.net> wrote:
> Isaac Gouy wrote:
> > On Jul 7, 6:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> Isaac Gouy wrote:
> >>> Fortran in the benchmarks game is sadly unloved - no one's sending
> >>> Features Requests asking for a differentlanguageimplementation, no
> >>> one's working on the programs ...
> >>>http://shootout.alioth.debian.org/gp4/faq.php#report
> >> Several people submitted improved Fortran code for the ray tracer benchmark
> >> that was taken down.
>
> > You make my point well - Fortran in the benchmarks game is sadly
> > unloved - that problem hasn't been shown for a couple of years.
>
> Maybe there are better things to do w/ their time????

I expect so, there are many better things to do with ones time :-)

On Jul 7, 3:18 pm, Jon Harrop <j...@ffconsultancy.com> wrote:

> On the contrary, the Fortran implementations of the ray tracer benchmark
> that were all deleted were the fastest of all the implementations even when
> compiled with g95.
>
> The fact that they were deleted by the shootout maintainers has no bearing
> on Fortran itself.

That must be a special Jon Harrop fact.

For those interested in the more usual kind of fact, the fact is that
we have programs for 41 obsolete problems in CVS, and we have been
showing programs for the same 19 active problems for about the last 2
years.


On Jul 7, 12:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>  Deleting the Fortran entries from your shootout doesn't make
>  Fortran "unloved".

That's just malicious gossip - no one deleted Fortran entries from the
shootout.

On Jul 8, 5:47 pm, Jon Harrop <j...@ffconsultancy.com> wrote:

<snip>

> The improvements made to Fortran over the past 30 years are mundane and
> insignificant compared to the features adopted by other languages. Garbage
> collection, regular expressions, metaprogramming, pattern matching and so
> on.

In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
"everywhere", and they cannot leak memory (unless there is a compiler
bug). So I think F2003 has the benefits of a language with garbage
collection.

Operations on multidimensional arrays and array sections may be
"mundane", but they are features that many working scientific
programmers (including myself) will actually use and are missing from
many other languages.

On Jul 10, 8:39 pm, Isaac Gouy <igo...@yahoo.com> wrote:

<snip>

> > > You make my point well - Fortran in the benchmarks game is sadly
> > > unloved - that problem hasn't been shown for a couple of years.
>
> > Maybe there are better things to do w/ their time????
>
> I expect so, there are many better things to do with ones time :-)

Could you add gfortran (part of gcc) as a Fortran implementation? The
codes compiled with g95 should also run with gfortran, and gfortran is
faster -- see http://www.polyhedron.com/pb05/linux/f90bench_p4.html .

Isaac Gouy wrote:
> On Jul 7, 12:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>  Deleting the Fortran entries from your shootout doesn't make
>>  Fortran "unloved".
> 
> That's just malicious gossip - no one deleted Fortran entries from the
> shootout.

e.g. where's the Fortran ray tracer gone?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Beliavsky wrote:
> In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
> "everywhere", and they cannot leak memory (unless there is a compiler
> bug). So I think F2003 has the benefits of a language with garbage
> collection.

Can you represent arbitrary (cyclic) graphs with automatic collection in
Fortran 2003?

> Operations on multidimensional arrays and array sections may be
> "mundane", but they are features that many working scientific
> programmers (including myself) will actually use and are missing from
> many other languages.

True.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

"Jon Harrop" <jon@ffconsultancy.com> wrote in message 
news:46951c86$0$1591$ed2619ec@ptn-nntp-reader02.plus.net...
> Beliavsky wrote:
>> In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
>> "everywhere", and they cannot leak memory (unless there is a compiler
>> bug). So I think F2003 has the benefits of a language with garbage
>> collection.
>
> Can you represent arbitrary (cyclic) graphs with automatic collection in
> Fortran 2003?
Let's make the question scientific.  If you show me pseudosource in C, I'll 
show you pseudosource in fortran.  To heck with this saber-rattling about 
some contest that a lot of no ones paid attention to.

We don't talk too much about mathematical morphologies in c.l.f., which I 
don't really mind.  There's two things that appeal to me about this problem:
a)  it gives me an excuse to talk to Dr. Goldman.  He has more of Dr. Rota's 
originals than anyone I know of.
b)  I don't have a 2003 compiler.  Not many people do.  It's similar to C99 
like that but I think there are different reasons for this.  Joe Usenet 
can't get a hold of one right now.  My guess is that they are working out 
issues pretty close to the ones that arise in such an inter-syntax 
comparison.  No one in c.l.f. can hold my fat to the fire for failing when 
my involvement is necessarily something less than hands-on.

Remember, I'm asking for the pseudosource, not the source.  When I left C, I 
vowed that I would read pointer-infested slop no more, forever.  That may 
sound like a prelude to a flame, but it is not so intended.  I want to solve 
the posed problem.
-- 
Cheers, merl 

On 2007-07-11 15:02:42 -0300, Jon Harrop <jon@ffconsultancy.com> said:

> Beliavsky wrote:
>> In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
>> "everywhere", and they cannot leak memory (unless there is a compiler
>> bug). So I think F2003 has the benefits of a language with garbage
>> collection.

ALLOCATABLE is an attribute in Fortran that comes with restrictions when
viewed as pointer based storage but high usability for many applications.
ALLOCATABLE and POINTER are different attributes in Fortran. Fortran 2003
has relaxed the restrictions on ALLOCATABLE compared to Fortran 95 so that
many uses of POINTER to overcome the earlier restrictions are no longer
needed and thus ALLOCATABLE has become more useful. One of the effects of
the restrictions is that there are no cycles in the use of ALLOCATABLE
storage. The usual statement is that Fortran 95 had been overly cautious
in the specification of ALLOCATABLE with Fortran 2003 more realistic.

ALLOCATABLE is for flexible sized storage that lives within the usual
scopes.

> Can you represent arbitrary (cyclic) graphs with automatic collection in
> Fortran 2003?

There is also an ability to ALLOCATE storage for POINTERs and the user
is free to be as foolish as the user cares to be just like most uses
of pointer based allocation schemes. At least one vendor has a
garbage collector for use with such storage. Garbage collection is
compatible with the Fortran standard but is not required by the standard.

POINTERs are for the furry objects that one learns about in a first
course in Algorithms and Data Structures in Computer Science undergraduate
school. There are often of less use than the introductory advertising.

Fortran POINTERs also do slices and other things as they are more
descriptors than merely machine addresses.

>> Operations on multidimensional arrays and array sections may be
>> "mundane", but they are features that many working scientific
>> programmers (including myself) will actually use and are missing from
>> many other languages.
> 
> True.

Gordon Sande wrote:
....
> [...]                                             Garbage collection is
> compatible with the Fortran standard but is not required by the
> standard.

On the other hand, I think garbage collection is *not* compatible
with C.  (Doesn't C explicitly allow pointers to be cast to ints,
held in that form for a while, and cast back to pointers?   Hence
any garbage collect will not be able to find all potentially
active memory references).

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 

On Jul 11, 8:09 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> Gordon Sande wrote:
>
> ...
>
> > [...]                                             Garbage collection is
> > compatible with the Fortran standard but is not required by the
> > standard.
>
> On the other hand, I think garbage collection is *not* compatible
> with C.  (Doesn't C explicitly allow pointers to be cast to ints,
> held in that form for a while, and cast back to pointers?   Hence
> any garbage collect will not be able to find all potentially
> active memory references).
>

Well, there are certainly problems, but conservative collectors like
the Boehm collector for C (see Google) are very successful in practice
despite the theoretical problems.  They look at all possible words and
trace anything that might possibly be a pointer.  It turns out that
the Boehm "might possibly" test doesn't make many mistakes in most
programs, so the collector doesn't miss much garbage.

merl the perl wrote:
> "Jon Harrop" <jon@ffconsultancy.com> wrote in message
> news:46951c86$0$1591$ed2619ec@ptn-nntp-reader02.plus.net...
>> Can you represent arbitrary (cyclic) graphs with automatic collection in
>> Fortran 2003?
>
> Let's make the question scientific.  If you show me pseudosource in C

Why C?

> b)  I don't have a 2003 compiler.  Not many people do.  It's similar to
> C99 like that

I've used C99 and its compilers a few times now. It is very good, IMHO.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

James Giles <jamesgiles@worldnet.att.net> wrote:

> Gordon Sande wrote:
> ...
> > [...]                                             Garbage collection is
> > compatible with the Fortran standard but is not required by the
> > standard.
> 
> On the other hand, I think garbage collection is *not* compatible
> with C.  (Doesn't C explicitly allow pointers to be cast to ints,
> held in that form for a while, and cast back to pointers?   Hence
> any garbage collect will not be able to find all potentially
> active memory references).

I can't answer the C question (wel, not without spending more time
researching it than I care to). I'll note that I had exactly that kind
of problem once in Fortran using TRANSFER to copy the bits of a pointer
to temporary storage in an array of integers. The garbage collector
trashed that program. Fortunately, I was able to turn the garbage
collector off. Although I did not turn it in as a bug report, an
acquaintance who worked for the vendor later suggested that if I had
made my temporary storage a pointer (even though it would have been a
pointer to the wrong type, and thus still needed the TRANSFER), the
garbage collector would have left it alone.

I know the style of coding I used there was at least questionable in
terms of the standard. More likely I was past the bounds of the
standard. I subsequently abandoned that practice.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Gene wrote:
> Well, there are certainly problems, but conservative collectors like
> the Boehm collector for C (see Google) are very successful in practice
> despite the theoretical problems.

No, they aren't. Several companies tried to commercialize the idea and
either went bust or had to move onto more lucrative areas. Several major
open source development projects have or are ditching Boehm's GC for
various reasons.

> They look at all possible words and 
> trace anything that might possibly be a pointer.  It turns out that
> the Boehm "might possibly" test doesn't make many mistakes in most
> programs, so the collector doesn't miss much garbage.

It does, however, cause segfaults on valid C/C++ code by deallocating memory
when it is still used (e.g. when memory is referenced by offset) and it is
much slower than most exact GCs.

http://www.mail-archive.com/guile-devel%40gnu.org/msg01726.html
http://caml.inria.fr/pub/ml-archives/caml-list/2004/08/4fe9279ff78ac69ff552ffde06ca6efa.fr.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

James Giles wrote:
(snip)

> On the other hand, I think garbage collection is *not* compatible
> with C.  (Doesn't C explicitly allow pointers to be cast to ints,
> held in that form for a while, and cast back to pointers?   Hence
> any garbage collect will not be able to find all potentially
> active memory references).

I don't believe garbage collection is disallowed, nor does
C require pointers to cast to int and back.  C allows casting
of pointers to int and back, but doesn't guarantee the ability
to do so, nor the result of doing it.  In other words, the
standard allows one to write non-portable programs.

Among other reasons, C doesn't guarantee that a pointer will
fit in an int, or any size of integer.  C allows pointers to
include other information, such as bounds information.

-- glen

In article <bISdnbPgXe8IDAjbnZ2dnUVZ_sSmnZ2d@comcast.com>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> James Giles wrote:
> 
> > On the other hand, I think garbage collection is *not* compatible
> > with C.  (Doesn't C explicitly allow pointers to be cast to ints,
> > held in that form for a while, and cast back to pointers?   Hence
> > any garbage collect will not be able to find all potentially
> > active memory references).
> 
> I don't believe garbage collection is disallowed, nor does
> C require pointers to cast to int and back.  C allows casting
> of pointers to int and back, but doesn't guarantee the ability
> to do so, nor the result of doing it.  In other words, the
> standard allows one to write non-portable programs.
> 
> Among other reasons, C doesn't guarantee that a pointer will
> fit in an int, or any size of integer.  C allows pointers to
> include other information, such as bounds information.

Of course the C standard has as many nooks and crannies as the
Fortran standard, but I'm fairly confident of the following:

 - C does not disallow garbage collection by fiat, but it does
   make life difficult for the implementor.

 - C, indeed, does not require that a data pointer fit within any
   integer type.  (If it does, then these integer types should be
   named intptr_t and uintptr_t.)

 - C does, however, require that a data pointer fix within a
   variable of the form:
        unsigned char   holder [sizeof (void *)];
   and the bits can be reliably copied in and out via the moral
   equivalent of:
        memcpy (holder, &dataptr, sizeof holder);
        memcpy (&dataptr, holder, sizeof dataptr);

Thus, it is possible for a conforming application program to copy
the contents of a data pointer to an opaque container and copy
that container outside of the process's address space (where it
presumably can be neither located nor examined by the GC).  It could
then later transfer those bits back into a data pointer of the
appropriate type and expect to read valid data by dereferencing
that pointer.  (This is assuming, of course, that the data has
not become undefined by, for example, going out of scope in the
meantime.)

Note that there are garbage collectors for C (the one by Hans Boehm
likely being the most popular).  Many of these GCs implement
conservative collection algorithms:  they perform program analysis
(both static and dynamic) and, if they suspect that the address
of a data block has become hidden from them, they will not garbage
collect that data.  I can't prove it, but I believe that for all
of these GCs, there still exist various application actions that
are legal C but which would confuse the GC (and therefore would
cause improper run-time behavior).

 - dmw

-- 
..   Douglas Wells             .  Connection Technologies      .
..   Internet:  -sp9804- -at - contek.com-                     .

On Jul 11, 10:13 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Gene wrote:
> > They look at all possible words and
> > trace anything that might possibly be a pointer.  It turns out that
> > the Boehm "might possibly" test doesn't make many mistakes in most
> > programs, so the collector doesn't miss much garbage.
>
> It does, however, cause segfaults on valid C/C++ code by deallocating memory
> when it is still used (e.g. when memory is referenced by offset) and it is
> much slower than most exact GCs.

Thanks.  Yes.  This is the problem I've read about but haven't
encountered myself.  I'm curious about what kinds of compiler/code
combinations can lead to this.  Do you have an example?

see@signature.invalid (Douglas Wells) writes:


> Note that there are garbage collectors for C (the one by Hans Boehm
> likely being the most popular).  Many of these GCs implement
> conservative collection algorithms:  they perform program analysis
> (both static and dynamic) and, if they suspect that the address
> of a data block has become hidden from them, they will not garbage
> collect that data.  I can't prove it, but I believe that for all
> of these GCs, there still exist various application actions that
> are legal C but which would confuse the GC (and therefore would
> cause improper run-time behavior).

You can perfectly well write a C compiler that garbage-collects heap
allocated structures.  It would have to detect when pointers to the
heap are stored in other data types (even storing pointers to files
are allowed, and the C standard mandates that they are valid after
reading them back in), so you would get space leaks (but not incorrect
behaviour).  Since C code with manual allocation can have space leaks,
this is no worse than the current state, and probably better as the
space leaks are easier to avoid (just don't do bad things with
pointers).

But making a GC'ing compiler (and libraries) for C is a huge task,
which is why Boehm-style cnservative GC is used instead.

For an alternative, see Cyclone (http://cyclone.thelanguage.org/ or
http://en.wikipedia.org/wiki/Cyclone_programming_language), which is a
variant of C that has safe pointers and both GC and safe manual memory
managment.

	Torben

On 2007-07-12 02:13, Jon Harrop <jon@ffconsultancy.com> wrote:
> Gene wrote:
>> They look at all possible words and trace anything that might
>> possibly be a pointer.  It turns out that the Boehm "might possibly"
>> test doesn't make many mistakes in most programs, so the collector
>> doesn't miss much garbage.
>
> It does, however, cause segfaults on valid C/C++ code by deallocating memory
> when it is still used (e.g. when memory is referenced by offset)

I don't think this can happen in a valid C program. Pointer arithmetic
is undefined if the result point outside of the object. So something
like 


    char *p = malloc(10);
    p += 20;
    x = p[-15];

is already undefined, and if the GC frees the block between line 2 and 3
because there is no pointer pointing to it any more that's entirely
consistent with the C standard. There is one gotcha, though: A pointer
can point *just beyond* the object, so 

    char *p = malloc(10);
    p += 10;
    x = p[-5];

is conforming C code, and the GC must not free the block here. This can
be easily accomplished by always allocating one byte more than
requested.

	hp


-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

see@signature.invalid (Douglas Wells) writes:

> In article <bISdnbPgXe8IDAjbnZ2dnUVZ_sSmnZ2d@comcast.com>,
>  glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> James Giles wrote:
>> 
>> > On the other hand, I think garbage collection is *not* compatible
>> > with C.  (Doesn't C explicitly allow pointers to be cast to ints,
>> > held in that form for a while, and cast back to pointers?   Hence
>> > any garbage collect will not be able to find all potentially
>> > active memory references).
>> 
>> I don't believe garbage collection is disallowed, nor does
>> C require pointers to cast to int and back.  C allows casting
>> of pointers to int and back, but doesn't guarantee the ability
>> to do so, nor the result of doing it.  In other words, the
>> standard allows one to write non-portable programs.
>> 
>> Among other reasons, C doesn't guarantee that a pointer will
>> fit in an int, or any size of integer.  C allows pointers to
>> include other information, such as bounds information.
>
> Of course the C standard has as many nooks and crannies as the
> Fortran standard, but I'm fairly confident of the following:
>
>  - C does not disallow garbage collection by fiat, but it does
>    make life difficult for the implementor.
>
>  - C, indeed, does not require that a data pointer fit within any
>    integer type.  (If it does, then these integer types should be
>    named intptr_t and uintptr_t.)
>
>  - C does, however, require that a data pointer fix within a
>    variable of the form:
>         unsigned char   holder [sizeof (void *)];
>    and the bits can be reliably copied in and out via the moral
>    equivalent of:
>         memcpy (holder, &dataptr, sizeof holder);
>         memcpy (&dataptr, holder, sizeof dataptr);
>
> Thus, it is possible for a conforming application program to copy
> the contents of a data pointer to an opaque container and copy
> that container outside of the process's address space (where it
> presumably can be neither located nor examined by the GC).

Only by putting it in a file (C has no other portable idea of an
address space) and for that you don't need a char array.  Printing a
pointer to a stream using the "%p" format and reading it back (in the
same program execution) must work and could be used to hide a pointer
from the GC.  Similarly, just XORing your char array with something
will hide the pointer from the GC (no need for another address space)
and XORing it again is guaranteed to give you same pointer back.

A much less contrived problem is that:

  char *p = malloc(42);
  if (p) {
    p += 13;
    f(); /* does lots of allocation that triggers GC */
    free(p - 13);
  }

is standard, portable, C but it is hard for any GC to find p.

-- 
Ben.

Jon Harrop <jon@ffconsultancy.com> writes:

> merl the perl wrote:
>> "Jon Harrop" <jon@ffconsultancy.com> wrote in message
>> news:46951c86$0$1591$ed2619ec@ptn-nntp-reader02.plus.net...
>>> Can you represent arbitrary (cyclic) graphs with automatic collection in
>>> Fortran 2003?
>>
>> b)  I don't have a 2003 compiler.  Not many people do.  It's similar to
>> C99 like that
>
> I've used C99 and its compilers a few times now. It is very good,
> IMHO.

The point was that "not many people have C99" not that no one does!
You are lucky to have a C99 compiler (you seem to imply you have used
more than one!).  I am told that they do exist, but they are not common
or cheap.

-- 
Ben.

["Followup-To:" header set to comp.programming.]
On 2007-07-12 10:58, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> A much less contrived problem is that:
>
>   char *p = malloc(42);
>   if (p) {
>     p += 13;
>     f(); /* does lots of allocation that triggers GC */
>     free(p - 13);
>   }
>
> is standard, portable, C but it is hard for any GC to find p.
>

AIU the Boehm GC, it should find that p still points within the malloced
block and therefore not free the block.

	hp


-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

Jon Harrop wrote:
> Beliavsky wrote:
>> In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
>> "everywhere", and they cannot leak memory (unless there is a compiler
>> bug). So I think F2003 has the benefits of a language with garbage
>> collection.
> 
> Can you represent arbitrary (cyclic) graphs with automatic collection in
> Fortran 2003?

AFAICS, no; A cyclic graph would not be allowed under the "no-alias"
rule that applies to allocatables [*]. Secondly, the "no-alias" rule is
sort-of part of the syntax. You allocate an array, and that variable
is then the only way to reach that array. You cannot make an
allocatable variable refer to some other storage, for that you need a
pointer. I.e. you cannot make an allocatable variable point to some
other already-allocated storage. So you can use allocatables to set up
an acyclic graph, but not a cyclic one. [**]

Now, cyclic graphs can be done with pointers, but those leak if you
forget to explicitly deallocate them. Of course, nothing prevents a
compiler from implementing GC for pointer variables, but that's not
part of the language spec. Actually, now that there is the enhanced
allocatables with F2003, I wouldn't mind if a future version of the
standard would require GC for pointer variables.

[*] You can set a "target" attribute for allocatables, which makes
them eligible as targets for pointers, but well, then we're into
pointer territory.

[**] Now that I think of [*], maybe it's actually possible to create a
leak-free cyclic graph? Say (warning, untested, and I've never used
the allocatable TR features myself):

type node_t
	....
	type(node_t), pointer :: next
	type(node_t), allocatable, target :: nextd
end type

subroutine add_node (node)
  type(node_t), allocatable :: node
  allocate(node%nextd)
  node%next => node%nextd
end subroutine add_node

subroutine make_cycle (nodeA, nodeB)
  type(node_t) :: nodeA, nodeB
  if (allocated(nodeA%nextd) then
    deallocate (nodeA%nextd)
  end if
  nodeA%next => nodeB%nextd
end subroutine make_cycle

The idea being to use pointers to implement aliasing, and allocatables
for all allocations.

-- 
Janne Blomqvist

"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:

> ["Followup-To:" header set to comp.programming.]
> On 2007-07-12 10:58, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> A much less contrived problem is that:
>>
>>   char *p = malloc(42);
>>   if (p) {
>>     p += 13;
>>     f(); /* does lots of allocation that triggers GC */
>>     free(p - 13);
>>   }
>>
>> is standard, portable, C but it is hard for any GC to find p.
>>
>
> AIU the Boehm GC, it should find that p still points within the malloced
> block and therefore not free the block.

You are right.  It uses very conservative tests.  Subtracting 13 would
fool it, but that would not be valid C either.

-- 
Ben.

Ben Bacarisse wrote:
> The point was that "not many people have C99" not that no one does!
> You are lucky to have a C99 compiler (you seem to imply you have used
> more than one!).  I am told that they do exist, but they are not common
> or cheap.

That's what I don't understand: GCC is free and has supported C99 for years.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Ben Bacarisse wrote:
> You are right.  It uses very conservative tests.  Subtracting 13 would
> fool it, but that would not be valid C either.

I thought that was valid C, provided you don't dereference it?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Gene wrote:
> Thanks.  Yes.  This is the problem I've read about but haven't
> encountered myself.  I'm curious about what kinds of compiler/code
> combinations can lead to this.  Do you have an example?

The whole of the world's defacto-standard monograph on numerical computing:
Numerical Recipies. They use Fortran indexing (starting at n=1) by
subtracting 1 after every malloc (and more for multidimensional arrays!).

Most major programs have similar code and will just randomly segfault. Note
that the segfaults occur elsewhere in the program and are almost impossible
to track back to the source of the problem which is almost always a masked
pointer.

So if you're going to use Boehm, you must be very careful. It is also easy
to hit pathologically bad performance. Of course, this begs the question:
why start writing a program in C+GC when you could just write it in a
language that was designed to be GC'd...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Peter J. Holzer wrote:
> I don't think this can happen in a valid C program. Pointer arithmetic
> is undefined if the result point outside of the object. So something
> like
> 
> 
>     char *p = malloc(10);
>     p += 20;
>     x = p[-15];
> 
> is already undefined,

Are you sure that is undefined?

> and if the GC frees the block between line 2 and 3 
> because there is no pointer pointing to it any more that's entirely
> consistent with the C standard.

What about:

  char *p = malloc(10);
  p += 20;
  ...
  p -= 20;
  x = p[5];

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Jon Harrop <jon@ffconsultancy.com> writes:

> Ben Bacarisse wrote:
>> The point was that "not many people have C99" not that no one does!
>> You are lucky to have a C99 compiler (you seem to imply you have used
>> more than one!).  I am told that they do exist, but they are not common
>> or cheap.
>
> That's what I don't understand: GCC is free and has supported C99 for years.

No, it doesn't support C99 even now.  See
        http://gcc.gnu.org/c99status.html
-- 
"I don't want to learn the constitution and the declaration of
 independence (marvelous poetry though it be) by heart, and worship the
 flag and believe that there is a god and the dollar is its prophet."
--Maarten Wiltink in the Monastery

On Thu, 12 Jul 2007 16:08:11 +0100, Jon Harrop wrote:

> Ben Bacarisse wrote:
>> The point was that "not many people have C99" not that no one does! You
>> are lucky to have a C99 compiler (you seem to imply you have used more
>> than one!).  I am told that they do exist, but they are not common or
>> cheap.
> 
> That's what I don't understand: GCC is free and has supported C99 for
> years.

Not quite, I think:

http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Standards.html#Standards

Quote: "A new edition of the ISO C standard was published in 1999 as ISO/
IEC 9899:1999, and is commonly known as C99. GCC has incomplete support 
for this standard version; see http://gcc.gnu.org/gcc-4.2/c99status.html 
for details."

-- 
Lionel B

On 2007-07-12 15:30, Jon Harrop <jon@ffconsultancy.com> wrote:
> Peter J. Holzer wrote:
>> I don't think this can happen in a valid C program. Pointer arithmetic
>> is undefined if the result point outside of the object. So something
>> like
>> 
>> 
>>     char *p = malloc(10);
>>     p += 20;
>>     x = p[-15];
>> 
>> is already undefined,
>
> Are you sure that is undefined?

Yes. Section 6.5.6 Additive operators in ISO/IEC 9899:1999 only defines
pointer arithmetic within an array. p += 20 is undefined.


>> and if the GC frees the block between line 2 and 3 
>> because there is no pointer pointing to it any more that's entirely
>> consistent with the C standard.
>
> What about:
>
>   char *p = malloc(10);
>   p += 20;
>   ...
>   p -= 20;
>   x = p[5];

Same problem. You invoke undefined behaviour in line 2. After that,
anything can happen.


But I've changed my mind. It could happen if the compiler adds the
offset as an optimization. For example, a programmer could write this
completely conforming code:

char *p = malloc(1000);
for (i = 5000; i < 6000; i++) {
    p[i - 5000] = compute_something(i);
}

and the compiler could turn it into:

char *p = malloc(1000) - 5000;
for (i = 5000; i < 6000; i++) {
    p[i] = compute_something(i);
}

So the compiler needs to aware of the GC to avoid certain optimizations.

	hp


-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

Jon Harrop <jon@ffconsultancy.com> writes:

> Ben Bacarisse wrote:
>> You are right.  It uses very conservative tests.  Subtracting 13 would
>> fool it, but that would not be valid C either.
>
> I thought that was valid C, provided you don't dereference it?

No.  You can't even construct a pointer that is not within (or just
past) an object.  Posting in comp.lang.c will get you all the details
and quotes from the standard if you require them.

[I won't post another reply about C99.  I see, elsethread, that you
have been pointed to list of outstanding C99 issues in gcc.]

-- 
Ben.

"Ben Pfaff" <blp@cs.stanford.edu> wrote in message 
news:874pk9hbd6.fsf@blp.benpfaff.org...
> Jon Harrop <jon@ffconsultancy.com> writes:
>
>> Ben Bacarisse wrote:
>>> The point was that "not many people have C99" not that no one does!
>>> You are lucky to have a C99 compiler (you seem to imply you have used
>>> more than one!).  I am told that they do exist, but they are not common
>>> or cheap.
>>
>> That's what I don't understand: GCC is free and has supported C99 for 
>> years.
>
> No, it doesn't support C99 even now.  See
>        http://gcc.gnu.org/c99status.html
I think Ben's right here, and where the heck did Ben Pfaff come from?  If 
your linker doesn't complain about:
#include <stdio.h>
#include <complex.h>
int main(void)
{

printf("tja\n");
system("pause");
return 0;
}
, then your compiler has some C99 capability.  It's not always clear cut, 
unless, indeed you have a C99 compiler.
I wrote the prog just to make certain that I have the C99 capability.  The 
environment is Bloodshed dev C++ 4.9.9.2 .  You need to know to have the 
source file of type .c, then you get the c, as opposed to the c++, 
capability.  I got it off the net for free.  In return, I write the word 
Bloodshed with a capital B more often than I would otherwise.

On my primary identity, which itunes just murdered for me, I have Jacob 
Navia's lcc.  It was the environment in which I did a lot of C99 fiddling 
about.  Jacob has the distinction of being the person in c.l.c. who gets 
knocked to the ground more than any other.  I figured I'd try out the poor 
guy's stuff, and am happy that I did so.  It is free and available at a 
frenchman near you.

What's the pseudosource for this graph traversal look like?  There were many 
programming exercises in the custom edition of Applied Combinatorics with 
Problem Solving (Jackson, Thoro) from Dr. Goldman's class.  I showed that 
the hypercube was connected in C, but that feels like about a decade ago. 
I'll take a look and see if there isn't a programming  exercise from this 
text that has relevance.

This gives another opportunity to get Goldman to compile a single program in 
his entire life.  Stubborn!  He's only ever handwritten instructions to 
Turing machines in grad school.  There's twenty bucks from the profs at UM 
if I can do it.  I'll send him perl, and he won't even know what happened.
Cheers, merl

"Janne Blomqvist" <foo@bar.invalid> wrote in message 
news:slrnf9c7ti.bl4q.foo@kosh.hut.fi...
> Jon Harrop wrote:
>> Beliavsky wrote:
>>> In Fortran 2003, unlike Fortran 95, allocatable arrays can be used
>>> "everywhere", and they cannot leak memory (unless there is a compiler
>>> bug). So I think F2003 has the benefits of a language with garbage
>>> collection.
>>
>> Can you represent arbitrary (cyclic) graphs with automatic collection in
>> Fortran 2003?
>
> AFAICS, no; A cyclic graph would not be allowed under the "no-alias"
> rule that applies to allocatables [*]. Secondly, the "no-alias" rule is
> sort-of part of the syntax. You allocate an array, and that variable
> is then the only way to reach that array. You cannot make an
> allocatable variable refer to some other storage, for that you need a
> pointer. I.e. you cannot make an allocatable variable point to some
> other already-allocated storage. So you can use allocatables to set up
> an acyclic graph, but not a cyclic one. [**]
>
> Now, cyclic graphs can be done with pointers, but those leak if you
> forget to explicitly deallocate them. Of course, nothing prevents a
> compiler from implementing GC for pointer variables, but that's not
> part of the language spec. Actually, now that there is the enhanced
> allocatables with F2003, I wouldn't mind if a future version of the
> standard would require GC for pointer variables.
>
> [*] You can set a "target" attribute for allocatables, which makes
> them eligible as targets for pointers, but well, then we're into
> pointer territory.
>
> [**] Now that I think of [*], maybe it's actually possible to create a
> leak-free cyclic graph? Say (warning, untested, and I've never used
> the allocatable TR features myself):
>
> type node_t
> ....
> type(node_t), pointer :: next
> type(node_t), allocatable, target :: nextd
> end type
>
> subroutine add_node (node)
>  type(node_t), allocatable :: node
>  allocate(node%nextd)
>  node%next => node%nextd
> end subroutine add_node
>
> subroutine make_cycle (nodeA, nodeB)
>  type(node_t) :: nodeA, nodeB
>  if (allocated(nodeA%nextd) then
>    deallocate (nodeA%nextd)
>  end if
>  nodeA%next => nodeB%nextd
> end subroutine make_cycle
>
> The idea being to use pointers to implement aliasing, and allocatables
> for all allocations.
I think 16.8.1 MR&C is relevant:
When a type is extended, the new type does not inherit any of the final 
subroutines of the old type.  The new type is, however, still finalizable, 
and when it is finalized any applicable final subroutines of the old type 
are invoked on the parent component.  "Finalizable" is hard to type.
--
merl 

merl the perl said:

> 
> "Ben Pfaff" <blp@cs.stanford.edu> wrote in message
> news:874pk9hbd6.fsf@blp.benpfaff.org...
>> Jon Harrop <jon@ffconsultancy.com> writes:
>>
>>> Ben Bacarisse wrote:
>>>> The point was that "not many people have C99" not that no one does!
>>>> You are lucky to have a C99 compiler (you seem to imply you have
>>>> used
>>>> more than one!).  I am told that they do exist, but they are not
>>>> common or cheap.
>>>
>>> That's what I don't understand: GCC is free and has supported C99
>>> for years.
>>
>> No, it doesn't support C99 even now.  See
>>        http://gcc.gnu.org/c99status.html
> I think Ben's right here,

He is indeed.

> and where the heck did Ben Pfaff come from?

Stanford.

> If your linker doesn't complain about:
> #include <stdio.h>
> #include <complex.h>
> int main(void)
> {
> 
> printf("tja\n");
> system("pause");
> return 0;
> }
> , then your compiler has some C99 capability.

Um, why? printf and system are both C90 routines. I reckon I could get 
that to compile and link quite happily on Turbo C (circa 1989).


> It's not always clear
> cut, unless, indeed you have a C99 compiler.

Which the vast majority of people don't.

> I wrote the prog just to make certain that I have the C99 capability. 
> The
> environment is Bloodshed dev C++ 4.9.9.2 .

I've searched Bloodshed's Web site as best I can, but I can find no 
claims of C99 conformance.

> On my primary identity, which itunes just murdered for me, I have
> Jacob
> Navia's lcc.  It was the environment in which I did a lot of C99
> fiddling
> about.

That's odd because, again, lcc-win32 does not claim C99 conformance.

> Jacob has the distinction of being the person in c.l.c. who
> gets knocked to the ground more than any other.

Only because he doesn't know C very well (if his comp.lang.c articles 
are anything to go by).

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:

(snip)

>>#include <stdio.h>
>>#include <complex.h>
>>int main(void)
>>{

>>printf("tja\n");
>>system("pause");
>>return 0;
>>}
(snip)

> Um, why? printf and system are both C90 routines. I reckon I could get 
> that to compile and link quite happily on Turbo C (circa 1989).

I don't remember complex.h from 1989, though.

-- glen

glen herrmannsfeldt said:

> Richard Heathfield wrote:
> 
> (snip)
> 
>>>#include <stdio.h>
>>>#include <complex.h>
>>>int main(void)
>>>{
> 
>>>printf("tja\n");
>>>system("pause");
>>>return 0;
>>>}
> (snip)
> 
>> Um, why? printf and system are both C90 routines. I reckon I could
>> get that to compile and link quite happily on Turbo C (circa 1989).
> 
> I don't remember complex.h from 1989, though.

True enough, but it doesn't matter, for several reasons:

(1) C90 compilers are allowed to provide extensions, so the existence of 
<complex.h> doesn't imply C99 conformance;
(2) he said it was a linker issue, and the location and translation of 
headers is all done and dusted by the time the linker gets its hands on 
the code;
(3) if all else fails, we can just knock up a <complex.h> of our own and 
hurl it into \tc\include or whatever. Doing so does not make our 
implementation magically C99-conforming.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <CrSdnRWTN7SzfwvbnZ2dnUVZ_u6rnZ2d@comcast.com>, merl the perl wrote:
> "Janne Blomqvist" <foo@bar.invalid> wrote in message 
[snip]
>> [**] Now that I think of [*], maybe it's actually possible to create a
>> leak-free cyclic graph? Say (warning, untested, and I've never used
>> the allocatable TR features myself):
>>
>> type node_t
>> ....
>> type(node_t), pointer :: next
>> type(node_t), allocatable, target :: nextd
>> end type
>>
>> subroutine add_node (node)
>>  type(node_t), allocatable :: node
>>  allocate(node%nextd)
>>  node%next => node%nextd
>> end subroutine add_node
>>
>> subroutine make_cycle (nodeA, nodeB)
>>  type(node_t) :: nodeA, nodeB
>>  if (allocated(nodeA%nextd) then
>>    deallocate (nodeA%nextd)
>>  end if
>>  nodeA%next => nodeB%nextd
>> end subroutine make_cycle
>>
>> The idea being to use pointers to implement aliasing, and allocatables
>> for all allocations.
> I think 16.8.1 MR&C is relevant:
> When a type is extended, the new type does not inherit any of the final 
> subroutines of the old type.  The new type is, however, still finalizable, 
> and when it is finalized any applicable final subroutines of the old type 
> are invoked on the parent component.  "Finalizable" is hard to type.

No, extended types and finalizers have nothing to do with the issue at
hand.


-- 
Janne Blomqvist

Jon Harrop wrote:

> Ben Bacarisse wrote:
>> You are right.  It uses very conservative tests.  Subtracting 13 would
>> fool it, but that would not be valid C either.
> 
> I thought that was valid C, provided you don't dereference it?

No.

-- 
RIP Donald Michie 11 November 1923 - 7 July 2007

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

On Jul 11, 11:00 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> Isaac Gouy wrote:
> > On Jul 7, 12:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> >>  Deleting the Fortran entries from yourshootoutdoesn't make
> >>  Fortran "unloved".
>
> > That's just malicious gossip - no one deleted Fortran entries from the
> >shootout.
>
> e.g. where's the Fortran ray tracer gone?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet

Next you'll be asking where your head has gone - it hasn't gone
anywhere.

Isaac Gouy wrote:
> On Jul 11, 11:00 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Isaac Gouy wrote:
>>> On Jul 7, 12:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>>  Deleting the Fortran entries from yourshootoutdoesn't make
>>>>  Fortran "unloved".
>>> That's just malicious gossip - no one deleted Fortran entries from the
>>> shootout.
>> e.g. where's the Fortran ray tracer gone?
>>
>> --
>> Dr Jon D Harrop, Flying Frog Consultancy
>> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet
> 
> Next you'll be asking where your head has gone - it hasn't gone
> anywhere.
> 
Er, um, maybe Jon could have phrased his question a little better, but
isn't it obvious that he doesn't know where the program is?  Why not
simply tell him where to look?

Dick Hendrickson

"Janne Blomqvist" <foo@bar.invalid> wrote in message 
news:slrnf9eb89.5m7v.foo@kosh.hut.fi...
> In article <CrSdnRWTN7SzfwvbnZ2dnUVZ_u6rnZ2d@comcast.com>, merl the perl 
> wrote:
>> "Janne Blomqvist" <foo@bar.invalid> wrote in message
> [snip]
>>> [**] Now that I think of [*], maybe it's actually possible to create a
>>> leak-free cyclic graph? Say (warning, untested, and I've never used
>>> the allocatable TR features myself):
>>>
>>> type node_t
>>> ....
>>> type(node_t), pointer :: next
>>> type(node_t), allocatable, target :: nextd
>>> end type
>>>
>>> subroutine add_node (node)
>>>  type(node_t), allocatable :: node
>>>  allocate(node%nextd)
>>>  node%next => node%nextd
>>> end subroutine add_node
>>>
>>> subroutine make_cycle (nodeA, nodeB)
>>>  type(node_t) :: nodeA, nodeB
>>>  if (allocated(nodeA%nextd) then
>>>    deallocate (nodeA%nextd)
>>>  end if
>>>  nodeA%next => nodeB%nextd
>>> end subroutine make_cycle
>>>
>>> The idea being to use pointers to implement aliasing, and allocatables
>>> for all allocations.
>> I think 16.8.1 MR&C is relevant:
>> When a type is extended, the new type does not inherit any of the final
>> subroutines of the old type.  The new type is, however, still 
>> finalizable,
>> and when it is finalized any applicable final subroutines of the old type
>> are invoked on the parent component.  "Finalizable" is hard to type.
>
> No, extended types and finalizers have nothing to do with the issue at
> hand.
How do you collect garbage without finalizing?
--
merl 

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:w7udnVQlsrOGggrbnZ2dnUVZ8sbinZ2d@bt.com...
> glen herrmannsfeldt said:
>
>> Richard Heathfield wrote:
>>
>> (snip)
>>
>>>>#include <stdio.h>
>>>>#include <complex.h>
>>>>int main(void)
>>>>{
>>
>>>>printf("tja\n");
>>>>system("pause");
>>>>return 0;
>>>>}
>> (snip)
>>
>>> Um, why? printf and system are both C90 routines. I reckon I could
>>> get that to compile and link quite happily on Turbo C (circa 1989).
No complaint about the lack of portability of ("pause")?

>> I don't remember complex.h from 1989, though.
>
> True enough, but it doesn't matter, for several reasons:
>
> (1) C90 compilers are allowed to provide extensions, so the existence of
> <complex.h> doesn't imply C99 conformance;
> (2) he said it was a linker issue, and the location and translation of
> headers is all done and dusted by the time the linker gets its hands on
> the code;
> (3) if all else fails, we can just knock up a <complex.h> of our own and
> hurl it into \tc\include or whatever. Doing so does not make our
> implementation magically C99-conforming.
I used complex.h precisely because it is in this netherregion.  My MS 
product from circa 1995 had no problem with it.  More indicative is the 
header for the boolean types.  Since main doesn't use anything from 
complex.h, I figured it would be the linker to complain, but I can be wrong. 
I don't believe that I have anything less than C99 on which I can test.
--
merl 

merl the perl said:

> 
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:w7udnVQlsrOGggrbnZ2dnUVZ8sbinZ2d@bt.com...
>> glen herrmannsfeldt said:
>>
>>> Richard Heathfield wrote:
>>>
>>> (snip)
>>>
>>>>>#include <stdio.h>
>>>>>#include <complex.h>
>>>>>int main(void)
>>>>>{
>>>
>>>>>printf("tja\n");
>>>>>system("pause");
>>>>>return 0;
>>>>>}
>>> (snip)
>>>
>>>> Um, why? printf and system are both C90 routines. I reckon I could
>>>> get that to compile and link quite happily on Turbo C (circa 1989).
> No complaint about the lack of portability of ("pause")?

Oh, I can moan about that if you like, but I was trying to stick to the 
subject at hand.

>>> I don't remember complex.h from 1989, though.
>>
>> True enough, but it doesn't matter, for several reasons:
>>
>> (1) C90 compilers are allowed to provide extensions, so the existence
>> of <complex.h> doesn't imply C99 conformance;
>> (2) he said it was a linker issue, and the location and translation
>> of headers is all done and dusted by the time the linker gets its
>> hands on the code;
>> (3) if all else fails, we can just knock up a <complex.h> of our own
>> and hurl it into \tc\include or whatever. Doing so does not make our
>> implementation magically C99-conforming.
> I used complex.h precisely because it is in this netherregion.  My MS
> product from circa 1995 had no problem with it.  More indicative is
> the
> header for the boolean types.  Since main doesn't use anything from
> complex.h, I figured it would be the linker to complain, but I can be
> wrong.

Why should the linker complain? All it has to do is find printf() and 
system(), and those are both C90 functions.


> I don't believe that I have anything less than C99 on which I
> can test.

It's possible that you have a C99-conforming compiler, but frankly I 
doubt it. Most people don't have C99. Many people, however, labour 
under the mistaken belief that they do.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:arqdnbnC1-bWmgXbRVnygAA@bt.com...
> merl the perl said:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:w7udnVQlsrOGggrbnZ2dnUVZ8sbinZ2d@bt.com...
>>> glen herrmannsfeldt said:

>> I used complex.h precisely because it is in this netherregion.  My MS
>> product from circa 1995 had no problem with it.  More indicative is
>> the
>> header for the boolean types.  Since main doesn't use anything from
>> complex.h, I figured it would be the linker to complain, but I can be
>> wrong.
>
> Why should the linker complain? All it has to do is find printf() and
> system(), and those are both C90 functions.
I see your point.  I believe that a correct descriptor of printf is that it 
is "variadic."  Which other C functions have this trait?

>> I don't believe that I have anything less than C99 on which I
>> can test.
>
> It's possible that you have a C99-conforming compiler, but frankly I
> doubt it. Most people don't have C99. Many people, however, labour
> under the mistaken belief that they do.
Can you post source that will fail or succeed, ergo decide, if not compiled 
with C99?  I'm almost certain I have the headers, but this doesn't imply 
that I'm strictly-conforming.
-- 
merl 

merl the perl said:
> "Richard Heathfield" <rjh@see.sig.invalid> wrote...

<snip>

>>
>> Why should the linker complain? All it has to do is find printf() and
>> system(), and those are both C90 functions.
> I see your point.  I believe that a correct descriptor of printf is
> that it
> is "variadic."  Which other C functions have this trait?

The obvious candidates are fprintf, sprintf, scanf, sscanf, fscanf, and 
so on. C99 adds some more, such as snprintf.

(No - having snprintf doesn't by itself mean that you have a 
C99-conforming implementation.)

>>> I don't believe that I have anything less than C99 on which I
>>> can test.
>>
>> It's possible that you have a C99-conforming compiler, but frankly I
>> doubt it. Most people don't have C99. Many people, however, labour
>> under the mistaken belief that they do.
> Can you post source that will fail or succeed, ergo decide, if not
> compiled with C99?

As Richard Maine points out, you're asking me to provide a full 
conformance test suite. That will take me a few years to write, but if 
you're prepared to pay consultancy rates over that period, I'm happy to 
take it on.

> I'm almost certain I have the headers, but this doesn't
> imply that I'm strictly-conforming.

Yes, you're right that it doesn't imply that. There are in fact very few 
known-to-be-conforming C99 implementations.

I have no idea how up to date the following link is, but you may find it 
of passing interest: <http://www.peren.com/pages/cvsa_isocvpl.htm>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:duudnQTbmuDctwXbRVnyggA@bt.com...
> merl the perl said:
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote...

>>> Why should the linker complain? All it has to do is find printf() and
>>> system(), and those are both C90 functions.
>> I see your point.  I believe that a correct descriptor of printf is
>> that it
>> is "variadic."  Which other C functions have this trait?
>
> The obvious candidates are fprintf, sprintf, scanf, sscanf, fscanf, and
> so on. C99 adds some more, such as snprintf.
I believe these are precluded from fortran interop.

>>>> I don't believe that I have anything less than C99 on which I
>>>> can test.
>>>
>>> It's possible that you have a C99-conforming compiler, but frankly I
>>> doubt it. Most people don't have C99. Many people, however, labour
>>> under the mistaken belief that they do.
>> Can you post source that will fail or succeed, ergo decide, if not
>> compiled with C99?
>> I'm almost certain I have the headers, but this doesn't
>> imply that I'm strictly-conforming.
>
> Yes, you're right that it doesn't imply that. There are in fact very few
> known-to-be-conforming C99 implementations.
>
> I have no idea how up to date the following link is, but you may find it
> of passing interest: <http://www.peren.com/pages/cvsa_isocvpl.htm>
Those are the usual suspects.  I've been looking at Sun capabilities as 
maybe a good next option for me.  Having a strictly-conforming C compiler 
sweetens the deal.

[reordered for thematic reasons]
> As Richard Maine points out, you're asking me to provide a full
> conformance test suite. That will take me a few years to write, but if
> you're prepared to pay consultancy rates over that period, I'm happy to
> take it on.
No, I'm not asking for a 3-year indenture.  I'm asking for something similar 
to the question of how can I tell c vs. c++.  People _do_ make careers out 
of that, but I say the answer is to make a malloc() call and see if your 
compiler wnats to caste it.  It's not the whole answer, but it's always 
worked for me.  There have got to be a handful of calls that would decide 
except in cases of intentionally pathology.
-- 
merl

Richard Heathfield <rjh@see.sig.invalid> writes:

> As Richard Maine points out, you're asking me to provide a full
> conformance test suite. That will take me a few years to write,
> but if you're prepared to pay consultancy rates over that
> period, I'm happy to take it on.

ITYM "...give you a receipt."
-- 
Ben Pfaff 
http://benpfaff.org

merl the perl said:

<snip>
 
> There have got to be a handful of calls that would
> decide except in cases of intentionally pathology.

No, not really. After all, any one of the C99 changes may be offered as 
a C90 extension. Nevertheless, here are some basic tests you can do:

1) Does your implementation claim C99 conformance? If not, it doesn't 
conform to C99.
2) is your implementation supplied by Microsoft, Borland, or GNU? Or is 
it lcc-win32, perhaps? If so, it's not C99-conforming.
3) does your implementation issue a diagnostic message for:

main() { puts("Hello, world!"); }

If it doesn't, it isn't C99-conforming. (Just because it does, doesn't 
mean it is. But if it doesn't, it isn't.)

4) How does it handle comments?

#include <stdio.h>

int main(void)
{
  int x = 9;
  int y = 10;
  int z = x//* hello world */y
          ;
  printf("Comments are C9%d\n", z);
  return 0;
}

You can make up similar tests yourself, I'm sure.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Ben Pfaff said:

> Richard Heathfield <rjh@see.sig.invalid> writes:
> 
>> As Richard Maine points out, you're asking me to provide a full
>> conformance test suite. That will take me a few years to write,
>> but if you're prepared to pay consultancy rates over that
>> period, I'm happy to take it on.
> 
> ITYM "...give you a receipt."

<grin> Would I say a thing like that?

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:tZ-dneQindwH9QXbRVnyvQA@bt.com...
> merl the perl said:
>
> <snip>
>
>> There have got to be a handful of calls that would
>> decide except in cases of intentionally pathology.
>
> No, not really. After all, any one of the C99 changes may be offered as
> a C90 extension. Nevertheless, here are some basic tests you can do:
>
> 1) Does your implementation claim C99 conformance? If not, it doesn't
> conform to C99.
> 2) is your implementation supplied by Microsoft, Borland, or GNU? Or is
> it lcc-win32, perhaps? If so, it's not C99-conforming.
Not by intent. And the reasons for these 4 vendors not complying vary.

> 3) does your implementation issue a diagnostic message for:
>
> main() { puts("Hello, world!"); }
>
> If it doesn't, it isn't C99-conforming. (Just because it does, doesn't
> mean it is. But if it doesn't, it isn't.)
>
> 4) How does it handle comments?
>
> #include <stdio.h>
>
> int main(void)
> {
>  int x = 9;
>  int y = 10;
>  int z = x//* hello world */y
>          ;
>  printf("Comments are C9%d\n", z);
>  return 0;
> }
>
> You can make up similar tests yourself, I'm sure.
I'm certain that I can't do anything virtuoso like that.  I have no idea 
whether it's genius or ba-hooey.  I'll make this my C99 target.  Here comes 
deltree.
-- 
merl 

In article <-pudnVLJG_OmZwrbnZ2dnUVZ_gWdnZ2d@comcast.com>, merl the perl wrote:
> How do you collect garbage without finalizing?

Just like you collect garbabe with finalizing, except the collector
does not call the finalizer before deallocating the storage.

-- 
Janne Blomqvist

On Sat, Jul 14, 2007 at 04:12:01AM -0800, glen herrmannsfeldt wrote:
> 
> As far as I know, conservative GC is usual.  It is well known
> in Java that GC will not recognize circular linked lists that
> can't be reached, such that one should assign null to break the
> list.

Eh? What do you mean? Garbage collectors can and do collect unreachable 
circular data structures. IIRC, Sun's JVM uses some combination of 
stop-and-copy and mark-and-compact, both of which are perfectly capable 
of collecting unreachable circular data structures.

Regards,

Bob

-- 
"Beware of bugs in the above code; I have only proved it correct, but not
tried it."
	-- Donald Knuth

Douglas Wells wrote:
(snip)

>  - C does, however, require that a data pointer fix within a
>    variable of the form:
>         unsigned char   holder [sizeof (void *)];
>    and the bits can be reliably copied in and out via the moral
>    equivalent of:
>         memcpy (holder, &dataptr, sizeof holder);
>         memcpy (&dataptr, holder, sizeof dataptr);

> Thus, it is possible for a conforming application program to copy
> the contents of a data pointer to an opaque container and copy
> that container outside of the process's address space (where it
> presumably can be neither located nor examined by the GC).  
(snip)

In that case, the GC has to recognize that the pointer is
being copied out an never release that space.

> Note that there are garbage collectors for C (the one by Hans Boehm
> likely being the most popular).  Many of these GCs implement
> conservative collection algorithms:  they perform program analysis
> (both static and dynamic) and, if they suspect that the address
> of a data block has become hidden from them, they will not garbage
> collect that data.  I can't prove it, but I believe that for all
> of these GCs, there still exist various application actions that
> are legal C but which would confuse the GC (and therefore would
> cause improper run-time behavior).

As far as I know, conservative GC is usual.  It is well known
in Java that GC will not recognize circular linked lists that
can't be reached, such that one should assign null to break the
list.   Also, if one creates a large object in main that isn't
needed to assign null to the object reference.  There are enough
cases where no GC can figure out that data won't be referenced,
such that the only way out is manual intervention.

The case above seems to require special code in memcpy to
recognize it.

-- glen

glen herrmannsfeldt wrote:
> As far as I know, conservative GC is usual.  It is well known
> in Java that GC will not recognize circular linked lists that
> can't be reached, such that one should assign null to break the
> list.   Also, if one creates a large object in main that isn't
> needed to assign null to the object reference.  There are enough
> cases where no GC can figure out that data won't be referenced,
> such that the only way out is manual intervention.

Note that this is all completely wrong.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Peter J. Holzer wrote:
> Yes. Section 6.5.6 Additive operators in ISO/IEC 9899:1999 only defines
> pointer arithmetic within an array. p += 20 is undefined.

Is this specific to C99?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Jon Harrop <jon@ffconsultancy.com> writes:

> Peter J. Holzer wrote:
>> Yes. Section 6.5.6 Additive operators in ISO/IEC 9899:1999 only defines
>> pointer arithmetic within an array. p += 20 is undefined.
>
> Is this specific to C99?

No, p += 20 in a 10-element array is also undefined in C89.
-- 
Ben Pfaff 
http://benpfaff.org

On 2007-07-14 15:53, Jon Harrop <jon@ffconsultancy.com> wrote:
> Peter J. Holzer wrote:
>> Yes. Section 6.5.6 Additive operators in ISO/IEC 9899:1999 only defines
>> pointer arithmetic within an array. p += 20 is undefined.
>
> Is this specific to C99?
>

No. It was the same in C89. 

There are a few reasons for this:

1) There is no portable use for pointers which point outside an object
   (except for "one past the end" and "one before the start").
   So there was no reason to define what should happen in this case and
   any definition would have been an arbitrary restriction on
   implementations.

2) There were quite a few segmented architectures in the 1980s, which
   behaved differently on overflow. Some (e.g., the 8086) would just
   wrap around (so arithmetic would work, but comparisons would not),
   some would throw an exception. Requiring a different behaviour would
   have made C on those architectures unnessarily inefficient for no
   gain. (this also killed "one before the start")

3) Not defining the behaviour on pointer arithmetic overflow allows 
   implementations to implement range-checking but doesn't require it.
   IIRC there existed at least one reasonably popular implementation in
   ca. 1990. 

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

On Jul 13, 3:11 pm, Dick Hendrickson <dick.hendrick...@att.net> wrote:
> Isaac Gouy wrote:
> > On Jul 11, 11:00 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> Isaac Gouy wrote:
> >>> On Jul 7, 12:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> >>>>  Deleting the Fortran entries from yourshootoutdoesn't make
> >>>>  Fortran "unloved".
> >>> That's just malicious gossip - no one deleted Fortran entries from the
> >>>shootout.
> >> e.g. where's the Fortran ray tracer gone?
>
> >> --
> >> Dr Jon D Harrop, Flying Frog Consultancy
> >> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet
>
> > Next you'll be asking where your head has gone - it hasn't gone
> > anywhere.
>
> Er, um, maybe Jon could have phrased his question a little better, but
> isn't it obvious that he doesn't know where the program is?  Why not
> simply tell him where to look?
>
> Dick Hendrickson


It's obvious that Jon has claimed "the Fortran implementations of the
ray tracer benchmark ... were all deleted. ... deleted by the shootout
maintainers..." [Jul 7, 3:18 pm] without making any attempt to show
that accusation has any basis in reality.

Jon continues to demand that I disprove his baseless claim - that's
just the wrong way around, it isn't for us to disprove claims that the
moon is made of green cheese, doing the work to disprove baseless
claims is just an encouragement.

I think Jon Harrop is a clever guy, I think he phrases his questions
carefully and I don't guess about his motivations ;-)

In article <1184433600.500366.205770@g12g2000prg.googlegroups.com>,
Isaac Gouy  <igouy2@yahoo.com> wrote:

>It's obvious that Jon has claimed "the Fortran implementations of the
>ray tracer benchmark ... were all deleted. ... deleted by the shootout
>maintainers..." [Jul 7, 3:18 pm] without making any attempt to show
>that accusation has any basis in reality.

It would be helpful if people would talk to each other instead of just
butting heads.

I don't see a ray tracer in the current benchmark list. Did there used
to be one? Was it deleted?

-- g

On Jul 14, 10:34 am, lind...@pbm.com (Greg Lindahl) wrote:
> In article <1184433600.500366.205...@g12g2000prg.googlegroups.com>,
> Isaac Gouy  <igo...@yahoo.com> wrote:
>
> >It's obvious that Jon has claimed "the Fortran implementations of the
> >ray tracer benchmark ... were all deleted. ... deleted by theshootout
> >maintainers..." [Jul 7, 3:18 pm] without making any attempt to show
> >that accusation has any basis in reality.
>
> It would be helpful if people would talk to each other instead of just
> butting heads.

None of this is news to Jon :-)


> I don't see a ray tracer in the current benchmark list. Did there used
> to be one? Was it deleted?


To repeat [Jul 10, 5:58 pm] "...the fact is that we have programs for
41 obsolete problems in CVS, and we have been showing programs for the
same 19 active problems for about the last 2 years."

raytracer is one of those 41 obsolete problems, last shown in August
2005.

Aren't you going to ask if "the Fortran implementations of the ray
tracer benchmark ... were all deleted. ... deleted by the shootout
maintainers..." ?

Isaac Gouy writes:
> Aren't you going to ask if "the Fortran implementations of the ray
> tracer benchmark ... were all deleted. ... deleted by the shootout
> maintainers..." ?

Oh for Ghu's sake.  This is obviously a private quarrel, as determined
you all are to make sure no outsiders can easily find out what you are
yakking about.  So take this to a private mail.  Or if you must go on
in public, at least get a grip and post some URLs where people - and
Harris - can judge for themselves without deciding from who is best at
throwing dirt.

There have been some interesting postings under this subject, but this
isn't it.

-- 
Regards,
Hallvard

I wrote:
> in public, at least get a grip and post some URLs where people - and
> Harris - can judge for themselves without deciding from who is best at
> throwing dirt.

Oops, Harrop of course.  Sorry.

-- 
Regards,
Hallvard

In article <1184438369.259366.326410@g12g2000prg.googlegroups.com>,
Isaac Gouy  <igouy2@yahoo.com> wrote:

>Aren't you going to ask if "the Fortran implementations of the ray
>tracer benchmark ... were all deleted. ... deleted by the shootout
>maintainers..." ?

Well, no, but you did just explain Jon's complaint. I agree that Jon
is a butt-head (he's in my killfile and belongs in yours, too), but
you could have explained the obsolete program issue immediately
instead of being coy about it.

-- greg

Ben Pfaff wrote:
> No, p += 20 in a 10-element array is also undefined in C89.

So most of Numerical Recipies is actually illegal C because it offsets base
pointers to get Fortran-style 1..n indexing?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

Jon Harrop said:

> Ben Pfaff wrote:
>> No, p += 20 in a 10-element array is also undefined in C89.
> 
> So most of Numerical Recipies is actually illegal C because it offsets
> base pointers to get Fortran-style 1..n indexing?

I can't quite remember how they pull this off, so I'm not prepared to 
say it's actually illegal, but IF they do this:

T *p = malloc(n * sizeof *p);

foo(p - 1, n);

so that they can use elements 1 to n within foo, then yes, that's 
illegal - or at least, the behaviour of such code is undefined.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jon Harrop <jon@ffconsultancy.com> writes:

> Ben Pfaff wrote:
>> No, p += 20 in a 10-element array is also undefined in C89.
>
> So most of Numerical Recipies is actually illegal C because it offsets base
> pointers to get Fortran-style 1..n indexing?

Yes.  Its authors are aware of this: see the dicussion under
"Memory Allocation: Advanced Topics" in "Appendix B: Utility
Routines" in the 2nd edition of _Numerical Recipes in C_.
-- 
"Because computer source code is an expressive means for the exchange
 of information and ideas about computer programming, we hold that it
 is protected by the First Amendment."
--Hon. Boyce F. Martin, Jr., for the 6th Circuit Court, Junger vs. Daley

Ben Pfaff wrote:
> Jon Harrop <jon@ffconsultancy.com> writes:
>> So most of Numerical Recipies is actually illegal C because it offsets
>> base pointers to get Fortran-style 1..n indexing?
> 
> Yes.  Its authors are aware of this: see the dicussion under
> "Memory Allocation: Advanced Topics" in "Appendix B: Utility
> Routines" in the 2nd edition of _Numerical Recipes in C_.

Wow. Another nail in that coffin...

I like their wording though:

  "Strictly speaking, this scheme is not blessed by the ANSI C standard..."

:-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

On Jul 14, 11:53 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
wrote:
> Isaac Gouy writes:
> > Aren't you going to ask if "the Fortran implementations of the ray
> > tracer benchmark ... were all deleted. ... deleted by theshootout
> > maintainers..." ?
>
> Oh for Ghu's sake.  This is obviously a private quarrel, as determined
> you all are to make sure no outsiders can easily find out what you are
> yakking about.  So take this to a private mail.  Or if you must go on
> in public, at least get a grip and post some URLs where people - and
> Harris - can judge for themselves without deciding from who is best at
> throwing dirt.

Excellent! Please humour my curiousity, with 5 minutes of your time,
get a watch and time yourself, I have no particular expectation about
your success or failure, and see if you can find  "Fortran
implementations of the ray tracer benchmark" for yourself

http://shootout.alioth.debian.org/gp4/faq.php



>
> There have been some interesting postings under this subject, but this
> isn't it.
>
> --
> Regards,
> Hallvard

Robbert Haarman wrote:
(I wrote)

>>As far as I know, conservative GC is usual.  It is well known
>>in Java that GC will not recognize circular linked lists that
>>can't be reached, such that one should assign null to break the
>>list.

> Eh? What do you mean? Garbage collectors can and do collect unreachable 
> circular data structures. IIRC, Sun's JVM uses some combination of 
> stop-and-copy and mark-and-compact, both of which are perfectly capable 
> of collecting unreachable circular data structures.

It may have been changed, it used to not recognize circular
data structures.  Do you trust that all JVMs will recognize them?

In any case, it will still not GC reachable but no longer
used items.   I don't believe that mind reading has been added
to any GC system yet.

-- glen

glen herrmannsfeldt wrote:
> Robbert Haarman wrote:
> (I wrote)
> 
>>>As far as I know, conservative GC is usual.  It is well known
>>>in Java that GC will not recognize circular linked lists that
>>>can't be reached, such that one should assign null to break the
>>>list.
> 
>> Eh? What do you mean? Garbage collectors can and do collect unreachable 
>> circular data structures. IIRC, Sun's JVM uses some combination of 
>> stop-and-copy and mark-and-compact, both of which are perfectly capable 
>> of collecting unreachable circular data structures.
> 
> It may have been changed, it used to not recognize circular
> data structures.

IIRC at least mainstream JVM:s (Sun, IBM) have always used proper GC,
which is capable of collecting circular data structures. I think
you'll be hard pressed to find any JVM which is not capable of this
(I'm not aware of any).

The python programming language used to do "vanilla" reference
counting, and was thus not capable of collecting circular
structures. But in later versions they added some kind of loop
detector or maybe they switched to a proper GC.

>  Do you trust that all JVMs will recognize them?

Yes, all the commonly used ones at least.

> In any case, it will still not GC reachable but no longer
> used items.   I don't believe that mind reading has been added
> to any GC system yet.

They don't do mind reading, but they do stack liveness analysis, so
there's no need to nullify local variables. See

http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf


-- 
Janne Blomqvist

glen herrmannsfeldt wrote:
> Robbert Haarman wrote:
> (I wrote)
> 
>>>As far as I know, conservative GC is usual.  It is well known
>>>in Java that GC will not recognize circular linked lists that
>>>can't be reached, such that one should assign null to break the
>>>list.
> 
>> Eh? What do you mean? Garbage collectors can and do collect unreachable 
>> circular data structures. IIRC, Sun's JVM uses some combination of 
>> stop-and-copy and mark-and-compact, both of which are perfectly capable 
>> of collecting unreachable circular data structures.
> 
> It may have been changed, it used to not recognize circular
> data structures.

IIRC at least mainstream JVM:s (Sun, IBM) have always used proper GC,
which is capable of collecting circular data structures. I think
you'll be hard pressed to find any JVM which is not capable of this
(I'm not aware of any).

The python programming language used to do "vanilla" reference
counting, and was thus not capable of collecting circular
structures. But in later versions they added some kind of loop
detector or maybe they switched to a proper GC.

>  Do you trust that all JVMs will recognize them?

Yes, all the commonly used ones at least.

> In any case, it will still not GC reachable but no longer
> used items.   I don't believe that mind reading has been added
> to any GC system yet.

They don't do mind reading, but they do liveness analysis, so there's
no need to nullify local variables. See

http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf


-- 
Janne Blomqvist

Isaac Gouy writes:
> On Jul 14, 11:53 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
> wrote:
>> Oh for Ghu's sake.  This is obviously a private quarrel, as determined
>> you all are to make sure no outsiders can easily find out what you are
>> yakking about.  So take this to a private mail.  Or if you must go on
>> in public, at least get a grip and post some URLs where people - and
>> Harris - can judge for themselves without deciding from who is best at
>> throwing dirt.
>
> Excellent! Please humour my curiousity, with 5 minutes of your time,
> get a watch and time yourself,

Why on earth should I?  You're the one who want people who believe
Harro's claims are false, so it's your problem and not mine to use
some time at finding references.

> I have no particular expectation about
> your success or failure, and see if you can find  "Fortran
> implementations of the ray tracer benchmark" for yourself
>
> http://shootout.alioth.debian.org/gp4/faq.php

I did have a brief look there last time you posted it.  "Fortran" and
"ray tracer" are among the phrases not mentioned there.  A quick google
finds too much or too little.  Browsing CVS finds 0 entries for fortran,
or old references to a fortran ray tracer, among a bunch of other stuff.
None of the quick finds mentioned its history.

The one thing I actually know about this by now is that either of you
some day were to deign to actually post some useful references, I have
no interest in going there to find out if the shootout is cheating or
not.

-- 
Regards,
Hallvard

Janne Blomqvist wrote:

(snip)

>>In any case, it will still not GC reachable but no longer
>>used items.   I don't believe that mind reading has been added
>>to any GC system yet.

> They don't do mind reading, but they do liveness analysis, so there's
> no need to nullify local variables.

In main, though, they stay live until the return from main.
There was an example, I believe in Sun documentation, of a large
array used in main once, and then never used again.
That would also be true in another method for a large object
that was used once, unneeded later, and other large objects were
needed that should be able to reuse that memory.  It is fairly
rare, but it can happen.

-- glen

glen herrmannsfeldt wrote:
> Janne Blomqvist wrote:
> 
> (snip)
> 
>>>In any case, it will still not GC reachable but no longer
>>>used items.   I don't believe that mind reading has been added
>>>to any GC system yet.
> 
>> They don't do mind reading, but they do liveness analysis, so there's
>> no need to nullify local variables.
> 
> In main, though, they stay live until the return from main.
> There was an example, I believe in Sun documentation, of a large
> array used in main once, and then never used again.
> That would also be true in another method for a large object
> that was used once, unneeded later, and other large objects were
> needed that should be able to reuse that memory.  It is fairly
> rare, but it can happen.

You're missing the point. Liveness is not the same as "exists on the
stack". In essence, liveness analysis is about finding reference
variables on the stack which are never referenced before they are
popped. I.e. the object can be deallocated even though the reference
still exists on the stack and conceptually points to some object. I
presume you didn't read pages 16 and 17 in the slides I linked to in
my previous post, or you wouldn't post stuff which directly
contradicts what the JVM GC designers say about their own product.

Now, AFAICS liveness analysis has not always been part of the JVM, and
I also remember that nulling unneeded references was a common
optimization suggestion way back when, and it might even have found
it's way into Sun's documentation like you say. But the damn world
just keeps changin'..

-- 
Janne Blomqvist

On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
wrote:
-snip-
> Why on earth should I?  You're the one who want people who believe
> Harro's claims are false, so it's your problem and not mine to use
> some time at finding references.

What I want is for people to understand that when Jon Harrop makes a
claim, the burden is on Jon Harrop to prove his claim not on others to
disprove it.


> I did have a brief look there last time you posted it.  "Fortran" and
> "ray tracer" are among the phrases not mentioned there.  A quick google
> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
> or old references to a fortran ray tracer, among a bunch of other stuff.

Sounds like you found the fortran raytracer source code in CVS but
thought it old? (It is old, 2005)


> None of the quick finds mentioned its history.

> The one thing I actually know about this by now is that either of you
> some day were to deign to actually post some useful references, I have
> no interest in going there to find out if the shootout is cheating or
> not.

That's about how interested I am in responding when Jon Harrop makes
statements which are untrue.

In any case here's the fortran raytracer source code, right alongside
programs that Jon Harrop checked into CVS - go figure!

http://alioth.debian.org/plugins/scmcvs/cvsweb.php/shootout/bench/raytracer/?cvsroot=shootout

Isaac Gouy wrote:
> In any case here's the fortran raytracer source code, right alongside
> programs that Jon Harrop checked into CVS - go figure!
> 
>
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/shootout/bench/raytracer/?cvsroot=shootout

Those programs were once on the shootout. Now they are not:

  http://shootout.alioth.debian.org

Magic.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet

In article <1184433600.500366.205770@g12g2000prg.googlegroups.com>,
Isaac Gouy  <igouy2@yahoo.com> wrote:
>
>... it isn't for us to disprove claims that the
>moon is made of green cheese

I helped disprove that claim sometime in the early 1960s when I was a
PhD student in applied maths and went to an astronomy research seminar
where someone was talking about his experiments in reflecting radio
waves off the moon, and he had found the refractive index of the
moon's surface rocks at radio frequency. I asked at question time 
"What's the refractive index of green cheese?" After the laughter 
subsided, the speaker admitted he had no idea, but others present 
gave order-of-magnitude estimates that left us convinced that the 
ancient suggestion had at last been disproved.

-- John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

John Harper wrote:
(snip)

> I helped disprove that claim sometime in the early 1960s when I was a
> PhD student in applied maths and went to an astronomy research seminar
> where someone was talking about his experiments in reflecting radio
> waves off the moon, and he had found the refractive index of the
> moon's surface rocks at radio frequency. I asked at question time 
> "What's the refractive index of green cheese?" After the laughter 
> subsided, the speaker admitted he had no idea, but others present 
> gave order-of-magnitude estimates that left us convinced that the 
> ancient suggestion had at last been disproved.

The low frequency refractive index of water is about 9,
(the square root of the dielectric constant, which is 80).
For cheese which is mostly water, it should be relatively high.

-- glen

["Followup-To:" header set to comp.programming.]
On 2007-07-15 23:36, Isaac Gouy <igouy2@yahoo.com> wrote:
> On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
> wrote:
> -snip-
>> Why on earth should I?  You're the one who want people who believe
>> Harro's claims are false, so it's your problem and not mine to use
>> some time at finding references.
>
> What I want is for people to understand that when Jon Harrop makes a
> claim, the burden is on Jon Harrop to prove his claim not on others to
> disprove it.

Well, you did go to the trouble of writing several postings in which you
just claimed that he was wrong without offering any evidence. Since
there is no raytracer benchmark in the current set of active benchmarks
and finding the fortran version in the CVS repository is not
straightforward, Jon did seem somewhat more credible than you did. Not
everybody in the three groups this thread is crossposted to is
intimately familiar with the history of the debian language shootout.
Including a link to
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/~checkout~/shootout/bench/raytracer/raytracer.ifc?rev=1.11;content-type=text%2Fplain;cvsroot=shootout
would have been an easy way to show the audience that you aren't making
clearly counter-factual claims.

>> I did have a brief look there last time you posted it.  "Fortran" and
>> "ray tracer" are among the phrases not mentioned there.  A quick google
>> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
>> or old references to a fortran ray tracer, among a bunch of other stuff.
>
> Sounds like you found the fortran raytracer source code in CVS but
> thought it old? (It is old, 2005)

To me it sounds like he did NOT find ("0 references") the fortran ray
tracer. I didn't find it at the first attempt either. I found the ray
tracer, but the ".ifc" extension didn't indicate fortran to me (I was
looking for ".f", ".f77", ".f90" or something like that).

>> The one thing I actually know about this by now is that either of you
>> some day were to deign to actually post some useful references, I have
>> no interest in going there to find out if the shootout is cheating or
>> not.
>
> That's about how interested I am in responding when Jon Harrop makes
> statements which are untrue.

It sure sounded like he meant that only the fortran submissions had been
removed. However, I am willing that he meant that the whole benchmark
has been removed and that be "removed" he meant "excluded from the
active set of benchmarks" not "removed from the CVS repository".

	hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

On Jul 16, 4:58 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> ["Followup-To:" header set to comp.programming.]
> On 2007-07-15 23:36, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
> > wrote:
> > -snip-
> >> Why on earth should I?  You're the one who want people who believe
> >> Harro's claims are false, so it's your problem and not mine to use
> >> some time at finding references.
>
> > What I want is for people to understand that when Jon Harrop makes a
> > claim, the burden is on Jon Harrop to prove his claim not on others to
> > disprove it.
>
> Well, you did go to the trouble of writing several postings in which you
> just claimed that he was wrong without offering any evidence. Since
> there is no raytracer benchmark in the current set of active benchmarks
> and finding the fortran version in the CVS repository is not
> straightforward, Jon did seem somewhat more credible than you did. Not
> everybody in the three groups this thread is crossposted to is
> intimately familiar with the history of the debian language shootout.
> Including a link to http://alioth.debian.org/plugins/scmcvs/cvsweb.php/~checkout~/shootou...
> would have been an easy way to show the audience that you aren't making
> clearly counter-factual claims.
>
> >> I did have a brief look there last time you posted it.  "Fortran" and
> >> "ray tracer" are among the phrases not mentioned there.  A quick google
> >> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
> >> or old references to a fortran ray tracer, among a bunch of other stuff.
>
> > Sounds like you found the fortran raytracer source code in CVS but
> > thought it old? (It is old, 2005)
>
> To me it sounds like he did NOT find ("0 references") the fortran ray
> tracer. I didn't find it at the first attempt either. I found the ray
> tracer, but the ".ifc" extension didn't indicate fortran to me (I was
> looking for ".f", ".f77", ".f90" or something like that).

Ouch, a convention of using .ifc for Fortran code that is compiled
with the Intel Fortran compiler is painful.  Most but not all Fortran
programmers agree that the suffix .f90 should be use for free source
form Fortran and that .f or possibly .for should be used for the
traditional fixed source form.

On 2007-07-16 09:57:10 -0300, Beliavsky <beliavsky@aol.com> said:

> On Jul 16, 4:58 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> ["Followup-To:" header set to comp.programming.]
>> On 2007-07-15 23:36, Isaac Gouy <igo...@yahoo.com> wrote:
>> 
>>> On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
>>> wrote:
>>> -snip-
>>>> Why on earth should I?  You're the one who want people who believe
>>>> Harro's claims are false, so it's your problem and not mine to use
>>>> some time at finding references.
>> 
>>> What I want is for people to understand that when Jon Harrop makes a
>>> claim, the burden is on Jon Harrop to prove his claim not on others to
>>> disprove it.
>> 
>> Well, you did go to the trouble of writing several postings in which you
>> just claimed that he was wrong without offering any evidence. Since
>> there is no raytracer benchmark in the current set of active benchmarks
>> and finding the fortran version in the CVS repository is not
>> straightforward, Jon did seem somewhat more credible than you did. Not
>> everybody in the three groups this thread is crossposted to is
>> intimately familiar with the history of the debian language shootout.
>> Including a link to 
>> http://alioth.debian.org/plugins/scmcvs/cvsweb.php/~checkout~/shootou...
>> would have been an easy way to show the audience that you aren't making
>> clearly counter-factual claims.
>> 
>>>> I did have a brief look there last time you posted it.  "Fortran" and
>>>> "ray tracer" are among the phrases not mentioned there.  A quick google
>>>> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
>>>> or old references to a fortran ray tracer, among a bunch of other stuff.
>> 
>>> Sounds like you found the fortran raytracer source code in CVS but
>>> thought it old? (It is old, 2005)
>> 
>> To me it sounds like he did NOT find ("0 references") the fortran ray
>> tracer. I didn't find it at the first attempt either. I found the ray
>> tracer, but the ".ifc" extension didn't indicate fortran to me (I was
>> looking for ".f", ".f77", ".f90" or something like that).
> 
> Ouch, a convention of using .ifc for Fortran code that is compiled
> with the Intel Fortran compiler is painful.  Most but not all Fortran
> programmers agree that the suffix .f90 should be use for free source
> form Fortran and that .f or possibly .for should be used for the
> traditional fixed source form.

What happened to .FTN? My impression is that it was used with the FTN
compiler on CDC at a time when there were two Fortran compilers available
on that machine. Same rational as .ifc but more obvious to more folks.

On Jul 16, 1:58 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> ["Followup-To:" header set to comp.programming.]
> On 2007-07-15 23:36, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
> > wrote:
> > -snip-
> >> Why on earth should I?  You're the one who want people who believe
> >> Harro's claims are false, so it's your problem and not mine to use
> >> some time at finding references.
>
> > What I want is for people to understand that when Jon Harrop makes a
> > claim, the burden is on Jon Harrop to prove his claim not on others to
> > disprove it.
>
> Well, you did go to the trouble of writing several postings in which you
> just claimed that he was wrong without offering any evidence.

Assertions made without evidence can be dismissed without evidence
- "The moon is made of green cheese!"
- "I think not!"

> Since
> there is no raytracer benchmark in the current set of active benchmarks
> and finding the fortran version in the CVS repository is not
> straightforward, Jon did seem somewhat more credible than you did. Not
> everybody in the three groups this thread is crossposted to is
> intimately familiar with the history of the debian languageshootout.
> Including a link tohttp://alioth.debian.org/plugins/scmcvs/cvsweb.php/~checkout~/shootou...
> would have been an easy way to show the audience that you aren't making
> clearly counter-factual claims.

When Jon Harrop makes a claim, the burden is on him to show his claim
is true - the burden is not on others to disprove his claim -
unfortunately we are often all too willing to believe gossip.


>
> >> I did have a brief look there last time you posted it.  "Fortran" and
> >> "ray tracer" are among the phrases not mentioned there.  A quick google
> >> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
> >> or old references to a fortran ray tracer, among a bunch of other stuff.
>
> > Sounds like you found the fortran raytracer source code in CVS but
> > thought it old? (It is old, 2005)
>
> To me it sounds like he did NOT find ("0 references") the fortran ray
> tracer. I didn't find it at the first attempt either. I found the ray
> tracer, but the ".ifc" extension didn't indicate fortran to me (I was
> looking for ".f", ".f77", ".f90" or something like that).
>
> >> The one thing I actually know about this by now is that either of you
> >> some day were to deign to actually post some useful references, I have
> >> no interest in going there to find out if theshootoutis cheating or
> >> not.
>
> > That's about how interested I am in responding when Jon Harrop makes
> > statements which are untrue.
>
> It sure sounded like he meant that only the fortran submissions had been
> removed. However, I am willing that he meant that the whole benchmark
> has been removed and that be "removed" he meant "excluded from the
> active set of benchmarks" not "removed from the CVS repository".


I explicitly agreed [Jul 7, 9:55 am] that "problem hasn't been shown
for a couple of years"

http://groups.google.com/group/comp.lang.fortran/msg/d96d47f58fdb5640

after which Jon repeatedly stated that the Fortran implementations of
the ray tracer benchmark were all deleted.

1) The Fortran  implementations of raytracer have /not/ been deleted.
2) raytracer has not been shown since August 2005.

(Shock! Horror! Postman did not bite dog!)

Isaac Gouy wrote:
> On Jul 16, 1:58 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> ["Followup-To:" header set to comp.programming.]
>> On 2007-07-15 23:36, Isaac Gouy <igo...@yahoo.com> wrote:
>>
>>> On Jul 15, 7:20 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
>>> wrote:
>>> -snip-
>>>> Why on earth should I?  You're the one who want people who believe
>>>> Harro's claims are false, so it's your problem and not mine to use
>>>> some time at finding references.
>>> What I want is for people to understand that when Jon Harrop makes a
>>> claim, the burden is on Jon Harrop to prove his claim not on others to
>>> disprove it.
>> Well, you did go to the trouble of writing several postings in which you
>> just claimed that he was wrong without offering any evidence.
> 
> Assertions made without evidence can be dismissed without evidence
> - "The moon is made of green cheese!"
> - "I think not!"

Depends on the assertion.  His assertion was along the lines of
It used to be there
I can't find it
Therefore, it's been deleted.

Sure, his "therefore" isn't the only possible one, but it's a
reasonable one.  Sure, he could have said things in a nicer tone.
Sure, you and he apparently have a long history.  But, his fundamental
problem was that he couldn't find the ray tracer.  That's an assertion
that is true on the face of it [No on is going to lie about not being
able to find a program].  And, you not only knew where it was, but you
knew that something had been done to it in 2005.  You could have
easily told him where it was and what/when/why happened to it.
Why not do that?

Dick Hendrickson
> 
>> Since
>> there is no raytracer benchmark in the current set of active benchmarks
>> and finding the fortran version in the CVS repository is not
>> straightforward, Jon did seem somewhat more credible than you did. Not
>> everybody in the three groups this thread is crossposted to is
>> intimately familiar with the history of the debian languageshootout.
>> Including a link tohttp://alioth.debian.org/plugins/scmcvs/cvsweb.php/~checkout~/shootou...
>> would have been an easy way to show the audience that you aren't making
>> clearly counter-factual claims.
> 
> When Jon Harrop makes a claim, the burden is on him to show his claim
> is true - the burden is not on others to disprove his claim -
> unfortunately we are often all too willing to believe gossip.
> 
> 
>>>> I did have a brief look there last time you posted it.  "Fortran" and
>>>> "ray tracer" are among the phrases not mentioned there.  A quick google
>>>> finds too much or too little.  Browsing CVS finds 0 entries for fortran,
>>>> or old references to a fortran ray tracer, among a bunch of other stuff.
>>> Sounds like you found the fortran raytracer source code in CVS but
>>> thought it old? (It is old, 2005)
>> To me it sounds like he did NOT find ("0 references") the fortran ray
>> tracer. I didn't find it at the first attempt either. I found the ray
>> tracer, but the ".ifc" extension didn't indicate fortran to me (I was
>> looking for ".f", ".f77", ".f90" or something like that).
>>
>>>> The one thing I actually know about this by now is that either of you
>>>> some day were to deign to actually post some useful references, I have
>>>> no interest in going there to find out if theshootoutis cheating or
>>>> not.
>>> That's about how interested I am in responding when Jon Harrop makes
>>> statements which are untrue.
>> It sure sounded like he meant that only the fortran submissions had been
>> removed. However, I am willing that he meant that the whole benchmark
>> has been removed and that be "removed" he meant "excluded from the
>> active set of benchmarks" not "removed from the CVS repository".
> 
> 
> I explicitly agreed [Jul 7, 9:55 am] that "problem hasn't been shown
> for a couple of years"
> 
> http://groups.google.com/group/comp.lang.fortran/msg/d96d47f58fdb5640
> 
> after which Jon repeatedly stated that the Fortran implementations of
> the ray tracer benchmark were all deleted.
> 
> 1) The Fortran  implementations of raytracer have /not/ been deleted.
> 2) raytracer has not been shown since August 2005.
> 
> (Shock! Horror! Postman did not bite dog!)
> 

On Jul 16, 2:29 pm, Dick Hendrickson <dick.hendrick...@att.net> wrote:
> Isaac Gouy wrote:
-snip-
> > Assertions made without evidence can be dismissed without evidence
> > - "The moon is made of green cheese!"
> > - "I think not!"
>
> Depends on the assertion.  His assertion was along the lines of
> It used to be there
> I can't find it
> Therefore, it's been deleted.
>
> Sure, his "therefore" isn't the only possible one, but it's a
> reasonable one.  Sure, he could have said things in a nicer tone.
> Sure, you and he apparently have a long history.  But, his fundamental
> problem was that he couldn't find the ray tracer.  That's an assertion
> that is true on the face of it [No on is going to lie about not being
> able to find a program].  And, you not only knew where it was, but you
> knew that something had been done to it in 2005.  You could have
> easily told him where it was and what/when/why happened to it.
> Why not do that?
>
> Dick Hendrickson

You are doing no more than guessing Jon Harrop's motivations -
guessing motivations is fraught at best.

If you wanted to know where something is do you think you might simply
ask where something is or would you accuse someone else of destroying
it?

On Sun, 08 Jul 2007 04:59:14 -0700, Quadibloc <jsavard@ecn.ab.ca>
 wrote in <1183895954.875538.5010@e9g2000prf.googlegroups.com>:

> and the FORTRAN compiler available to you

	These days we tend to use Fortran compilers -- they're a bit more
capable than the old FORTRAN ones...

-- 
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,
Brunel University.    Ivan.Reid@[brunel.ac.uk|cern.ch]    Room 40-1-B12, CERN
        KotPT -- "for stupidity above and beyond the call of duty".

On Jul 15, 5:21 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Isaac Gouy wrote:
> > In any case here's the fortran raytracer source code, right alongside
> > programs that Jon Harrop checked into CVS - go figure!
>
> http://alioth.debian.org/plugins/scmcvs/cvsweb.php/shootout/bench/ray...
>
> Those programs were once on theshootout. Now they are not:
>
>  http://shootout.alioth.debian.org
>
> Magic.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet


You wrote:
"On the contrary, the Fortran implementations of the ray tracer
benchmark
that were all deleted were the fastest of all the implementations even
when
compiled with g95.

The fact that they were deleted by the shootout maintainers has no
bearing
on Fortran itself. "

http://groups.google.com/group/comp.lang.fortran/msg/bc79d2b55396594e


1) Did you intend that to mean - where can I find the fortran
implementation of raytracer?

2) Did you intend that to mean - the raytracer problem is no longer
shown.

3) Did you intend that to mean - the fortran implementations of
raytracer were all deleted.


Magic? Apparently it was magic to you -
"Any sufficiently advanced technology is indistinguishable from magic."

f'up set to c.l.f.

The problem with cross-posting and threaddrift is exhibited by the 
existence/lack of existence of this ray tracer.  If we needed 6 usenet 
messages to talk about finding it, then something's just wrong, something 
not worth pursuing.
-- 
Wade Ward 

["Followup-To:" header set to comp.lang.misc.]
On 2007-07-07, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Richard Maine wrote:
>
> (snip)
>
>> Computational fluid dynamics (typically abbreviated to CFD) is very much
>> that way. There are "interesting" problems in CFD that are multiple
>> orders of magnitude from practical today, even on the biggest machines.
>> Weather simulations, though that has many similarities to CFD. The
>> scales tend to be quite a bit different, but some of the same stuff
>> comes up. I know oil field stuff is big, though I haven't seen it first
>> hand. Nuclear reaction simulations.
>
> I agree with this, but still find it interesting that people are
> more concerned about speed than they were 20 or 30 or 40 years ago.
> These problems (on a smaller scale) were being done years ago, when
> computer time was much more expensive.

Yes, but cut down to the computer of the time with simplifications and
assumptions. So sometimes problems resurface later in a slightly different
form.

P.s. If you have some computer time to spare, you can calculate the charge
distribution of each atom in a gram of non-crystalline matter.