curious about 8 byte LOGICAL...
in [Fortran]
|
Prev: CVF help -- was: Re: It Hurts When I Do This -- diversion...
Next: Reading unknown number of lines in unknown number of files
From: glen herrmannsfeldt on 23 Apr 2008 01:50 e p chandler wrote: (snip) > 1. So when the default numeric storage unit is 8 bytes on PCs, what > happens to DOUBLE PRECISION? > 2. Is it legal to set aside 8 bytes for a REAL but use only 4? > 3. Computers with 64 bit words ... we've never had _that_ before, have > we? My guess is that they will cheat. In the 16 bit days, (such as the PDP-11 and DG Eclipse) they stored default integers in 16 bit words by default. The DEC compilers I know had the option of storing in 32 bits, but I believe still only used 16. Even with cheap memory, I find it unlikely that the default will be eight byte integer and real, with 16 byte double precision. (Until good hardware support for 16 byte reals.) -- glen
From: robert.corbett on 23 Apr 2008 02:31 On Apr 22, 10:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Even with cheap memory, I find it unlikely that the default will > be eight byte integer and real, with 16 byte double precision. > (Until good hardware support for 16 byte reals.) Even when there is hardware support for 128-bit floating-point, the default type sizes are unlikely to double. The biggest bottleneck in many high-performance applications is memory bandwidth, not the speed of floating-point operations. As long as buyers of high-performance machines care about high-performance, compiler vendors are unlikely to make programs take twice as long. Programmers are going to have to get used to using INTEGER*8 variables to hold subscript values. Bob Corbett
From: glen herrmannsfeldt on 23 Apr 2008 03:27 robert.corbett(a)sun.com wrote: > On Apr 22, 10:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> > wrote: >>Even with cheap memory, I find it unlikely that the default will >>be eight byte integer and real, with 16 byte double precision. >>(Until good hardware support for 16 byte reals.) > Even when there is hardware support for 128-bit floating-point, > the default type sizes are unlikely to double. The biggest > bottleneck in many high-performance applications is memory > bandwidth, not the speed of floating-point operations. As long > as buyers of high-performance machines care about high-performance, > compiler vendors are unlikely to make programs take twice as long. > Programmers are going to have to get used to using INTEGER*8 > variables to hold subscript values. Actually, I think it will still be a little while before it is really a problem. For C, pointer variables will have to go to 64 bits, but it will be much less important for subscript values. For four byte integer and eight byte real, you can address 8GB and 16GB respectively with a signed 32 bit integer. (Double that if you allow negative values.) Most programs need more than one array, so the needed size will be even smaller. For a square matrix, even 16 bit integers will be big enough for 4GB. The subscript calculation still has to be done in more than 32 bits, and compilers should adjust to that. -- glen
From: Ian Bush on 23 Apr 2008 05:43 As if by magic, glen herrmannsfeldt appeared ! > robert.corbett(a)sun.com wrote: > >> On Apr 22, 10:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> >> wrote: >> >> Programmers are going to have to get used to using INTEGER*8 >> variables to hold subscript values. > > Actually, I think it will still be a little while before it is > really a problem. Well I'm coming across codes that are hitting it, though I can't claim that it is very common ( or elegant ! ) The situation is packed symmetric matrices, and in particular runs on parallel machines where, for reasons I don't want to go in to, they are either replicated or stored in a shared memory segment. Actualy the parallel is not a requirement, it's just to perform these runs one processor does not give enough ooomph, Ian
From: Horand.Gassmann on 23 Apr 2008 06:58
On Apr 23, 2:15 am, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > <andrej.panj...(a)climatechange.qld.gov.au> wrote in message > > news:a8338933-0afe-4e7f-b106-04cb2d84d492(a)a23g2000hsc.googlegroups.com... > > > Quite a few compilers support different representations for LOGICAL > > types: 1 byte, 2 byte 4 byte...and 8 byte? > > What applications are there for 8 byte LOGICAL types? (Or for 2 byte > > types?) > > Storage association rules require than a default INTEGER takes up > the same space as a default LOGICAL. N1601.pdf, section 16.4.3.1: This looks to me like a hole in the language. Is there a SELECTED_LOGICAL_KIND that would allow me to specify (portably) the smallest available logical type, for instances where I do not want to burn up 128 bits to store T/F values in a large array? |