Let me propose another quite simple and yet efficient solution on a
heterogeneous cluster:
Compile on the machine with the least hardware features w/o changing any
of the configure options (i.e. using xHost).
The resulting build works and uses the intersection of advanced hardware
features on all machines in your cluster (SSE 4.1 in your case). This is
what I have been doing many times now, and it really saves a lot of work.
JP
On 13.01.2015 18:20, Novosielski, Ryan wrote:
> Wouldn't there be performance tradeoffs there? I'd think that at least supporting 4.1, in my case, would result in faster execution.
>
> ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
> || \\UTGERS |---------------------*O*---------------------
> ||_// Biomedical | Ryan Novosielski - Senior Technologist
> || \\ and Health | novosirj.rutgers.edu<mailto:novosirj.rutgers.edu>- 973/972.0922 (2x0922)
> || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
> `'
>
> On Jan 12, 2015, at 20:45, Daniel Roe <daniel.r.roe.gmail.com<mailto:daniel.r.roe.gmail.com>> wrote:
>
> Hi,
>
> Personally, on clusters like that I usually just configure with the
> '-nosse' flag to avoid the issue altogether.
>
> -Dan
>
> On Monday, January 12, 2015, Novosielski, Ryan <novosirj.ca.rutgers.edu<mailto:novosirj.ca.rutgers.edu>>
> wrote:
>
> Hi all,
>
> I recently ran into the following error at runtime:
>
> "Please verify that both the operating system and the processor support
> Intel(R) SSE4_2 and POPCNT instructions."
>
> The reason for this is that we have some nodes with Nehalem chipsets and
> some with Harpertown chipsets on our cluster, and the master node is a
> newer machine that supports some of the newer instructions. Looking through
> the —full-help configure option, I saw that I could define SSE_TYPES to say
> which CPU instructions should be supportable at runtime. However, I tried
> building with SSE types set to SSE4.2,SSE4.1 and the reverse even though I
> doubted that would make any difference. It appears as if it does add
> -axSSE4.2,SSE4.1 to the appropriate places during the build, which from my
> read of the Intel documentation is exactly what it should do. However, when
> built, the code behaves the same way with the same error messages on the
> Harpertown nodes. I don’t see a way to disable POPCNT, but it appears as if
> SSE4.1 machines don’t support it, so I would assume it is not used when the
> runtime dispatcher selects SSE4.1.
>
> I was not aware of auto CPU dispatch before today, so I’m not sure if I’m
> doing something wrong somehow. Amber version is 14, Intel compilers are
> 15.0.1.
>
>
> ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
> || \\UTGERS |---------------------*O*---------------------
> ||_// Biomedical | Ryan Novosielski - Senior Technologist
> || \\ and Health | novosirj.rutgers.edu<mailto:novosirj.rutgers.edu> <javascript:;> - 973/972.0922
> (2x0922)
> || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
> `'
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org> <javascript:;>
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 307
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jan 14 2015 - 04:30:02 PST
