Using Prime calc. as benchmark 
Author Message
 Using Prime calc. as benchmark


Date: Mon, 27 Jan 2003 07:21:44 GMT

Quote:





>> > >Your version does not emulate bits.  It uses a whole integer to
>> > >store each bit.  It uses 8 times the storage of my PL/I version.

>> > A byte is not a whole integer.

>> But it is.  It's a signed integer, using 8, or 16, or 32 bits
>> depending on what the compiler supports.
>Name a computer that identifies a "byte" as 16 or 32 bits.

Richard,
        You know full well that fortran provides word-size integers
(typically 32 bit integers).

However, there is no guarantee that it provides 16 or 8-bit integers.
On Fortrans that don't provide support for 8-bit integers, it will use
a word (32 bits or whatever).

Quote:
>I admit that I overlooked in my byte duplication of your bit
>storage version, that          count = sum(sieve)   is a 127bit sum

No, its not a 127bit sum.  It's an 8-bit sum on your system because
127 is the largest signed integer that will fit in a byte.


Fri, 22 Jul 2005 08:46:29 GMT  
 Using Prime calc. as benchmark


Quote:

Florida
> Date: Mon, 27 Jan 2003 07:21:44 GMT






> >> > >Your version does not emulate bits.  It uses a whole integer
to
> >> > >store each bit.  It uses 8 times the storage of my PL/I
version.

> >> > A byte is not a whole integer.

> >> But it is.  It's a signed integer, using 8, or 16, or 32 bits
> >> depending on what the compiler supports.
> >Name a computer that identifies a "byte" as 16 or 32 bits.

> Richard,
> You know full well that Fortran provides word-size integers
> (typically 32 bit integers).

> However, there is no guarantee that it provides 16 or 8-bit
integers.
> On Fortrans that don't provide support for 8-bit integers, it will
use
> a word (32 bits or whatever).

Oh contraire! If the compiler doesnt recognize INTEGER(1) syntax it
will
error the statement (or shud)..

This is at least 3 times you have addressed me as Richard so taking on
the mantle of your mysterious Richard III

Now is the winter of our PL/I discontent make glorious Fortran from
 these sons of IBM..



Fri, 22 Jul 2005 22:08:02 GMT  
 Using Prime calc. as benchmark

Quote:




> Florida
> > Date: Mon, 27 Jan 2003 07:21:44 GMT






> > >> > >Your version does not emulate bits.  It uses a whole integer
> to
> > >> > >store each bit.  It uses 8 times the storage of my PL/I
> version.

> > >> > A byte is not a whole integer.

> > >> But it is.  It's a signed integer, using 8, or 16, or 32 bits
> > >> depending on what the compiler supports.
> > >Name a computer that identifies a "byte" as 16 or 32 bits.

> > Richard,
> > You know full well that Fortran provides word-size integers
> > (typically 32 bit integers).

> > However, there is no guarantee that it provides 16 or 8-bit
> integers.
> > On Fortrans that don't provide support for 8-bit integers, it will
> use
> > a word (32 bits or whatever).

> Oh contraire! If the compiler doesnt recognize INTEGER(1) syntax it
> will
> error the statement (or shud)..

Then you change the program to use something portable.
There's no guarantee that "integer (1)" will get you
anything, because that form is non-portable anyway.
Yu could get 32-bit integers with integer(1), or evem 64-bit integers!


Sat, 23 Jul 2005 10:12:22 GMT  
 Using Prime calc. as benchmark

Quote:


> > > ...
> > > On Fortrans that don't provide support for 8-bit integers, it will
> > use
> > > a word (32 bits or whatever).

> > Oh contraire! If the compiler doesnt recognize INTEGER(1) syntax it
> > will
> > error the statement (or shud)..

> Then you change the program to use something portable.
> There's no guarantee that "integer (1)" will get you
> anything, because that form is non-portable anyway.
> Yu could get 32-bit integers with integer(1), or evem 64-bit integers!

As I recall the standard, the "kind type" (the number in parentheses
in "INTEGER(1)") need not represent anything in particular.  The
requirement is that different kind types represent different precisions
and that larger kind type values indicate more precision than smaller
kind type values.  There is no requirement that kind type numbers
start at one, that they be sequential, or that they correspond to
powers of two.  So Robin is correct that "INTEGER(1)" is not
necessarily portable (though in practice it probably is).

On the other hand, there are intrinsic functions for determining the
kind type of an 8-bit integer (assuming the compiler in use supports
them) so it is possible to write a portable declaration -- as long as
the compiler supports an 8-bit integer type (not guaranteed).
Actually, the intrinsic function will return the smallest kind type
capable of holding an 8-bit integer -- depending on implementation,
that could be a 32- or even 64-bit integer; there would be no error
message.

Bob Lidral



Sat, 23 Jul 2005 11:15:09 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Using Prime calc. as benchmark

2. Using Prime calc.

3. Using Primes calculation as benchmark

4. Using Primes calculation as benchmark

5. anyone using a PRIME?????

6. Benchmark w/o using PL/I routine

7. Problem using f2c on SPEC benchmarks

8. Calc in Group Footer C4b legacy

9. G-Calc 4.2 now available

10. G-Calc's review in the current issue of Clarion Online

11. G-Calc update

12. err.$$$(1)#32:error:cif$fileopen calc.exe

 

 
Powered by phpBB® Forum Software