g95 errors

[Axel]

On Mar 21, 7:30 am, radsci2008 <9srh8rw... at jetable.org> wrote:
> Hi Teo-
>
> Really, I'm not trying to flog any horses, dead or otherwise. :/

please flog yourself. _you_ are refusing to get the point!


> On programs that use 64-bit integer default, like GAMESS, this yields
> faster code.  I understand that it must be obvious to developers what

that is because GAMESS uses a special trick to index integrals
that works better with integer*8 and a big advantage for calculations
with very large number of integrals _and_ particularly parallel runs.
i guess they were simply to lazy to rewrite the whole code to specify
integer*8 throughout...

you have to realize that fortran in particular was designed to be
mostly system agnostic and thus does not care much about the
specifics of what a platform or a compiler does, provided it is
within the limitations of the standard.

> a program does and does not use, and now you've made clear that when
> cp2k uses 64-bit reals it defines them as doubles and uses integers
> which are 32-bits so that 64-bit integer code would yield no
> advantage, but it's far from obvious to someone who just wants to
> compile and use the code and would like it to be as fast as may be
> feasible, but doesn't know the particulars of the code architecture.

what you should also note, and this is a common misconception,
that 64-bit code should be faster than 32-bit code. this is only true
for a few exceptions (e.g. encryption software). most of the time
the 64-bit version is about 20% slower due to memory (bandwitdh)
waste and less efficient cache utilization, regardless of the
platform.
the only exception is x86_64 where the change from 32-bit to
64-bit include a doubling number of general purpose registers
and the resulting speedup of about 20% compensates for the loss.
the ia32 architecture suffers very much lack of registers...

i am sorry if it is not obvious to you, but if you want to use
actively
developed software, you just have to invest some time into
understanding of the related background. otherwise it would
be like buying a shotgun without knowing how to shoot. this
would make it very dangerous to you and others. please be
considerate.

> > Be safe and use the standard fortran version of g95: http://
> > ftp.g95.org/g95-x86_64-64-linux.tgz
>
> I'll try it.  This is the first, though, that I've seen either version
> described as "standard."  The g95 site describes the 32-bit D.I.
> version as compatible with "older" programs.

yes. it is compatible _because_ it follows the standard.

> With the 64-bit D.I., -r4 -i4 got further but still failed to compile
> without errors, and this should be the same as the 32-bit D.I., but

why -r4??? didn't you read the previous posts?

> apparently there's some kind of difference given Yunfeng's results.

that is a completely unrelated problem.

> IIRC, double precision as 128-bit long is the case for the 64-bit D.I.
> g95.  (I'd have to check files on a machine that isn't readily

no it is not!

> accessible for an old version of GAMESS; my recollection of the comp
> file is that both the pgi compiler and what worked for g95 was 16-byte
> longs; the current g95 manual says nothing about doubles.  Seems like
> a question for Andy Vaught.)

16-byte longs would be 128bit and a long is an integer in "C/C++".
and that would violate the understanding of most c/c++ codes in turn,
where 128-bit integers would be a 'long long'.

please check your facts before posting.

thanks,
   axel.


> Thanks.