>>Your viewpoint is 5-10 years in the rearview mirror now.
Spooky ... I left imagination technologies in 2004.
>> I'm hiring at AWS BTW if you know any talent that gets manycore BTW.
As you said, it isn't mainstream yet. There seem to be quite a few
grad students these days who have their PC case open and a couple of
graphics cards inside though, so cheer up, the skills situation should
improve with time.
Josh
On 18/02/2014, Scott Le Grand <varelse2005.gmail.com> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Feb 18 2014 - 08:00:02 PST
