As optimistic I qualified your description of minor CPU role :)), simply
because
I have limited money to buy something better than "Intel Core i7-960" if
I don't want to loose one GPU. As much more optimistic I would qualified
Amber
performance which was nice on CPUs but which is now really impressive
thanks to it's very intelligent
customization for GPUs !
Thanks a lot to you, Ross, Robert and all the Amber developers for this
incredibly powerful tool !!!
Marek
Dne Tue, 13 Sep 2011 21:50:30 +0200 Scott Le Grand <varelse2005.gmail.com>
napsal/-a:
> I wouldn't call the view optimistic. Rather I would call it the result
> of 2
> years of observation while I wrote these kernels. If anything, I'm a
> bigger
> pessimist than Ross. One of the biggest problems with GPU adoption right
> now is the $h!+storm of half-a$$3d GPU LPU papers out there written by
> computer scientists who port half an application to the GPU but possess
> zero
> zip nada null low-level optimization talent and ultimately do little more
> than provide warehouses of ammo for the GPUs are no better than CPUs
> crowd.
>
> In any event, AMBER's performance is what happens when one both ports the
> entire algorithm to the GPU and then ruthlessly optimizes it once it's
> there. And that's currently the only way to illustrate exactly what GPUs
> can do. The same issue is faced by game console programmers and they'd
> likely agree with the above. Unfortunately, there aren't many of those
> sorts in the sciences.
>
> Scott
>
>
>
> 2011/9/13 Marek Maly <marek.maly.ujep.cz>
>
>> Hello Scott,
>> thanks for your optimistic view :))
>> After this short discussion I think that the main problem
>> (considering just single GPU jobs) will be probably "just"
>> sufficient cooling ...
>>
>> Best wishes,
>>
>> Marek
>>
>>
>> Dne Tue, 13 Sep 2011 20:15:27 +0200 Scott Le Grand
>> <varelse2005.gmail.com>
>> napsal/-a:
>>
>> > AMBER is designed to run the entire simulation in GPU-space. The CPU
>> > acts
>> > as a glorified foreman shouting out directions to the GPU as to which
>> > tasks
>> > it should run. If AMBER were rewritten from the ground up, that role
>> > could
>> > be removed entirely. The upshot is that for single-GPU runs, you
>> could
>> > probably stuff 8 GPUs into a single box and barely notice the
>> difference.
>> > And you could also use a cheap consumer CPU as well since it's mostly
>> > sitting on its butt waiting on the GPU(s).
>> >
>> > The difference between using a 4 year-old $20 CPU and a current $1000+
>> > CPU
>> > in this situation is about 2-3%.
>> >
>> >
>> >
>> >
>> > 2011/9/13 Marek Maly <marek.maly.ujep.cz>
>> >
>> >> Hi Ross,
>> >>
>> >> first of all thanks a lot for your complex answer !
>> >> In fact I assume mainly independent single GPU jobs. So if I
>> understood
>> >> well, in such case there should not be problem considering below
>> >> mentioned
>> >> motherboard/CPU/4xGPU. Am I right ?
>> >>
>> >> Best wishes,
>> >>
>> >> Marek
>> >>
>> >>
>> >>
>> >>
>> >> Dne Tue, 13 Sep 2011 18:53:34 +0200 Ross Walker
>> <ross.rosswalker.co.uk>
>> >> napsal/-a:
>> >>
>> >> > Hi Marek,
>> >> >
>> >> > I would say that the answer is, with caveats, not really. The
>> reason
>> >> for
>> >> > this is not a core to GPU ratio argument per se but actually one of
>> >> > memory
>> >> > bandwidth. For a single socket motherboard there is no way that it
>> can
>> >> > drive
>> >> > 4 PCI-E sockets flat out at x16 speed. Hence you are always going
>> to
>> >> get
>> >> > contention. Typically I would say never go beyond 2 GPUs per node
>> for
>> >> a
>> >> > single socket system. 4 GPUs per node is pushing it for a dual
>> socket
>> >> > system
>> >> > even with the highest CPU FSB speed you can get so on a single
>> socket
>> >> > system
>> >> > with a low end CPU it is definitely not going to cut it.
>> >> >
>> >> > Now if you only plan to run single GPU jobs. I.e. 4 independent
>> jobs
>> >> at
>> >> > once
>> >> > with reasonably large values for ntpr, ntwx etc then it is probably
>> >> not
>> >> > an
>> >> > issue since the memory bandwidth only really comes into play at
>> each
>> >> > output
>> >> > file or trajectory write for most types of calculations. However,
>> >> trying
>> >> > to
>> >> > run in parallel where a single job spans GPUs it really all comes
>> down
>> >> > to a
>> >> > combination of the aggregate memory bandwidth of the main CPU
>> memory
>> >> per
>> >> > GPU
>> >> > and the PCI-E bandwidth to each GPU when all are communicating flat
>> >> out
>> >> > at
>> >> > the same time. You might be able to get speedup across 2 of the
>> GPUs
>> >> if
>> >> > you
>> >> > leave the other two idle. However, running two sets of dual GPU
>> runs
>> >> or
>> >> > running a single 4 GPU run is likely to cause so much contention
>> that
>> >> see
>> >> > little or no speedup.
>> >> >
>> >> > So it really comes down to a case of the type of jobs you want to
>> run.
>> >> >
>> >> > I hope that helps.
>> >> >
>> >> > All the best
>> >> > Ross
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Marek Maly [mailto:marek.maly.ujep.cz]
>> >> >> Sent: Tuesday, September 13, 2011 7:19 AM
>> >> >> To: amber.ambermd.org
>> >> >> Subject: [AMBER] Sufficient CPU cores/GPU ratio ?
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> just a very quick technical question. I would like to know if 4
>> core
>> >> >> CPU
>> >> >> "Intel Core i7-960" might be sufficient for
>> >> >> 4 GPU machine (motherboard: Asus P6T7 WS SuperComputer - Intel
>> X58
>> >> ).
>> >> >> I
>> >> >> mean if ratio 1 CPU core/ 1 GPU might
>> >> >> be here sufficient also considering some requirements (on CPU) for
>> >> >> managing operating system etc.
>> >> >>
>> >> >> Thanks in advance for any relevant comment !
>> >> >>
>> >> >> Best wishes,
>> >> >>
>> >> >> Marek
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >
>> >> > __________ Informace od ESET NOD32 Antivirus, verze databaze 6459
>> >> > (20110913) __________
>> >> >
>> >> > Tuto zpravu proveril ESET NOD32 Antivirus.
>> >> >
>> >> > http://www.eset.cz
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Tato zpráva byla vytvořena převratným poštovním klientem Opery:
>> >> http://www.opera.com/mail/
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> > __________ Informace od ESET NOD32 Antivirus, verze databaze 6459
>> > (20110913) __________
>> >
>> > Tuto zpravu proveril ESET NOD32 Antivirus.
>> >
>> > http://www.eset.cz
>> >
>> >
>> >
>>
>>
>> --
>> Tato zpráva byla vytvořena převratným poštovním klientem Opery:
>> http://www.opera.com/mail/
>>
>> _______________________________________________
>> 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
>
> __________ Informace od ESET NOD32 Antivirus, verze databaze 6461
> (20110913) __________
>
> Tuto zpravu proveril ESET NOD32 Antivirus.
>
> http://www.eset.cz
>
>
>
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Sep 13 2011 - 14:30:02 PDT
