You can argue all you want. Embedded programmers (of which I count myself
as one given 10+ years of experience with video game consoles and set top
boxes pre-NVIDIA) are in huge demand today because of cell phones and their
insanely bad battery lives. Your viewpoint is 5-10 years in the rearview
mirror now. If you're not making industry wages doing this, you suck at it
and you need to do something else.
What your typical embedded programmer is not so familiar with is
translating a traditionally serial algorithm into tens of thousands of
threads and this is where they all fall flat on their faces during job
interviews and on the job. I'm hiring at AWS BTW if you know any talent
that gets manycore BTW. Because I cannot find the talent out there that
"gets" manycore. Either Google sucks them up with their perks and then
assigns them to writing python scripts in exchange for free food and
subsidized massage or they're making horrendous judgment calls on exposing
OpenCL within Android or they're Szilard Pail or Ivan Ufimtsev and there's
about 18 more of them out there, all busy.
Case in point: when I left NVIDIA for Google they tried porting AMBER from
Fermi to Kepler internally rather than rely on me. As a result, GTX680
went out the door at 43 ns/day compared to GTX 580's 51 ns/day. This is
because there were fundamental regressions in the HW w/r to required
threadcounts and functional unit throughput. This led them to hand me one
and 2 weeks later it broke 70 ns/day and went up from there. I wouldn't
expect such turbulence to abate any time in the near future.
In closing, effectively no one really gets manycore yet. The industry is
just coming to terms with multithreading now and scratching its collective
head about learning "lock-free computing" which has been at the heart of
CUDA since 2006. Finally, from first-hand experience, most industry
engineers view multithreading at the task-parallel level within some
godawful scripting language easily squandering 90-99.9% of attainable
computation in doing so. Such talent writes horrendous GPU code.
On Tue, Feb 18, 2014 at 6:43 AM, Josh Berryman <
the.real.josh.berryman.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.
>
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Feb 18 2014 - 07:30:02 PST
