>>There are approximately 20 people in the world who can write efficient GPU
>>kernels for programs like AMBER and maybe 2,000 that could do it badly.
I'd argue that anyone who is used to embedded programming should be
able to figure it out pretty quickly. Long pipelines, quirky
instruction sets, slow/non-existent floating point, multi-layered
parallelism .... any of that sound familiar? Wages are not even high
for that kind of work, it has become unsexy due to having been around
since forever.
If you need someone who also understands physics and biochemistry then
that could be a problem, but expert programmers who have an idea about
getting the best from (any) specific architecture? There are a lot of
those, coding for everything from the ICs in flight simulators to
industrial robots to consumer hi-fi.
Josh
On 18/02/2014, Scott Le Grand <varelse2005.gmail.com> wrote:
> There are approximately 20 people in the world who can write efficient GPU
> kernels for programs like AMBER and maybe 2,000 that could do it badly.
>
> That is the underlying problem, not running the simulation entirely on the
> GPU.
>
> Get universities to teach manycore instead of concurrent Java plus
> scripting languages and this problem will resolve itself. It's not
> entirely unlike the hostility I faced in grad school and post-doc days for
> using C instead of FORTRAN.
>
> This problem will solve itself in time, but not on any of our schedules.
>
> Sfott
>
>
> On Tue, Feb 18, 2014 at 2:27 AM, Scott Brozell
> <sbrozell.rci.rutgers.edu>wrote:
>
>> On Mon, Feb 17, 2014 at 11:42:13PM -0500, Scott Brozell wrote:
>> > On Wed, Feb 12, 2014 at 09:46:15PM -0500, David A Case wrote:
>> > > On Wed, Feb 12, 2014, Jason Swails wrote:
>> > > on the GPU." We *should* establish a better mechanism for suggesting
>> and
>> > > vetting requests for new GPU features. But I don't (yet) see that
>> another
>> > > code fork is needed to accomplish this.
>> >
>> > 1.
>> > Why not create a 'new features' Severity bug in bugzilla
>> > and cc the am-dev list when it is created:
>> > Every developer should be subscribed to am-dev, so every developer
>> > gets notified. Those that want to vet can do so via bugzilla.
>>
>> Hmm, emails from bugzilla to this list don't seem to work (yet).
>>
>> > 2.
>> > I agree that existing-feature-bla may not merit another code fork.
>> > But let me throw out another code fork:
>> > heterogeneous-platform-ambermd
>> > Its design would be along the lines of the gromacs 4.6 rewrite
>> > where, eg, non-bonded forces, are offloaded to gpus or other compute
>> resources.
>>
>> Some were too fast for me, but here's the new feature report for this
>> http://bugzilla.ambermd.org/show_bug.cgi?id=258
>>
>> scott
>>
>>
>> _______________________________________________
>> 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 Tue Feb 18 2014 - 07:00:03 PST
