Hi Ross,
So maybe we should just wrap the stringizing stuff in an #ifdef CUDA (or
whatever it is)? Sorry I am not more up-to-date on this stuff; I just have
not been set up to play with this stuff yet. But if we did that, we would
probably effectively be putting ourselves in a position where we can ignore
old systems, since they are pretty unlikely to be used with cuda anyway...
Regards - Bob
----- Original Message -----
From: "Ross Walker" <ross.rosswalker.co.uk>
To: "'AMBER Developers Mailing List'" <amber-developers.ambermd.org>
Sent: Monday, March 29, 2010 2:03 PM
Subject: RE: [AMBER-Developers] Help with NVIDIA Compilation using ifort
> Hi Bob,
>
> In terms of building PMEMD in AMBER 11 the standard build (serial or MPI)
> should work with all of the compilers that the standard
> amber11/src/configure script supports. This includes gnu,intel and pgi.
> Maybe some others. PGI I have not tested because I do not have a copy. Gnu
> and Intel I test regularly.
>
> My intention is that the pmemd.cuda version can be built with either gnu
> or
> Intel. Any other compiler options the configure script should reject if
> you
> specify -cuda on the command line.
>
> As for building PMEMD on its own all the original build scripts are still
> there and one just needs to use configure.advanced and makefile.advanced
> in
> the pmemd directory.
>
> E.g.
>
> cd $AMBERHOME/src/pmemd/
> ./configure.advanced linux_em64t ifort mvapich pubfft bintraj
> make -f Makefile.advanced
>
> This is, and should remain for this release, undocumented since it is
> meant
> only for developers and advanced users and the build scripts need a lot of
> work to update them for current generation machines and compilers.
>
> Things like IBM etc can still be used if one uses the advanced Makefile.
>
> It could be done in the standard AMBER 11 build configure script but this
> needs someone who has both the time and access to the hardware to
> volunteer
> to do it.
>
> All the best
> Ross
>
>
>> -----Original Message-----
>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>> bounces.ambermd.org] On Behalf Of Robert Duke
>> Sent: Monday, March 29, 2010 10:45 AM
>> To: AMBER Developers Mailing List
>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
>> ifort
>>
>> Yes, but those are not the two compilers I am worried about... We
>> really
>> need to understand what compilers we intend to support in this release,
>> and
>> what the impact of the various c preprocessors would be. If we make a
>> decision to support, say, gcc, intel, pgi, and ibm (the minimal list I
>> can
>> come up with - I have not a clue about mac's, or how you guys do
>> anything
>> with cygwin), then so be it. But we should have a list. I used to
>> support
>> a wide range of stuff for pmemd; I am aware that a lot of those
>> platforms,
>> especially the risc stuff, are now effectively dead. It would be my
>> guess
>> that we could use stringizing, but should check it out on all the above
>> stuff at a minimum (pretty sure no issues with intel or gcc; ibm you
>> never
>> know). I consider it a clean and good solution, as long as the
>> preprocessors are there. I suppose one could also insist that on
>> non-compliant platforms, folks just have to use the gcc preprocessor.
>> But
>> it has to be worked out...
>> Scott, do you or does some collective somebody have access to
>> everything
>> "supported", is there a "supported" list, etc. It would be pretty easy
>> to
>> check stringizing on some small list of platforms, if you have them...
>> Regards - Bob
>> ----- Original Message -----
>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>> Sent: Monday, March 29, 2010 1:32 PM
>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
>> ifort
>>
>>
>> > Just out of curiosity I tried to compile the following:
>> >
>> > example.cc:
>> >
>> > extern "C" {
>> >
>> > int serious_subroutine() {
>> > for (int i = 0; i < 1000000; ++i) {
>> > int j = i*i;
>> > }
>> > return 8;
>> > }
>> >
>> > int serious_subroutine_() __attribute__ ((weak, alias
>> > ("serious_subroutine")));
>> > int serious_subroutine__() __attribute__ ((weak, alias
>> > ("serious_subroutine")));
>> >
>> > } // extern "C"
>> >
>> > using g++ 3.4.6 and icpc 10.1.022 -- in both cases I got
>> >
>> > nm example.o
>> > 00000000 T serious_subroutine
>> > 00000000 W serious_subroutine_
>> > 00000000 W serious_subroutine__
>> >
>> > which means that icpc does understand __attribute__ (...) and,
>> > consequently, this can be probably given a try if the problem
>> > is "to be able to use either gnu or intel compilers to build
>> > pmemd with CUDA support".
>> >
>> > Best,
>> >
>> > Volodymyr
>> >
>> > On Mon, March 29, 2010 13:03, Robert Duke wrote:
>> >> Yeah, that is what I am worried about - vendor compilers don't
>> >> necessarily
>> >> conform to gcc, so finding stuff to use in gcc is not a great idea.
>> >> Adhering to certain c standards is a better idea, but I know that at
>> >> least
>> >> in the past, the functionality found in c preprocessors was still
>> "hit
>> >> and
>> >> miss", to describe it kindly. So we just need to look out for this.
>> If
>> >> anyone is still using something old, they might try it and see what
>> >> happens.
>> >> I used to hit old ibm and and sgi machines for this purpose, but I
>> don't
>> >> have them anymore.
>> >> Regards -Bob
>> >>
>> >> ----- Original Message -----
>> >> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>> >> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>> >> Sent: Monday, March 29, 2010 12:37 PM
>> >> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
>> ifort
>> >>
>> >>
>> >>>> The only issue I can think
>> >>>> of is if there is a c preprocessor out there somewhere that can't
>> >>>> handle
>> >>>> stringizing - that may be why I avoided doing this in the first
>> pass.
>> >>>
>> >>> A good point to look for a quite portable solution is "gmacros.h"
>> from
>> >>> glib (http://library.gnome.org/devel/glib/), I believe.
>> >>>
>> >>> Another way would be to use gcc's "alias" __attribute__
>> >>>
>> >>> http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-
>> Attributes.html#Function-Attributes
>> >>>
>> >>> alias ("target")
>> >>> The alias attribute causes the declaration to be emitted as an
>> alias
>> >>> for another symbol, which must be specified. For instance,
>> >>>
>> >>> void __f () { /* Do something. */; }
>> >>> void f () __attribute__ ((weak, alias ("__f")));
>> >>>
>> >>>
>> >>> defines `f' to be a weak alias for `__f'. In C++, the mangled
>> name
>> >>> for
>> >>> the target must be used. It is an error if `__f' is not defined in
>> the
>> >>> same translation unit.
>> >>>
>> >>> Not all target machines support this attribute.
>> >>>
>> >>> Just random comments,
>> >>>
>> >>> Volodymyr
>> >>>
>> >>>> Some
>> >>>> folks who use a wider variety of platforms than I do might want to
>> >>>> comment
>> >>>> on that.
>> >>>> Regards - Bob
>> >>>> ----- Original Message -----
>> >>>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
>> >>>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>> >>>> Sent: Monday, March 29, 2010 12:18 PM
>> >>>> Subject: RE: [AMBER-Developers] Help with NVIDIA Compilation using
>> >>>> ifort
>> >>>>
>> >>>>
>> >>>>> One could possibly use a macro like
>> >>>>>
>> >>>>> #ifdef ASSUME_JUST_ONE_TRAILING_UNDERSCORE
>> >>>>> # define FORTRANIZE(name) name##_
>> >>>>> #else
>> >>>>> # define FORTRANIZE(name) name##___
>> >>>>> #endif
>> >>>>>
>> >>>>> or something like that.
>> >>>>>
>> >>>>> Best,
>> >>>>>
>> >>>>> Volodymyr
>> >>>>>
>> >>>>> On Mon, March 29, 2010 11:59, Ross Walker wrote:
>> >>>>>> Hi Tim
>> >>>>>>
>> >>>>>> We already have something similar to this in
>> >>>>>> src/pmemd/src/cuda/gpu.cpp
>> >>>>>>
>> >>>>>> extern "C" void gpu_dump_dval_(double* pDouble)
>> >>>>>> {
>> >>>>>> ...
>> >>>>>> }
>> >>>>>>
>> >>>>>> I was hoping to find a way to do this without having to go
>> through
>> >>>>>> and
>> >>>>>> make
>> >>>>>> additional copies of everything for Intel.
>> >>>>>>
>> >>>>>> All the best
>> >>>>>> Ross
>> >>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: amber-developers-bounces.ambermd.org [mailto:amber-
>> developers-
>> >>>>>>> bounces.ambermd.org] On Behalf Of Timothy J Giese
>> >>>>>>> Sent: Friday, March 26, 2010 4:15 PM
>> >>>>>>> To: AMBER Developers Mailing List
>> >>>>>>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation
>> using
>> >>>>>>> ifort
>> >>>>>>>
>> >>>>>>> I've only done a few things with cuda/fortran, but I basically
>> >>>>>>> treat it like how I treat c/fortran, i.e., in C, create
>> >>>>>>> subroutine_ and have it simply call subroutine.
>> >>>>>>>
>> >>>>>>> I've never really thought about pros and cons of this.
>> >>>>>>>
>> >>>>>>> For example
>> >>>>>>>
>> >>>>>>> void init_template_kernel_drv(int &, int &, int &);
>> >>>>>>> void free_template_kernel_drv();
>> >>>>>>> void run_template_kernel_drv(int &, double *);
>> >>>>>>>
>> >>>>>>> extern "C"
>> >>>>>>> {
>> >>>>>>> void init_template_kernel_(int &, int &, int &);
>> >>>>>>> void free_template_kernel_();
>> >>>>>>> void run_template_kernel_(int &, double *);
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> void init_template_kernel_(int & max_blocks,int &
>> threads_per_block,
>> >>>>>>> int
>> >>>>>>> & buflen)
>> >>>>>>> {
>> >>>>>>> init_template_kernel_drv(max_blocks, threads_per_block,
>> buflen);
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>> void free_template_kernel_()
>> >>>>>>> {
>> >>>>>>> free_template_kernel_drv();
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> void run_template_kernel_(int & na, double * A)
>> >>>>>>> {
>> >>>>>>> run_template_kernel_drv(na, A);
>> >>>>>>> }
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I found some discussion on the intel boards. Not sure how
>> >>>>>>> useful it is.
>> >>>>>>>
>> >>>>>>> http://software.intel.com/en-us/forums/showthread.php?t=56872
>> >>>>>>>
>> >>>>>>> -Tim
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> AMBER-Developers mailing list
>> >>>>>>> AMBER-Developers.ambermd.org
>> >>>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> AMBER-Developers mailing list
>> >>>>>> AMBER-Developers.ambermd.org
>> >>>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> AMBER-Developers mailing list
>> >>>>> AMBER-Developers.ambermd.org
>> >>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> AMBER-Developers mailing list
>> >>>> AMBER-Developers.ambermd.org
>> >>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> AMBER-Developers mailing list
>> >>> AMBER-Developers.ambermd.org
>> >>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> AMBER-Developers mailing list
>> >> AMBER-Developers.ambermd.org
>> >> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>
>> >
>> >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> > AMBER-Developers.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >
>> >
>>
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 29 2010 - 11:30:03 PDT
