3:46 p.m.
Does someone know a distribution/operating system, that rather uses the
GPU for "working", not the CPU? [by default]
Or this solution is still in the "beginning part"?
Thanks for any tips, link, suggestions.
11:47 a.m.
Robert Myers wrote:
Some recent threads on comp.arch have pursued the subject of
non-sequential, high-bandwidth access to memory very aggressively.
Those who are interested in why GPU's aren't necessarily god's answer
to the needs of HPC might want to have a look.
If only as a place to track any emerging new tools, this could be useful. Thanks
for the pointer.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
10:04 p.m.
On Fri, Jul 16, 2010 at 10:35 PM, JD <jd1008(a)gmail.com> wrote:
So, what would you say is/are the class/classes of problems that would
benefit greatly from a high flops gpu, but without the sort of bus
bandwidth you would like to see?
Almost any problem that is embarrassingly parallel or nearly so is
potentially a candidate for low-bandwidth computing. Ray tracing is the
primo example. Almost any linear problem is potentially embarrassingly
parallel, and, if you don't want to go through the work of exposing the
embarrassingly parallel nature of the problem, there are the tricks that
make the linpack benchmark so popular for selling "supercomputers" that have
absurdly small bisection bandwidths.
My question, though, is, if that's the kind of problem you have, why not do
it on a distributed platform and teach students how to use distributed
resources? If you're Pixar, I understand why you'd want a well-organized
farm of GPU's, but if you just want to replicate what LLNL (Lawrence
Livermore) was doing, say, ten years ago, are you doing your students any
favor by giving them a GPGPU instead of the challenge of doing real
distributed computing? Conceivably, watts per flop (power consumption)
makes GPGPU's the hands down winner over distributed computing for problems
that are embarrassingly parallel or nearly so. Inevitably, though, people
will want clusters of GPUGPU's, so you'll wind up doing distributed
computing, anyway.
If you rewrite your applications for the one-off architectures typical of
GPU's, so that you have to do it all over again when the next generation
comes out, have you really done yourself any favors?
I don't claim that there are simple or obvious answers, but it's just too
easy for people to be blown away by huge flops numbers. What I'm afraid of
has already started to happen as far as I'm concerned, which is that all
problems will be jammed into the low-bandwidth mold, whether it's
appropriate or not.
Robert.
8:12 p.m.
On 07/15/2010 03:44 PM, JD wrote:
On 07/15/2010 01:58 PM, Michael Miles wrote:
> On 07/15/2010 11:38 AM, JD wrote:
>
>> On 07/15/2010 11:23 AM, Michael Miles wrote:
>>
>>
>>> On 07/15/2010 12:18 AM, JD wrote:
>>>
>>>
>>>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>>>
>>>>
>>>>
>>>>> On Thu, Jul 15, 2010 at 5:27 AM, john
wendel<jwendel10(a)comcast.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Agreed that an OS kernel hasn't much use for a GPU. But it
should be
>>>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a
couple
>>>>>> of usb ports to the card and move X completely to the video card.
Just
>>>>>> like a remote X server only in the same box.
>>>>>>
>>>>>> I really think the OP was referring to having user mode code
take
>>>>>> advantage of the high processing power of modern GPUs. It works
now, but
>>>>>> could be improved if the OS contained specialized scheduling
support for
>>>>>> these kinds of jobs.
>>>>>>
>>>>>>
>>>>>>
>>>>> I understand that the GPU has no page faults, and is missing many of
>>>>> what we regard as the essential functions of a normal processor?
Also
>>>>> getting large amounts of data in or out of the GPU is slow - it is
>>>>> fast partly because there is a lot less overhead compared to a
single
>>>>> processor and partly from the advantage of multiple cores. I was
>>>>> speaking to someone who has been working with GPU processing for
>>>>> several years and was skeptical about getting code to run reliably
>>>>> across different GPUs... and of course CUDA is vendor specific as
fa
>>>>> as I know? So speed gain is dependent on the kind of processing
needed
>>>>> but if anything goes wrong then it can easily crash the system.
>>>>>
>>>>> Anyone had any experience with using the GPU could perhaps comment?
>>>>>
>>>>>
>>>>>
>>>> Sorry to barge in this late into this thread....
>>>> Was the originator of the thread interested in the kernel
>>>> to use the gpu for floating point operations or integer
>>>> operations?
>>>> If floating point, the x86 (among others) already has an
>>>> integrated fpu, and the integer logic is already in the cpu (or alu).
>>>> So I do not understand what sort of computations the originator
>>>> of the thread would like to see done on the gpu.
>>>>
>>>> jd
>>>>
>>>>
>>>>
>>> The other OS's Mac and Windows are using the GPU in its video
>>> conversion programs.
>>> The newer programs will have selections to activate the GPU for computation.
>>>
>>> I have been using the GPU for scientific computation for quite a while now.
>>> Seti@home is very much a hobby and it takes samples from the areciebo
>>> telescope and analyse data looking for "You guessed it, ET"
>>> It will crunch numbers very fast compared to a normal CPU.
>>>
>>> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
>>> Gflops .
>>>
>>> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
>>> to a full teraflop.
>>> That kind of speed would be well accepted if an OS would use it
>>> generally or software that is written for Video conversion to use it
>>> greatly reducing time.
>>>
>>>
>>> That's what I would like to see, more focus on speeding up video
>>> conversion especially with HD video and it seems that the GPU is a very
>>> inexpensive way to add a lot of power to your machines
>>>
>>>
>> A teraflop?? WHoa! Can the PCI bus really feed the gpu with
>> an instruction stream that will yield that performance?
>> I mean most pc's out there are in people's homes still pci (33 or 66 MHz
>> bus).
>> Relatively, fewer are on pci x16 which is a much faster bus.
>>
>> Thanks for your feedback.
>>
>>
>>
>>
> PCI-E only will handle that kind of speed.
>
> It's also good to have a video card with fast ram and lots of it.
>
> The new Fermi chips coming out and mindboggling fast, over a tflop
>
> So yes seeing them take over some of the bigger computations for video
> conversion would be great.
>
> For instance the Nvidia 295 has 240 stream processors and is able to do
> 1788.48 gflops.
> Put two or three together in a sli config and you've got some power there
>
>
> http://en.wikipedia.org/wiki/GeForce_200_Series
>
> This page will give you an idea of what these things do.
>
>
> The 400 series uses Fermi and lets take the 480 gtx for instance, 480
> stream processors
> Now we are talking about 4+ tflops.
>
> That's getting quick
>
> As well Nvidia cards are well noted for over clocking.
>
> My little 9400 runs at 550 and shader runs at 1375.
> I can push those up to 700 and 1800 shader and no artifacts and no problems.
>
>
>
>
>
> Michael
>
This is the kind of technology that is needed to solve huge mathematical
problems.
Most smaller universities and colleges do not have massively parallel
supercomputers that are
vector processors. This could make it easy for such colleges and small
university research
projects to have some decent computational power.
At the same time we have to be wary of the export laws for such devices
because one thing
that I had read some years back is that breaking cyphers is exactly what
such powerful processors
can be used for or adapted to be used for. For many years, this has been
a tug of war between
industry on one side, and the department of defense and the NSA on the
other.
I would like to see it implemented in Ray tracing.
I am a 3D Junkie and have been using Lightwave since the Amiga 2000 and
the Video toaster.
I still use the Windows version of Lightwave and complex ray tracing
still takes far too long using my Phenom 2 965.
Partly because the program is not using sse3 only sse2
I would like to send off work to a "Render farm (the GPU)" like we used
to send it off to the Raptor ( Alpha series) for rendering.....
That would reduce time of say a 10 minute animation from years to weeks.
Even now with the fast speed of today's cpu's animations of that size
and high resolutions take a very long time.
Using a GPU on these would be ideal.
It would take a savy programmer with some time and a reason to do so.
With the Cuda sdk 3.0 the tools are there, just not me as I have no clue
when it comes to programming
The medical field and research field would benefit as some tasks for
computation are not even attempted for the length of time it would take,
so it does not even get done.
So if the same task was done on a machine using Cuda or Cal would really
advance certain fields of technology.
Especially since most serious professional computers are not on Windows
but Linux or Unix based systems it would beneficial to have the support
for GPU computations built in to the OS itself
Michael
9:56 p.m.
john wendel wrote:
On 07/14/2010 08:43 PM, Bill Davidsen wrote:
> Jozsi Avadkan wrote:
>> Does someone know a distribution/operating system, that rather uses the
>> GPU for "working", not the CPU? [by default]
>>
> Other than internal use as part of a display driver, what do you think a kernel
> would do with a GPU? There essentially no FP in the kernel.
>
>> Or this solution is still in the "beginning part"?
>>
>> Thanks for any tips, link, suggestions.
>>
Agreed that an OS kernel hasn't much use for a GPU. But it should be
easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
of usb ports to the card and move X completely to the video card. Just
like a remote X server only in the same box.
I really think the OP was referring to having user mode code take
advantage of the high processing power of modern GPUs. It works now, but
could be improved if the OS contained specialized scheduling support for
these kinds of jobs.
Back when a Cray2 was hot stuff I know a bunch of work was done to get the
vector hardware working right, and a company call Convex had a really good
parallelizing compiler. I think the place for doing stuff like that remains in
the compiler and library, and not so much in the os.
GPU is good for FFT and DCT and all manner of singnal processing (in addition to
graphics), no so much for general work. Even programming the old 8087 FPU was a
bear, although I did get ~50% faster solution to a scaling problem "back when,"
mainly by keeping more in the registers and no using slow memory. For short
vectors the GPU setup time may make it no faster than SSE instructions.
Note that in Linux I believe that any use of SSE or FP results in more registers
being stored during context switch. I would bet that using the GPU would have
similar problems unless access was serialized. Neat problem, isn't mine.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
7:07 p.m.
On Fri, Jul 16, 2010 at 7:55 PM, Christofer C. Bell <
christofer.c.bell(a)gmail.com> wrote:
On Fri, Jul 16, 2010 at 6:49 PM, Robert Myers
<rbmyersusa(a)gmail.com>wrote:
> Whether you like it or not, and whether, even more important, you
> understand it or not, the architecture of a computer has a big impact on the
> kinds of models you can implement with any degree of efficiency on the
> computer. Hanging lots of flops on inadequate bandwidth is popular because
> you can get a high ranking on the Top 500 list with a minimal expenditure,
> but it also means that you can't do an important calculation like a global
> FFT at anything like reasonable efficiency. Flops are almost free.
> Bandwidth is expensive. Unfortunately, what is almost free (flops) can be
> nearly useless for, say, an FFT unless you have the bandwidth to move data
> around globally fast enough.
>
>
You need to make friends with a guy named Edward Lorenz. Bandwidth has
nothing to do with it. Do you even know what this term means?
Look.
I've been through this argument plenty of times in forums where there are
people who would just glare at you if you had the gall to ask them if they
knew what bandwidth meant. Imagine me glaring at you.
What I'm talking about may or may not have anything to do with chaos theory.
At the moment, there is no way of knowing because there are no computers
with the capability of accurately simulating the interaction between hugely
disparate physical scales for very large problems. The problem, as I
perceive it, is that it is much easier to make plausible looking color plots
than it is to do good computational physics.
> I don't think name-calling and labeling ever helps.
>
Then stop doing it.
You should have thought about the advice as it applies to yourself before
proposing to offer further advice to me. You were the one who used an
offensive label, not me. I only asked you to consider what it would feel
like if I allowed myself the same "mote in my neighbor's eye" approach to
discussion.
Robert.
2:47 p.m.
On Tue, Jul 13, 2010 at 4:46 PM, Jozsi Avadkan <jozsi.avadkan(a)gmail.com> wrote:
Does someone know a distribution/operating system, that rather uses
the
GPU for "working", not the CPU? [by default]
Or this solution is still in the "beginning part"?
Just saw this posted a moment ago:
http://hardware.slashdot.org/story/10/07/15/181245/Why-Gaming-Chips-Are-M...
7:21 p.m.
On 07/17/2010 01:12 PM, Darr wrote:
On Thursday, 15 July, 2010 @23:21 zulu, Robert Myers scribed:
> You left out the Department of Energy, which is a much bigger
> player than the DoD.
>
Well, it sure would be nice if the DoE spent some of our
tax dollars making applications like the Clean Energy phase
2 task, being run by IBM's World Community Grid project
(http://worldcommunitygrid.org/research/cep2/overview.do )
and Harvard, that would use the GPU[s] from nVidia and ATI.
WCG uses Berkeley's BOINC framework that I mentioned
in my reply to the OP (whose author has not posted again, btw).
However, the applications that run in BOINC must be written
especially to make use of the GPU[s], and not all do (in fact,
none of the applications/tasks currently running at WCG can
use the GPU, and most that do under BOINC are windows-only).
I have recently switched from Windows to Linux and I have run Boinc
on both platforms with Seti@home.
With the same machine the cpu Windows was estimated at 7800 million
ops/second integer and 2500 million ops/second floating point while the
gpu was rated at 45 gflops
When I switched to Linux the first thing I noticed was the interger ops/
second was 17546 and floating point came up a bit to 2800 million ops/
second.
Quite a speed difference and it shows with amount of work done per day.
The gpu came up as well to 54 gflops while it was running at the same
speed as windows
So doing things on Linux blows Windows away for speed on cpu and gpu.
I recently downloaded the svn 3437 version of Handbrake and noticing a
huge increase of speed.
I then looked at the gpu temps to see they were going up by 10 degrees C
while I was rendering a film with Handbrake.
I have looked for documentation with the idea that Handbrake was using
the gpu with no info found at all.
Very strange that the temps go up while I run Handbrake.
It is like it is using gpu as when I shut it down the temps return to
normal.
When I start a gpu task with Seti@home the temps go up just like that
but usually by 15 or 20 degrees
There is nothing in the prefs for Handbrake svn saying it will use gpu.
Very strange
3:12 p.m.
On Thursday, 15 July, 2010 @23:21 zulu, Robert Myers scribed:
You left out the Department of Energy, which is a much bigger
player than the DoD.
Well, it sure would be nice if the DoE spent some of our
tax dollars making applications like the Clean Energy phase
2 task, being run by IBM's World Community Grid project
(http://worldcommunitygrid.org/research/cep2/overview.do )
and Harvard, that would use the GPU[s] from nVidia and ATI.
WCG uses Berkeley's BOINC framework that I mentioned
in my reply to the OP (whose author has not posted again, btw).
However, the applications that run in BOINC must be written
especially to make use of the GPU[s], and not all do (in fact,
none of the applications/tasks currently running at WCG can
use the GPU, and most that do under BOINC are windows-only).
1:40 p.m.
On Sat, Jul 17, 2010 at 1:08 PM, Les <hlhowell(a)pacbell.net> wrote:
> I am a test applications consultant. My trade forces me to
> continuously update my skills and try to keep up with the multitude of
> new architectures. I have almost no free time, as researching new
> architectures, designing new algorithms, understanding the application
> of algorithms to new tests, and hardware design requirements eats up
> many hours every day. Fortunately I am and always have been a NERD and
> proud of it. I work at it.
> Since you have a deep knowledge of your requirements,
perhaps you should
> put some time into thinking of a design methodology other than those I
> have mentioned or those that you know, in an attempt to improve the
> science. I am sure many others would be very appreciative, and quite
> likely supportive.
> I'm suspicious of the claimed narrowness of your
credentials, because you
have gotten so many things right. ;-)
Someone who *really* knows what he's talking about in this problem area
might be inclined to say, "This guy Myers is an idiot, because what he
apparently wants to do was shown not to be possible decades ago."
Nature, not hardware budgets, dictates the range of scales and the volume of
data that needs to be dealt with, and you are correct (if perhaps on the low
side) as to the scale of resources that would be required for a head-on
assault against some really important problems (hurricane prediction, for
example, or meaningful climate prediction). There is no conceivable way
that such a head-on assault could ever be mounted with any hardware that I
know of that anyone has ever imagined.
What *can* be done that no one seems interested in doing is to explore how
the effects I have described (computational artifacts resulting from
accommodating the problem to the available hardware, as you apparently
understand) exhibit themselves at attainable ratios of scales. Every lab
director knows that, important though such knowledge might be, the mere fact
that the potential importance of said knowledge is so hard to describe to a
layman means that significant funding will never be forthcoming. Even
worse, you might do an expensive and insightful exploration only to fail to
discover anything that can be applied to "real world" modeling (a null
result).
When you sink a lot of money into a huge new particle accelerator, there is
always the possibility that you will discover nothing new that is
interesting. What's different is that huge particle accelerators capture
the public imagination in a way that the grubby details of computational
physics, no matter how fundamental, never will. A bigger particle
accelerator, if nothing else, allows you to estimate new bounds for as yet
undetected phenomena. The bigger computers we keep building only push the
problem I have described more deeply into the mud.
I have talked to computer architects as to what is conceivably possible.
What I need to do right now is computation that will allow me to show
people what I'm talking about, rather than asking them to imagine it, even
though it is all very clear to me.
A closely-related question--how important are collective, nonlocal, and
nonlinear phenomena in neurobiology, and how much global bandwidth do they
imply?-- may eventually push the computational frontier that I see as being
ignored.
Robert.
But unfortunately, Robert, networks are inherently low bandwidth. To
achieve full throughput you still need parallelism in the networks
themselves. I think from your description, you are discussing the fluid
models which are generally deconstructed to finite series over limited
areas for computation with established boundary conditions. This
partitioning permits the distributed processing approach, but suffers at
the boundaries where either the boundary crossing phenomena are
discounted, or simulated, or I guess passed via some coding algorithm to
permit recursive reduction for some number of iterations.
What your field, and most others related to fluid dynamics, such as
plasma studies, explosion studies and so on, needs is full wide band
memory access across thousands of processors (millions perhaps?).
<big snip of insightful comments
12:08 p.m.
On Fri, 2010-07-16 at 23:04 -0400, Robert Myers wrote:
On Fri, Jul 16, 2010 at 10:35 PM, JD <jd1008(a)gmail.com> wrote:
So, what would you say is/are the class/classes of problems
that would
benefit greatly from a high flops gpu, but without the sort of
bus
bandwidth you would like to see?
Almost any problem that is embarrassingly parallel or nearly so is
potentially a candidate for low-bandwidth computing. Ray tracing is
the primo example. Almost any linear problem is potentially
embarrassingly parallel, and, if you don't want to go through the work
of exposing the embarrassingly parallel nature of the problem, there
are the tricks that make the linpack benchmark so popular for selling
"supercomputers" that have absurdly small bisection bandwidths.
My question, though, is, if that's the kind of problem you have, why
not do it on a distributed platform and teach students how to use
distributed resources? If you're Pixar, I understand why you'd want a
well-organized farm of GPU's, but if you just want to replicate what
LLNL (Lawrence Livermore) was doing, say, ten years ago, are you doing
your students any favor by giving them a GPGPU instead of the
challenge of doing real distributed computing? Conceivably, watts per
flop (power consumption) makes GPGPU's the hands down winner over
distributed computing for problems that are embarrassingly parallel or
nearly so. Inevitably, though, people will want clusters of GPUGPU's,
so you'll wind up doing distributed computing, anyway.
If you rewrite your applications for the one-off architectures typical
of GPU's, so that you have to do it all over again when the next
generation comes out, have you really done yourself any favors?
I don't claim that there are simple or obvious answers, but it's just
too easy for people to be blown away by huge flops numbers. What I'm
afraid of has already started to happen as far as I'm concerned, which
is that all problems will be jammed into the low-bandwidth mold,
whether it's appropriate or not.
Robert.
But unfortunately, Robert, networks are inherently low bandwidth. To
achieve full throughput you still need parallelism in the networks
themselves. I think from your description, you are discussing the fluid
models which are generally deconstructed to finite series over limited
areas for computation with established boundary conditions. This
partitioning permits the distributed processing approach, but suffers at
the boundaries where either the boundary crossing phenomena are
discounted, or simulated, or I guess passed via some coding algorithm to
permit recursive reduction for some number of iterations.
What your field, and most others related to fluid dynamics, such as
plasma studies, explosion studies and so on, needs is full wide band
memory access across thousands of processors (millions perhaps?).
I don't pretend to understand all the implications of various
computational requirements of your field, or that of neuroprocessors,
which is another area where massive parallelism requires deep memory
access, as my own problem area is rather limited to data spaces of only
a few gigabytes, and generally serial processing is capable of dealing
with it, although not real-time.
There are a number of neat processing ideas that have applications to
specific parallel type problems, such as CAPP, SIMD, MIMD arrays, and
neural networks. Whether these solutions will match your problem,
likely depends a great deal on your view of the problem. As in most
endeavors in life, our vision of the solution is as you speak of the
others here, limited by our view of the problem.
Very few people outside the realm of computation analysis ever deal with
the choices of algorithms, architecture, real through put, processing
limitations, bandwidth limitations, data access and distribution
problems, and so on. Fewer still deal with massive quantities of data.
Search engines deal with some of the issues, people like google deal
with all kinds of distributed problems across data spaces that dwarf the
efforts of even most sciences. Some algorithms, as you point out, have
limitations of the Multiple Instruction, Multiple Data sort, which place
great demands on memory bandwidth, and processor speeds, as well as
interprocess communications.
But saying that a particular architecture is unfit for an application
means that you have to understand both the application, and the
architecture. These are both difficult today, as the architectures are
changing about every 11 months or maybe less right now. Computation via
interferometry for example is one of the old (new) fields where a known
capability is only now capable of being explored. Optical computing,
3d shading, broadcast 3d, and other immersion technologies add new
requirements to the GPGU's being discussed. Motion coupled with 3d
means that the shaders and other elements need greater processing power,
and greater through put. Their architecture is undergoing severe
redesign. Even microcontrollers are expanding their reach via multiple
processors (via things like the propeller chip for example).
I am a test applications consultant. My trade forces me to
continuously update my skills and try to keep up with the multitude of
new architectures. I have almost no free time, as researching new
architectures, designing new algorithms, understanding the application
of algorithms to new tests, and hardware design requirements eats up
many hours every day. Fortunately I am and always have been a NERD and
proud of it. I work at it.
Since you have a deep knowledge of your requirements, perhaps you should
put some time into thinking of a design methodology other than those I
have mentioned or those that you know, in an attempt to improve the
science. I am sure many others would be very appreciative, and quite
likely supportive.
Regards,
Les H
9:35 p.m.
On 07/16/2010 04:49 PM, Robert Myers wrote:
On Fri, Jul 16, 2010 at 6:36 PM, Christofer C. Bell
<christofer.c.bell(a)gmail.com <mailto:christofer.c.bell@gmail.com>> wrote:
On Thu, Jul 15, 2010 at 10:56 PM, Robert Myers
<rbmyersusa(a)gmail.com <mailto:rbmyersusa@gmail.com>> wrote:
This is a technical forum, not a debating society. Science is
awash already in useless flops.
You're showing your ignorance, Robert. FLOPS is a very useful
measure and more is always good, but I don't think you know what
it means. It means FLoating Point Operations Per Second. It's
nothing more than a measure of computational speed and says
nothing about the accuracy of the models being computed.
In one of these long-running public debates, I pointed out to
a national decision-maker how relatively meaningless and
frequently wrong NOAA's hurricane season predictions have
been. Guess what? The most recent forecast was wrapped in
all kinds of weasel words. That won't stop them from drawing
their paychecks and burning megawatts producing useless pictures.
If the forecast is wrong, the either the model was inaccurate or
the input data was wrong. It says absolutely nothing about the
value of computing the answer fast (what FLOPS provides). While I
totally get you're going to somehow try to refute the idea that
"having a fast computer is good" and thus, I can only imagine,
make the case that "a slow computer is even better," you're not
going to convince anyone.
Whether you like it or not, and whether, even more important, you
understand it or not, the architecture of a computer has a big impact
on the kinds of models you can implement with any degree of efficiency
on the computer. Hanging lots of flops on inadequate bandwidth is
popular because you can get a high ranking on the Top 500 list with a
minimal expenditure, but it also means that you can't do an important
calculation like a global FFT at anything like reasonable efficiency.
Flops are almost free. Bandwidth is expensive. Unfortunately, what
is almost free (flops) can be nearly useless for, say, an FFT unless
you have the bandwidth to move data around globally fast enough.
Skimping on global bandwidth so that you can't do global operations
effectively forces you to approximations that require only local
computation, that's the kind of modeling we get, and the fact that
there is an inherent disconnect between the way the equations behave
and the way the discretized model behaves gets swept under the rug.
Nonlinear systems interact globally at all scales at every time step.
If your discretization scheme forces an inaccurate representation of
that global interaction, then you shouldn't ever trust what's coming
out of your simulation of nonlinear systems.
Attempting to simulate hurricanes is about as nonlinear as it gets.
When your weatherman on TV knowingly talks about tropical waves as a
cause of concern, he's talking about a large scale flow pattern that
might or might not go through some tortuous nonlinear processes that
will turn it into a hurricane. Modelling the interaction of hugely
different physical scales accurately is essential to accurate
prediction, and modern "supercomputers" are notably and chronically
short of the bandwidth required to do so.
Anyway, technical forum or not, it's a forum made up of people and
that makes it a community. To get along in a community, it helps
to not be an asshole. While you may not care about being an
asshole, do note that "getting along in a community" does
influence if anyone takes you seriously. And you seem very much
to want to be taken seriously.
Calling other people names helps to build a community? From your
pompous and condescending tone unbacked by actual knowledge, I'd be
inclined to label you in the same way you have chosen to label me,
with the addition of the word "ignorant" in front of it, but I don't
think name-calling and labeling ever helps.
Robert.
So, what would you say is/are the class/classes of problems that would
benefit greatly from a high flops gpu, but without the sort of bus
bandwidth you would like to see?
10:41 p.m.
On Fri, Jul 16, 2010 at 11:25 PM, JD <jd1008(a)gmail.com> wrote:
Dude, I am not a teacher.
I am a hacker of sorts.
My apologies for being misled by your post:
"This is the kind of technology that is needed to solve huge mathematical
problems.
Most smaller universities and colleges do not have massively parallel
supercomputers that are
vector processors. This could make it easy for such colleges and small
university research
projects to have some decent computational power."
If you'd said, "I'm a hacker of sorts, and I'm really excited at the
prospect of playing with one of these," the conversation never would have
taken place.
But you opine that problems that others are excited to solve with the
SLI gang of gpu's are "embarrassingly parallel", guess
you will just
have to sweat it and wait for your dream machine to be built, perhaps in
your next life time. Meanwhile, all you will be able to do is complain
about other people's excitement with the technology at hand.
I'm not waiting for anything. I get heard.
Robert.
10:25 p.m.
On 07/16/2010 08:04 PM, Robert Myers wrote:
On Fri, Jul 16, 2010 at 10:35 PM, JD <jd1008(a)gmail.com
<mailto:jd1008@gmail.com>> wrote:
So, what would you say is/are the class/classes of problems that would
benefit greatly from a high flops gpu, but without the sort of bus
bandwidth you would like to see?
Almost any problem that is embarrassingly parallel or nearly so is
potentially a candidate for low-bandwidth computing. Ray tracing is
the primo example. Almost any linear problem is potentially
embarrassingly parallel, and, if you don't want to go through the work
of exposing the embarrassingly parallel nature of the problem, there
are the tricks that make the linpack benchmark so popular for selling
"supercomputers" that have absurdly small bisection bandwidths.
My question, though, is, if that's the kind of problem you have, why
not do it on a distributed platform and teach students how to use
distributed resources? If you're Pixar, I understand why you'd want a
well-organized farm of GPU's, but if you just want to replicate what
LLNL (Lawrence Livermore) was doing, say, ten years ago, are you doing
your students any favor by giving them a GPGPU instead of the
challenge of doing real distributed computing? Conceivably, watts per
flop (power consumption) makes GPGPU's the hands down winner over
distributed computing for problems that are embarrassingly parallel or
nearly so. Inevitably, though, people will want clusters of GPUGPU's,
so you'll wind up doing distributed computing, anyway.
If you rewrite your applications for the one-off architectures typical
of GPU's, so that you have to do it all over again when the next
generation comes out, have you really done yourself any favors?
I don't claim that there are simple or obvious answers, but it's just
too easy for people to be blown away by huge flops numbers. What I'm
afraid of has already started to happen as far as I'm concerned, which
is that all problems will be jammed into the low-bandwidth mold,
whether it's appropriate or not.
Robert.
Dude, I am not a teacher.
I am a hacker of sorts.
But you opine that problems that others are excited to solve with the
SLI gang of gpu's are "embarrassingly parallel", guess you will just
have to sweat it and wait for your dream machine to be built, perhaps in
your next life time. Meanwhile, all you will be able to do is complain
about other people's excitement with the technology at hand.
10:17 p.m.
On 07/16/2010 04:55 PM, Christofer C. Bell wrote:
On Fri, Jul 16, 2010 at 6:49 PM, Robert Myers
<rbmyersusa(a)gmail.com
<mailto:rbmyersusa@gmail.com>> wrote:
Whether you like it or not, and whether, even more important, you
understand it or not, the architecture of a computer has a big
impact on the kinds of models you can implement with any degree of
efficiency on the computer. Hanging lots of flops on inadequate
bandwidth is popular because you can get a high ranking on the Top
500 list with a minimal expenditure, but it also means that you
can't do an important calculation like a global FFT at anything
like reasonable efficiency. Flops are almost free. Bandwidth is
expensive. Unfortunately, what is almost free (flops) can be
nearly useless for, say, an FFT unless you have the bandwidth to
move data around globally fast enough.
You need to make friends with a guy named Edward Lorenz. Bandwidth
has nothing to do with it. Do you even know what this term means?
I don't think name-calling and labeling ever helps.
Then stop doing it.
--
Chris
Hi Chris,
"In August 2007, PCI-SIG announced that PCI Express 3.0 will carry a bit
rate of 8 gigatransfers <http://en.wikipedia.org/wiki/Gigatransfer> per
second."
(128 bits per transfer) !!
That is about 137,438,953,472 bytes per second.
Viva SLI and multi-treaflop/s gpu's !!
Alright! All you DSP fans, and telemetry data fans, get to work :) :)
And you wifi cracker fans, you now have even a better tool than
what the japanese team had:
http://jwis2009.nsysu.edu.tw/location/paper/A%20Practical%20Message%20Fal...
If they could crack TKIP in under a minute using a laptop, perhaps
now they can tackle and crack AES, which they were not able to do back
then (2009).
Technology is indeed a two-edged sword :)
It temporarily gives us a false sense of security, only to be
robbed of that sense by self same technology.
Cheers,
JD
9:19 p.m.
On Fri, Jul 16, 2010 at 9:49 PM, Genes MailLists <lists(a)sapience.com> wrote:
On 07/16/2010 08:07 PM, Robert Myers wrote:
We ett that this stuff may not help your problem domain - don't
assume all problems look like the one(s) you are interested in.
This stuff is useful - I have seen it as have many others ... it is
not a panacea ... stop harping please ... and try understand the useful
side as well as the limitations .. it has limitations - as do people.
If you wanted this discussion to end, why are you continuing it?
Gordon Bell asked (about huge computers) in a presentation now 12 years old:
"Is it worth it?"
If you're not going to get new science out of a huge new computer, then why
spend the money?
I have one answer to where there is possibly new science, but we never get
the computer to explore it.
"My" problem domain (fluid mechanics) is a big driver behind the huge
expenditures on "supercomputers," which as I have pointed out ad nauseum,
are far from super in some really important ways.
The GPU may be a very handy tool for certain kinds of computations, but it
almost inherently replicates a design corner-cutting that that is endemic in
supercomputing right now (low bytes per flop).
If you want to say, "GPGPU's will help *my* problem, so I want one," I have
no answer for that.
If you propose that the GPU is an ideal tool for university level teaching
and research that requires hefty computing, as the poster I responded to
did, then I have some serious objections based on good science.
I presented my position, I defended my reputation and my position against
wild and ignorant slurs, and you have now joined a chorus that wants to
comment on my personality, rather than on anything technical. Perhaps you
are the one who should stop harping?
Robert.
8:49 p.m.
On 07/16/2010 08:07 PM, Robert Myers wrote:
We ett that this stuff may not help your problem domain - don't
assume all problems look like the one(s) you are interested in.
This stuff is useful - I have seen it as have many others ... it is
not a panacea ... stop harping please ... and try understand the useful
side as well as the limitations .. it has limitations - as do people.
gene/
6:55 p.m.
On Fri, Jul 16, 2010 at 6:49 PM, Robert Myers <rbmyersusa(a)gmail.com> wrote:
Whether you like it or not, and whether, even more important, you
understand it or not, the architecture of a computer has a big impact on the
kinds of models you can implement with any degree of efficiency on the
computer. Hanging lots of flops on inadequate bandwidth is popular because
you can get a high ranking on the Top 500 list with a minimal expenditure,
but it also means that you can't do an important calculation like a global
FFT at anything like reasonable efficiency. Flops are almost free.
Bandwidth is expensive. Unfortunately, what is almost free (flops) can be
nearly useless for, say, an FFT unless you have the bandwidth to move data
around globally fast enough.
You need to make friends with a guy named Edward Lorenz. Bandwidth has
nothing to do with it. Do you even know what this term means?
I don't think name-calling and labeling ever helps.
Then stop doing it.
--
Chris
6:49 p.m.
On Fri, Jul 16, 2010 at 6:36 PM, Christofer C. Bell <
christofer.c.bell(a)gmail.com> wrote:
On Thu, Jul 15, 2010 at 10:56 PM, Robert Myers
<rbmyersusa(a)gmail.com>wrote:
>
> This is a technical forum, not a debating society. Science is awash
> already in useless flops.
>
You're showing your ignorance, Robert. FLOPS is a very useful measure and
more is always good, but I don't think you know what it means. It means
FLoating Point Operations Per Second. It's nothing more than a measure of
computational speed and says nothing about the accuracy of the models being
computed.
> In one of these long-running public debates, I pointed out to a national
> decision-maker how relatively meaningless and frequently wrong NOAA's
> hurricane season predictions have been. Guess what? The most recent
> forecast was wrapped in all kinds of weasel words. That won't stop them
> from drawing their paychecks and burning megawatts producing useless
> pictures.
>
If the forecast is wrong, the either the model was inaccurate or the input
data was wrong. It says absolutely nothing about the value of computing the
answer fast (what FLOPS provides). While I totally get you're going to
somehow try to refute the idea that "having a fast computer is good" and
thus, I can only imagine, make the case that "a slow computer is even
better," you're not going to convince anyone.
Whether you like it or not, and whether, even more important, you understand
it or not, the architecture of a computer has a big impact on the kinds of
models you can implement with any degree of efficiency on the computer.
Hanging lots of flops on inadequate bandwidth is popular because you can
get a high ranking on the Top 500 list with a minimal expenditure, but it
also means that you can't do an important calculation like a global FFT at
anything like reasonable efficiency. Flops are almost free. Bandwidth is
expensive. Unfortunately, what is almost free (flops) can be nearly useless
for, say, an FFT unless you have the bandwidth to move data around globally
fast enough.
Skimping on global bandwidth so that you can't do global operations
effectively forces you to approximations that require only local
computation, that's the kind of modeling we get, and the fact that there is
an inherent disconnect between the way the equations behave and the way the
discretized model behaves gets swept under the rug. Nonlinear systems
interact globally at all scales at every time step. If your discretization
scheme forces an inaccurate representation of that global interaction, then
you shouldn't ever trust what's coming out of your simulation of nonlinear
systems.
Attempting to simulate hurricanes is about as nonlinear as it gets. When
your weatherman on TV knowingly talks about tropical waves as a cause of
concern, he's talking about a large scale flow pattern that might or might
not go through some tortuous nonlinear processes that will turn it into a
hurricane. Modelling the interaction of hugely different physical scales
accurately is essential to accurate prediction, and modern "supercomputers"
are notably and chronically short of the bandwidth required to do so.
Anyway, technical forum or not, it's a forum made up of people
and that
makes it a community. To get along in a community, it helps to not be an
asshole. While you may not care about being an asshole, do note that
"getting along in a community" does influence if anyone takes you
seriously. And you seem very much to want to be taken seriously.
Calling other people names helps to build a community? From your pompous
and condescending tone unbacked by actual knowledge, I'd be inclined to
label you in the same way you have chosen to label me, with the addition of
the word "ignorant" in front of it, but I don't think name-calling and
labeling ever helps.
Robert.
5:36 p.m.
On Thu, Jul 15, 2010 at 10:56 PM, Robert Myers <rbmyersusa(a)gmail.com> wrote:
This is a technical forum, not a debating society. Science is awash
already in useless flops.
You're showing your ignorance, Robert. FLOPS is a very useful measure and
more is always good, but I don't think you know what it means. It means
FLoating Point Operations Per Second. It's nothing more than a measure of
computational speed and says nothing about the accuracy of the models being
computed.
In one of these long-running public debates, I pointed out to a
national
decision-maker how relatively meaningless and frequently wrong NOAA's
hurricane season predictions have been. Guess what? The most recent
forecast was wrapped in all kinds of weasel words. That won't stop them
from drawing their paychecks and burning megawatts producing useless
pictures.
If the forecast is wrong, the either the model was inaccurate or the input
data was wrong. It says absolutely nothing about the value of computing the
answer fast (what FLOPS provides). While I totally get you're going to
somehow try to refute the idea that "having a fast computer is good" and
thus, I can only imagine, make the case that "a slow computer is even
better," you're not going to convince anyone.
Anyway, technical forum or not, it's a forum made up of people and that
makes it a community. To get along in a community, it helps to not be an
asshole. While you may not care about being an asshole, do note that
"getting along in a community" does influence if anyone takes you
seriously. And you seem very much to want to be taken seriously.
Just a friendly FYI.
--
Chris
11:42 p.m.
On Fri, Jul 16, 2010 at 12:13 AM, Genes MailLists <lists(a)sapience.com>wrote:
I've seen 1-2 orders of magnitude speedups in real world usage (using
nvidia GPU's in otherwise high end but standard equipment) - was really
impressive - don't get caught up in technical minutia like whether a
flop is useful metric - using the GPU can be an enormous speed gain.
Test it for your use case.
There are limitations - and moving things in and out can be costly -
however careful programming can most certainly lead to huge benefits -
that means cost savings for time critical usage ...
There are problems for which GPU's will be of tremendous benefit, just as
there
are problems for which the single precision arithmetic you are
apparently using will be acceptable. There are problems for which small
bandwidth per flop is acceptable, but not for all, just as there are
problems for which single-precision arithmetic is good enough, but not for
all. Most high-end technical computing (the really big problems) requires
double precision arithmetic, for which the performance of the GPU's is
significantly less impressive.
The claim to which I objected was sweeping. The emphasis on flops has
skewed computational physics in a way to which I take very strong exception.
I think I have made that clear enough.
The problems that were nearly impossible before Fermi will not be made any
easier by the introduction of Fermi.
When the DoE advertises its latest mistake, what it will advertise is flops
and use that to claim that they have the world's fastest or most powerful
computer when, for some really important problems, most of that power is
useless. GPU computation will only intensify an already unfortunate trend.
To think of GPU's as any kind of answer to the most pressing needs of
computational physics is just wrong.
In the late nineties, after some poorly thought-out purchases for the DoE,
the Congress was horrified to discover that actual flops in practice were
sometimes only 5% of peak flops on floating point intensive code. After
much hand wringing, lots of press releases, and the inevitable march of
Moore's Law, many codes are still running in the 5-10% efficiency range.
GPU's are only going to make this trend worse.
Robert.
11:13 p.m.
I've seen 1-2 orders of magnitude speedups in real world usage (using
nvidia GPU's in otherwise high end but standard equipment) - was really
impressive - don't get caught up in technical minutia like whether a
flop is useful metric - using the GPU can be an enormous speed gain.
Test it for your use case.
There are limitations - and moving things in and out can be costly -
however careful programming can most certainly lead to huge benefits -
that means cost savings for time critical usage ...
g
10:56 p.m.
On Thu, Jul 15, 2010 at 11:22 PM, JD <jd1008(a)gmail.com> wrote:
>
Listen Robert, you can disagree on the usefulness
and utilization for solving large problems.
But that hardly grants you the license to disparage
another member of this list.
If you do not think your comment:
> If you think flops is a good measure of the science you can do, you
> should probably be in a different business.
is at least disparaging, if not outright nasty.
Please refrain from making them.
No. Sorry. You listen.
You repeated a mindless refrain as if you knew what you were talking about,
when, in my never sufficiently humble opinion, you don't know what you're
talking about. If that's disparaging you, so be it.
Money that could be going to actual science is being wasted because of the
kind of clueless cheerleading that bureaucrats love and that you have put
the weight of your opinion behind.
This is a technical forum, not a debating society. Science is awash already
in useless flops.
In one of these long-running public debates, I pointed out to a national
decision-maker how relatively meaningless and frequently wrong NOAA's
hurricane season predictions have been. Guess what? The most recent
forecast was wrapped in all kinds of weasel words. That won't stop them
from drawing their paychecks and burning megawatts producing useless
pictures.
The Wall Street Journal recently published a totally meaningless computation
from the Department of Energy about the oil slick in the Gulf of Mexico
moving up the East Coast. What did they advertise as the scientific basis
for the calculation? The money that had been dumped into the code over the
years ($100 million) and how many hours of "supercomputer" time it took.
The calculation was junk, but because huge resources had been spent on it
and it made a nice color plot, the Wall Street Journal published it.
It's not just about opinions and your sense of good manners. The
flops-are-good mantra is ruining computational physics, and everyone goes
along with it, even though the emperor has no clothes. You might not have
liked what I said, but it accurately reflected my feelings on the subject.
If you can't respect that, then why should I respect you?
Robert.
10:22 p.m.
On 07/15/2010 05:58 PM, Robert Myers wrote:
On Thu, Jul 15, 2010 at 8:12 PM, JD <jd1008(a)gmail.com
<mailto:jd1008@gmail.com>> wrote:
.
>
"There he goes again"
I did not choose any position. I merely stated a fact and you
concocted
from that, that I am taking a position on the issue.
I am an old timer by the average age of this list's subscribers. I was
around when the pdp 8 and pdp 11 were used to teach
assembly language programming.
Quoting you:
"This is the kind of technology that is needed to solve huge mathematical
problems."
Highly questionable. Mostly wrong. Ok?
Bandwidth. Bandwidth. Bandwidth.
And it's a big problem for GPU's which are really, really good at
pounding the living daylights out of small datasets, but of marginal
usefulness for "huge mathematical problems," except for a small subset
of such problems, like linpack. I've argued this over and over again
publicly. People who actually control budgets already know what I
have to say. The most interesting problems are bandwidth-bound, not
compute-bound.
If I could have a Fermi, would I? You bet, because I want to play
with one. Do I expect it to open up new ground that in any way
reflects naive measures of its computational power? No, I don't.
Robert.
Listen Robert, you can disagree on the usefulness
and utilization for solving large problems.
But that hardly grants you the license to disparage
another member of this list.
If you do not think your comment:
If you think flops is a good measure of the science you can do, you
should probably be in a different business.
is at least disparaging, if not
outright nasty.
Please refrain from making them.
7:58 p.m.
On Thu, Jul 15, 2010 at 8:12 PM, JD <jd1008(a)gmail.com> wrote:
.
>
"There he goes again"
I did not choose any position. I merely stated a fact and you concocted
from that, that I am taking a position on the issue.
I am an old timer by the average age of this list's subscribers. I was
around when the pdp 8 and pdp 11 were used to teach
assembly language programming.
Quoting you:
"This is the kind of technology that is needed to solve huge mathematical
problems."
Highly questionable. Mostly wrong. Ok?
Bandwidth. Bandwidth. Bandwidth.
And it's a big problem for GPU's which are really, really good at pounding
the living daylights out of small datasets, but of marginal usefulness for
"huge mathematical problems," except for a small subset of such problems,
like linpack. I've argued this over and over again publicly. People who
actually control budgets already know what I have to say. The most
interesting problems are bandwidth-bound, not compute-bound.
If I could have a Fermi, would I? You bet, because I want to play with one.
Do I expect it to open up new ground that in any way reflects naive
measures of its computational power? No, I don't.
Robert.
7:12 p.m.
On 07/15/2010 04:39 PM, Robert Myers wrote:
On Thu, Jul 15, 2010 at 7:29 PM, JD <jd1008(a)gmail.com
<mailto:jd1008@gmail.com>> wrote:
On 07/15/2010 04:21 PM, Robert Myers wrote:
> On Thu, Jul 15, 2010 at 6:44 PM, JD <jd1008(a)gmail.com
<mailto:jd1008@gmail.com>
> <mailto:jd1008@gmail.com <mailto:jd1008@gmail.com>>> wrote:
>
> For many years, this has been
> a tug of war between
> industry on one side, and the department of defense and the
NSA on the
> other.
>
>
> You left out the Department of Energy, which is a much bigger player
> than the DoD.
>
> Meaningful computational power has been available on desktops for
> quite a while, and, if one desktop wasn't enough, you could always
> Beowulf it, which isn't much different from what the DoE has
been doing.
>
> If you think flops is a good measure of the science you can do, you
> should probably be in a different business.
>
> Robert.
>
On this list, I do not think you should be in the business of
1- putting your words in other people's mouths
2- telling people what business they should or should not be in.
Thanks for the advice.
I've been involved in this debate in a very public way for a long time
now.
YOU chose to use this list to advocate a position that the DoE has
been using for years to convince people that ever bigger computers are
a good way to spend money. If you didn't say it, you certainly
strongly implied it (more flops is better).
I answered you because you stepped on MY toes.
How long have you been around? The Cray-1 was practically synonymous
with "supercomputer," and that kind of power has been available to
desktop users for a long time now.
Robert.
"There he goes again"
I did not choose any position. I merely stated a fact and you concocted
from that, that I am taking a position on the issue.
I am an old timer by the average age of this list's subscribers. I was
around when the pdp 8 and pdp 11 were used to teach
assembly language programming.
6:21 p.m.
On Thu, Jul 15, 2010 at 6:44 PM, JD <jd1008(a)gmail.com> wrote:
For many years, this has been
a tug of war between
industry on one side, and the department of defense and the NSA on the
other.
You left out the Department of Energy, which is a much bigger player than
the DoD.
Meaningful computational power has been available on desktops for quite a
while, and, if one desktop wasn't enough, you could always Beowulf it, which
isn't much different from what the DoE has been doing.
If you think flops is a good measure of the science you can do, you should
probably be in a different business.
Robert.
6:39 p.m.
On Thu, Jul 15, 2010 at 7:29 PM, JD <jd1008(a)gmail.com> wrote:
On 07/15/2010 04:21 PM, Robert Myers wrote:
> On Thu, Jul 15, 2010 at 6:44 PM, JD <jd1008(a)gmail.com
> <mailto:jd1008@gmail.com>> wrote:
>
> For many years, this has been
> a tug of war between
> industry on one side, and the department of defense and the NSA on
the
> other.
>
>
> You left out the Department of Energy, which is a much bigger player
> than the DoD.
>
> Meaningful computational power has been available on desktops for
> quite a while, and, if one desktop wasn't enough, you could always
> Beowulf it, which isn't much different from what the DoE has been doing.
>
> If you think flops is a good measure of the science you can do, you
> should probably be in a different business.
>
> Robert.
>
On this list, I do not think you should be in the business of
1- putting your words in other people's mouths
2- telling people what business they should or should not be in.
Thanks for the advice.
I've been involved in this debate in a very public way for a long time now.
YOU chose to use this list to advocate a position that the DoE has been
using for years to convince people that ever bigger computers are a good way
to spend money. If you didn't say it, you certainly strongly implied it
(more flops is better).
I answered you because you stepped on MY toes.
How long have you been around? The Cray-1 was practically synonymous with
"supercomputer," and that kind of power has been available to desktop users
for a long time now.
Robert.
6:29 p.m.
On 07/15/2010 04:21 PM, Robert Myers wrote:
On Thu, Jul 15, 2010 at 6:44 PM, JD <jd1008(a)gmail.com
<mailto:jd1008@gmail.com>> wrote:
For many years, this has been
a tug of war between
industry on one side, and the department of defense and the NSA on the
other.
You left out the Department of Energy, which is a much bigger player
than the DoD.
Meaningful computational power has been available on desktops for
quite a while, and, if one desktop wasn't enough, you could always
Beowulf it, which isn't much different from what the DoE has been doing.
If you think flops is a good measure of the science you can do, you
should probably be in a different business.
Robert.
On this list, I do not think you should be in the business of
1- putting your words in other people's mouths
2- telling people what business they should or should not be in.
2:19 p.m.
On 07/15/2010 12:07 PM, Zoltan Boszormenyi wrote:
JD írta:
> On 07/15/2010 11:23 AM, Michael Miles wrote:
>
>> On 07/15/2010 12:18 AM, JD wrote:
>>
>>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>>
>>>
>>>> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net>
wrote:
>>>>
>>>>
>>>>
>>>>> Agreed that an OS kernel hasn't much use for a GPU. But it should
be
>>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a
couple
>>>>> of usb ports to the card and move X completely to the video card.
Just
>>>>> like a remote X server only in the same box.
>>>>>
>>>>> I really think the OP was referring to having user mode code take
>>>>> advantage of the high processing power of modern GPUs. It works now,
but
>>>>> could be improved if the OS contained specialized scheduling support
for
>>>>> these kinds of jobs.
>>>>>
>>>>>
>>>> I understand that the GPU has no page faults, and is missing many of
>>>> what we regard as the essential functions of a normal processor? Also
>>>> getting large amounts of data in or out of the GPU is slow - it is
>>>> fast partly because there is a lot less overhead compared to a single
>>>> processor and partly from the advantage of multiple cores. I was
>>>> speaking to someone who has been working with GPU processing for
>>>> several years and was skeptical about getting code to run reliably
>>>> across different GPUs... and of course CUDA is vendor specific as fa
>>>> as I know? So speed gain is dependent on the kind of processing needed
>>>> but if anything goes wrong then it can easily crash the system.
>>>>
>>>> Anyone had any experience with using the GPU could perhaps comment?
>>>>
>>>>
>>> Sorry to barge in this late into this thread....
>>> Was the originator of the thread interested in the kernel
>>> to use the gpu for floating point operations or integer
>>> operations?
>>> If floating point, the x86 (among others) already has an
>>> integrated fpu, and the integer logic is already in the cpu (or alu).
>>> So I do not understand what sort of computations the originator
>>> of the thread would like to see done on the gpu.
>>>
>>> jd
>>>
>>>
>> The other OS's Mac and Windows are using the GPU in its video
>> conversion programs.
>> The newer programs will have selections to activate the GPU for computation.
>>
>> I have been using the GPU for scientific computation for quite a while now.
>> Seti@home is very much a hobby and it takes samples from the areciebo
>> telescope and analyse data looking for "You guessed it, ET"
>> It will crunch numbers very fast compared to a normal CPU.
>>
>> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
>> Gflops .
>>
>> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
>> to a full teraflop.
>> That kind of speed would be well accepted if an OS would use it
>> generally or software that is written for Video conversion to use it
>> greatly reducing time.
>>
>>
>> That's what I would like to see, more focus on speeding up video
>> conversion especially with HD video and it seems that the GPU is a very
>> inexpensive way to add a lot of power to your machines
>>
> A teraflop?? WHoa! Can the PCI bus really feed the gpu with
> an instruction stream that will yield that performance?
>
Err, no. GPUs are massively parallel beasts. They can't reach level of
performance via a discrete instruction stream, not to mention even
the PCIe bus couldn't cope with it really. The high performance comes
from the GPU programmes are executed by their hardware threads
in parallel on large amounts of data.
> I mean most pc's out there are in people's homes still pci (33 or 66 MHz
> bus).
> Relatively, fewer are on pci x16 which is a much faster bus.
>
> Thanks for your feedback.
>
>
>
So, given the extreme limitations of the bus relative to the
teraflop speed of the gpu, how can the cpu feed the gpu with
"data" at a rate that can sustain continuous 1 teraflops/sec?
Is there a pci-e32 with a faster bus clock on the horizon?
There are so many programs that use/need floating point operations
on matrices that could benefit vastly from this. I hope someone(s)
can point to such future HW development.
1:38 p.m.
On 07/15/2010 11:23 AM, Michael Miles wrote:
On 07/15/2010 12:18 AM, JD wrote:
> On 07/14/2010 11:41 PM, mike cloaked wrote:
>
>> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net>
wrote:
>>
>>
>>> Agreed that an OS kernel hasn't much use for a GPU. But it should be
>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
>>> of usb ports to the card and move X completely to the video card. Just
>>> like a remote X server only in the same box.
>>>
>>> I really think the OP was referring to having user mode code take
>>> advantage of the high processing power of modern GPUs. It works now, but
>>> could be improved if the OS contained specialized scheduling support for
>>> these kinds of jobs.
>>>
>> I understand that the GPU has no page faults, and is missing many of
>> what we regard as the essential functions of a normal processor? Also
>> getting large amounts of data in or out of the GPU is slow - it is
>> fast partly because there is a lot less overhead compared to a single
>> processor and partly from the advantage of multiple cores. I was
>> speaking to someone who has been working with GPU processing for
>> several years and was skeptical about getting code to run reliably
>> across different GPUs... and of course CUDA is vendor specific as fa
>> as I know? So speed gain is dependent on the kind of processing needed
>> but if anything goes wrong then it can easily crash the system.
>>
>> Anyone had any experience with using the GPU could perhaps comment?
>>
> Sorry to barge in this late into this thread....
> Was the originator of the thread interested in the kernel
> to use the gpu for floating point operations or integer
> operations?
> If floating point, the x86 (among others) already has an
> integrated fpu, and the integer logic is already in the cpu (or alu).
> So I do not understand what sort of computations the originator
> of the thread would like to see done on the gpu.
>
> jd
>
The other OS's Mac and Windows are using the GPU in its video
conversion programs.
The newer programs will have selections to activate the GPU for computation.
I have been using the GPU for scientific computation for quite a while now.
Seti@home is very much a hobby and it takes samples from the areciebo
telescope and analyse data looking for "You guessed it, ET"
It will crunch numbers very fast compared to a normal CPU.
I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
Gflops .
I have a slow video card Nvidia 9400GT. The bigger ones will go right up
to a full teraflop.
That kind of speed would be well accepted if an OS would use it
generally or software that is written for Video conversion to use it
greatly reducing time.
That's what I would like to see, more focus on speeding up video
conversion especially with HD video and it seems that the GPU is a very
inexpensive way to add a lot of power to your machines
A teraflop?? WHoa! Can the
PCI bus really feed the gpu with
an instruction stream that will yield that performance?
I mean most pc's out there are in people's homes still pci (33 or 66 MHz
bus).
Relatively, fewer are on pci x16 which is a much faster bus.
Thanks for your feedback.
2:18 a.m.
On 07/14/2010 11:41 PM, mike cloaked wrote:
On Thu, Jul 15, 2010 at 5:27 AM, john
wendel<jwendel10(a)comcast.net> wrote:
> Agreed that an OS kernel hasn't much use for a GPU. But it should be
> easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
> of usb ports to the card and move X completely to the video card. Just
> like a remote X server only in the same box.
>
> I really think the OP was referring to having user mode code take
> advantage of the high processing power of modern GPUs. It works now, but
> could be improved if the OS contained specialized scheduling support for
> these kinds of jobs.
I understand that the GPU has no page faults, and is missing many of
what we regard as the essential functions of a normal processor? Also
getting large amounts of data in or out of the GPU is slow - it is
fast partly because there is a lot less overhead compared to a single
processor and partly from the advantage of multiple cores. I was
speaking to someone who has been working with GPU processing for
several years and was skeptical about getting code to run reliably
across different GPUs... and of course CUDA is vendor specific as fa
as I know? So speed gain is dependent on the kind of processing needed
but if anything goes wrong then it can easily crash the system.
Anyone had any experience with using the GPU could perhaps comment?
Sorry to barge
in this late into this thread....
Was the originator of the thread interested in the kernel
to use the gpu for floating point operations or integer
operations?
If floating point, the x86 (among others) already has an
integrated fpu, and the integer logic is already in the cpu (or alu).
So I do not understand what sort of computations the originator
of the thread would like to see done on the gpu.
jd
1:41 a.m.
On Thu, Jul 15, 2010 at 5:27 AM, john wendel <jwendel10(a)comcast.net> wrote:
Agreed that an OS kernel hasn't much use for a GPU. But it should
be
easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
of usb ports to the card and move X completely to the video card. Just
like a remote X server only in the same box.
I really think the OP was referring to having user mode code take
advantage of the high processing power of modern GPUs. It works now, but
could be improved if the OS contained specialized scheduling support for
these kinds of jobs.
I understand that the GPU has no page faults, and is missing many of
what we regard as the essential functions of a normal processor? Also
getting large amounts of data in or out of the GPU is slow - it is
fast partly because there is a lot less overhead compared to a single
processor and partly from the advantage of multiple cores. I was
speaking to someone who has been working with GPU processing for
several years and was skeptical about getting code to run reliably
across different GPUs... and of course CUDA is vendor specific as fa
as I know? So speed gain is dependent on the kind of processing needed
but if anything goes wrong then it can easily crash the system.
Anyone had any experience with using the GPU could perhaps comment?
--
mike c
11:27 p.m.
On 07/14/2010 08:43 PM, Bill Davidsen wrote:
Jozsi Avadkan wrote:
> Does someone know a distribution/operating system, that rather uses the
> GPU for "working", not the CPU? [by default]
>
Other than internal use as part of a display driver, what do you think a kernel
would do with a GPU? There essentially no FP in the kernel.
> Or this solution is still in the "beginning part"?
>
> Thanks for any tips, link, suggestions.
>
Agreed that an OS kernel hasn't much use for a GPU. But it should be
easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
of usb ports to the card and move X completely to the video card. Just
like a remote X server only in the same box.
I really think the OP was referring to having user mode code take
advantage of the high processing power of modern GPUs. It works now, but
could be improved if the OS contained specialized scheduling support for
these kinds of jobs.
Regards,
John
10:43 p.m.
Jozsi Avadkan wrote:
Does someone know a distribution/operating system, that rather uses
the
GPU for "working", not the CPU? [by default]
Other than internal use as part of a display driver, what do you think a kernel
would do with a GPU? There essentially no FP in the kernel.
Or this solution is still in the "beginning part"?
Thanks for any tips, link, suggestions.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
10:11 p.m.
On Tuesday, 13 July, 2010 @20:46 zulu, Jozsi Avadkan scribed:
Does someone know a distribution/operating system, that rather
uses the GPU for "working", not the CPU? [by default]
Or this solution is still in the "beginning part"?
Thanks for any tips, link, suggestions.
Have you checked out http://boinc.berkeley.edu ?
(see http://boinc.berkeley.edu/wiki/GPU_computing )
# yum install boinc-client boinc-manager
Will get you the basics. The client is the service; manager the GUI.
#yum info boinc* shows there's also boinc-client-static,
boinc-client-debuginfo, boinc-client-devel and boinc-client-doc.
However, the person that packages the RPMs from the BOINC
SVNs for the updates repos hasn't run his script for a few months, so
we're stuck at version 6.10.45 instead of the latest recommended
(6.10.56) unless you want to package it yourself (probably just as
well, as his script grabs the latest - currently 6.10.58 - to make).
Anyway... to make it use only the GPU, set its preferences to use 0 CPUs.
5:02 p.m.
On 07/13/2010 01:46 PM, Jozsi Avadkan wrote:
Does someone know a distribution/operating system, that rather uses
the
GPU for "working", not the CPU? [by default]
Or this solution is still in the "beginning part"?
Thanks for any tips, link, suggestions.
http://www.fixstars.com/en/company/press/20100302.html
Check out the page here and it's coming along.
There is an enterprise Linux ( Yellow Dog) which uses the GPU CUDA
device for added speed not just in acceleration for Video
Mac is doing the same.
Now that the Fermi's are out we will a brand new trend in parallel computing
Michael
4:50 p.m.
On 07/13/2010 01:46 PM, Jozsi Avadkan wrote:
Does someone know a distribution/operating system, that rather uses
the
GPU for "working", not the CPU? [by default]
Or this solution is still in the "beginning part"?
Thanks for any tips, link, suggestions.
Yes, unfortunately it is windows 7 and soon to be Windows 8 will use GPU
for Floating point calculation.
It is very much needed in Linux.
I tried Windows 7 and the Movie playes/ converters are using GPU for
added speed to the conversions.
I am keeping my eye's out for news about Linux doing the saame as GPU's
are extremely fast and should be built in to OS's for calculation and
not just video display
Michael
5 p.m.
On Sat, Jul 17, 2010 at 1:08 PM, Les <hlhowell(a)pacbell.net> wrote:
But unfortunately, Robert, networks are inherently low bandwidth.
To
achieve full throughput you still need parallelism in the networks
themselves. I think from your description, you are discussing the fluid
models which are generally deconstructed to finite series over limited
areas for computation with established boundary conditions. This
partitioning permits the distributed processing approach, but suffers at
the boundaries where either the boundary crossing phenomena are
discounted, or simulated, or I guess passed via some coding algorithm to
permit recursive reduction for some number of iterations.
What your field, and most others related to fluid dynamics, such as
plasma studies, explosion studies and so on, needs is full wide band
memory access across thousands of processors (millions perhaps?).
I don't pretend to understand all the implications of various
computational requirements of your field, or that of neuroprocessors,
which is another area where massive parallelism requires deep memory
access, as my own problem area is rather limited to data spaces of only
a few gigabytes, and generally serial processing is capable of dealing
with it, although not real-time.
There are a number of neat processing ideas that have applications to
specific parallel type problems, such as CAPP, SIMD, MIMD arrays, and
neural networks. Whether these solutions will match your problem,
likely depends a great deal on your view of the problem. As in most
endeavors in life, our vision of the solution is as you speak of the
others here, limited by our view of the problem.
Very few people outside the realm of computation analysis ever deal with
the choices of algorithms, architecture, real through put, processing
limitations, bandwidth limitations, data access and distribution
problems, and so on. Fewer still deal with massive quantities of data.
Search engines deal with some of the issues, people like google deal
with all kinds of distributed problems across data spaces that dwarf the
efforts of even most sciences. Some algorithms, as you point out, have
limitations of the Multiple Instruction, Multiple Data sort, which place
great demands on memory bandwidth, and processor speeds, as well as
interprocess communications.
But saying that a particular architecture is unfit for an application
means that you have to understand both the application, and the
architecture. These are both difficult today, as the architectures are
changing about every 11 months or maybe less right now. Computation via
interferometry for example is one of the old (new) fields where a known
capability is only now capable of being explored. Optical computing,
3d shading, broadcast 3d, and other immersion technologies add new
requirements to the GPGU's being discussed. Motion coupled with 3d
means that the shaders and other elements need greater processing power,
and greater through put. Their architecture is undergoing severe
redesign. Even microcontrollers are expanding their reach via multiple
processors (via things like the propeller chip for example).
I am a test applications consultant. My trade forces me to
continuously update my skills and try to keep up with the multitude of
new architectures. I have almost no free time, as researching new
architectures, designing new algorithms, understanding the application
of algorithms to new tests, and hardware design requirements eats up
many hours every day. Fortunately I am and always have been a NERD and
proud of it. I work at it.
Since you have a deep knowledge of your requirements, perhaps you should
put some time into thinking of a design methodology other than those I
have mentioned or those that you know, in an attempt to improve the
science. I am sure many others would be very appreciative, and quite
likely supportive.
Most of my discussion of this issue has been on the usenet forum
comp.arch. I asked the community there for input on what would be
most useful, and, as part of a result of lengthy discussion, I started
a google groups mailing list and at least a place-holder for a wiki.
So far, most of the discussion has stayed on comp.arch, but I'm hoping
to attract a wider audience than just computer architects or people
with a special interest in computer architecture.
My announcement, as posted to comp.arch follows:
On Jul 23, 4:35 pm, Robert Myers <rbmyers...(a)gmail.com> wrote:
Thanks for all those who contributed to my RFC on high-bandwidth
computing.
I have set up a mailing list/discussion forum on google groups:
http://groups.google.com/group/high-bandwidth-computing
Andy Glew has been kind enough to offer a home for a wiki:
http://hbc.comp-arch.net/
That link currently redirects to a wiki, which so far has nothing but
mostly my blather in it. I hope this is a low point for the SNR.
Those who already have a gmail address can log in to google groups using
that ID and password.
Very early on, one contributor asked the reasonable question: why a
separate group?
I want to be able to attract contributors who might not naturally
contribute to comp.arch without wearing out the patience of the
comp.arch regulars.
I've forwarded the existing thread to the google groups list by hand.
If you want to continue to post here, please cc the high-bandwidth
computing group.
I'm new to all this. Suggestions are encouraged. Thanks to all who
have contributed so far. I hope the discussion will continue.
Some recent threads on comp.arch have pursued the subject of
non-sequential, high-bandwidth access to memory very aggressively.
Those who are interested in why GPU's aren't necessarily god's answer
to the needs of HPC might want to have a look.
Robert.
3:55 p.m.
On Sat, Jul 17, 2010 at 4:12 PM, Darr <darr(a)core.com> wrote:
On Thursday, 15 July, 2010 @23:21 zulu, Robert Myers scribed:
> You left out the Department of Energy, which is a much bigger
> player than the DoD.
Well, it sure would be nice if the DoE spent some of our
tax dollars making applications like the Clean Energy phase
2 task, being run by IBM's World Community Grid project
(http://worldcommunitygrid.org/research/cep2/overview.do )
and Harvard, that would use the GPU[s] from nVidia and ATI.
WCG uses Berkeley's BOINC framework that I mentioned
in my reply to the OP (whose author has not posted again, btw).
However, the applications that run in BOINC must be written
especially to make use of the GPU[s], and not all do (in fact,
none of the applications/tasks currently running at WCG can
use the GPU, and most that do under BOINC are windows-only).
Last time I looked, which is approaching a decade ago, computational solid
state physics (as practiced by our bloated national labs) had its own
problems, like mispredicting electron mobility in semiconductors by a factor
of five.
I've uninstalled BOINC from my own computers because it seemed way too
hackable, it has caused problems, and the energy argument (the computer is
on, anyway) doesn't really work for modern processors, where it makes a huge
difference whether my i7-920's are idling or grinding away on a calculation
I am not supervising myself. I also could not find an application I was
interested in that would put my pointlessly powerful GPU's to work.
For all the money the DoE spends, you'd think it could come up with a
coherent effort to manage the computational resources and needs of the
country, including efforts like BOINC. The real trouble is that a project
like BOINC (unlike a huge new computer that requires its own building)
produces no photo-ops, no facility that senators and members of congress can
be taken on a tour of, and no bloated staff to justify a higher civil
service rating, larger office, and higher salary.
In theory, there are lots of things that the smart and curious people of a
community like the Fedora Project might be doing, but the leadership has to
come from somewhere.
Robert.
5:44 p.m.
On 07/15/2010 01:58 PM, Michael Miles wrote:
On 07/15/2010 11:38 AM, JD wrote:
> On 07/15/2010 11:23 AM, Michael Miles wrote:
>
>> On 07/15/2010 12:18 AM, JD wrote:
>>
>>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>>
>>>
>>>> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net>
wrote:
>>>>
>>>>
>>>>
>>>>> Agreed that an OS kernel hasn't much use for a GPU. But it should
be
>>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a
couple
>>>>> of usb ports to the card and move X completely to the video card.
Just
>>>>> like a remote X server only in the same box.
>>>>>
>>>>> I really think the OP was referring to having user mode code take
>>>>> advantage of the high processing power of modern GPUs. It works now,
but
>>>>> could be improved if the OS contained specialized scheduling support
for
>>>>> these kinds of jobs.
>>>>>
>>>>>
>>>> I understand that the GPU has no page faults, and is missing many of
>>>> what we regard as the essential functions of a normal processor? Also
>>>> getting large amounts of data in or out of the GPU is slow - it is
>>>> fast partly because there is a lot less overhead compared to a single
>>>> processor and partly from the advantage of multiple cores. I was
>>>> speaking to someone who has been working with GPU processing for
>>>> several years and was skeptical about getting code to run reliably
>>>> across different GPUs... and of course CUDA is vendor specific as fa
>>>> as I know? So speed gain is dependent on the kind of processing needed
>>>> but if anything goes wrong then it can easily crash the system.
>>>>
>>>> Anyone had any experience with using the GPU could perhaps comment?
>>>>
>>>>
>>> Sorry to barge in this late into this thread....
>>> Was the originator of the thread interested in the kernel
>>> to use the gpu for floating point operations or integer
>>> operations?
>>> If floating point, the x86 (among others) already has an
>>> integrated fpu, and the integer logic is already in the cpu (or alu).
>>> So I do not understand what sort of computations the originator
>>> of the thread would like to see done on the gpu.
>>>
>>> jd
>>>
>>>
>> The other OS's Mac and Windows are using the GPU in its video
>> conversion programs.
>> The newer programs will have selections to activate the GPU for computation.
>>
>> I have been using the GPU for scientific computation for quite a while now.
>> Seti@home is very much a hobby and it takes samples from the areciebo
>> telescope and analyse data looking for "You guessed it, ET"
>> It will crunch numbers very fast compared to a normal CPU.
>>
>> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
>> Gflops .
>>
>> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
>> to a full teraflop.
>> That kind of speed would be well accepted if an OS would use it
>> generally or software that is written for Video conversion to use it
>> greatly reducing time.
>>
>>
>> That's what I would like to see, more focus on speeding up video
>> conversion especially with HD video and it seems that the GPU is a very
>> inexpensive way to add a lot of power to your machines
>>
> A teraflop?? WHoa! Can the PCI bus really feed the gpu with
> an instruction stream that will yield that performance?
> I mean most pc's out there are in people's homes still pci (33 or 66 MHz
> bus).
> Relatively, fewer are on pci x16 which is a much faster bus.
>
> Thanks for your feedback.
>
>
>
PCI-E only will handle that kind of speed.
It's also good to have a video card with fast ram and lots of it.
The new Fermi chips coming out and mindboggling fast, over a tflop
So yes seeing them take over some of the bigger computations for video
conversion would be great.
For instance the Nvidia 295 has 240 stream processors and is able to do
1788.48 gflops.
Put two or three together in a sli config and you've got some power there
http://en.wikipedia.org/wiki/GeForce_200_Series
This page will give you an idea of what these things do.
The 400 series uses Fermi and lets take the 480 gtx for instance, 480
stream processors
Now we are talking about 4+ tflops.
That's getting quick
As well Nvidia cards are well noted for over clocking.
My little 9400 runs at 550 and shader runs at 1375.
I can push those up to 700 and 1800 shader and no artifacts and no problems.
Michael
This is the kind of technology that is needed to solve huge mathematical
problems.
Most smaller universities and colleges do not have massively parallel
supercomputers that are
vector processors. This could make it easy for such colleges and small
university research
projects to have some decent computational power.
At the same time we have to be wary of the export laws for such devices
because one thing
that I had read some years back is that breaking cyphers is exactly what
such powerful processors
can be used for or adapted to be used for. For many years, this has been
a tug of war between
industry on one side, and the department of defense and the NSA on the
other.
3:03 p.m.
JD írta:
On 07/15/2010 12:07 PM, Zoltan Boszormenyi wrote:
> JD írta:
>
>> On 07/15/2010 11:23 AM, Michael Miles wrote:
>>
>>
>>> On 07/15/2010 12:18 AM, JD wrote:
>>>
>>>
>>>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>>>
>>>>
>>>>
>>>>> On Thu, Jul 15, 2010 at 5:27 AM, john
wendel<jwendel10(a)comcast.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Agreed that an OS kernel hasn't much use for a GPU. But it
should be
>>>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a
couple
>>>>>> of usb ports to the card and move X completely to the video card.
Just
>>>>>> like a remote X server only in the same box.
>>>>>>
>>>>>> I really think the OP was referring to having user mode code
take
>>>>>> advantage of the high processing power of modern GPUs. It works
now, but
>>>>>> could be improved if the OS contained specialized scheduling
support for
>>>>>> these kinds of jobs.
>>>>>>
>>>>>>
>>>>>>
>>>>> I understand that the GPU has no page faults, and is missing many of
>>>>> what we regard as the essential functions of a normal processor?
Also
>>>>> getting large amounts of data in or out of the GPU is slow - it is
>>>>> fast partly because there is a lot less overhead compared to a
single
>>>>> processor and partly from the advantage of multiple cores. I was
>>>>> speaking to someone who has been working with GPU processing for
>>>>> several years and was skeptical about getting code to run reliably
>>>>> across different GPUs... and of course CUDA is vendor specific as
fa
>>>>> as I know? So speed gain is dependent on the kind of processing
needed
>>>>> but if anything goes wrong then it can easily crash the system.
>>>>>
>>>>> Anyone had any experience with using the GPU could perhaps comment?
>>>>>
>>>>>
>>>>>
>>>> Sorry to barge in this late into this thread....
>>>> Was the originator of the thread interested in the kernel
>>>> to use the gpu for floating point operations or integer
>>>> operations?
>>>> If floating point, the x86 (among others) already has an
>>>> integrated fpu, and the integer logic is already in the cpu (or alu).
>>>> So I do not understand what sort of computations the originator
>>>> of the thread would like to see done on the gpu.
>>>>
>>>> jd
>>>>
>>>>
>>>>
>>> The other OS's Mac and Windows are using the GPU in its video
>>> conversion programs.
>>> The newer programs will have selections to activate the GPU for computation.
>>>
>>> I have been using the GPU for scientific computation for quite a while now.
>>> Seti@home is very much a hobby and it takes samples from the areciebo
>>> telescope and analyse data looking for "You guessed it, ET"
>>> It will crunch numbers very fast compared to a normal CPU.
>>>
>>> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
>>> Gflops .
>>>
>>> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
>>> to a full teraflop.
>>> That kind of speed would be well accepted if an OS would use it
>>> generally or software that is written for Video conversion to use it
>>> greatly reducing time.
>>>
>>>
>>> That's what I would like to see, more focus on speeding up video
>>> conversion especially with HD video and it seems that the GPU is a very
>>> inexpensive way to add a lot of power to your machines
>>>
>>>
>> A teraflop?? WHoa! Can the PCI bus really feed the gpu with
>> an instruction stream that will yield that performance?
>>
>>
> Err, no. GPUs are massively parallel beasts. They can't reach level of
> performance via a discrete instruction stream, not to mention even
> the PCIe bus couldn't cope with it really. The high performance comes
> from the GPU programmes are executed by their hardware threads
> in parallel on large amounts of data.
>
>
>> I mean most pc's out there are in people's homes still pci (33 or 66 MHz
>> bus).
>> Relatively, fewer are on pci x16 which is a much faster bus.
>>
>> Thanks for your feedback.
>>
>>
>>
>>
So, given the extreme limitations of the bus relative to the
teraflop speed of the gpu, how can the cpu feed the gpu with
"data" at a rate that can sustain continuous 1 teraflops/sec?
Usually the GPU is used for matrix-computations, the tricks involve
computations done with strict aligment requirements and cleverly
parallelized
algorithms and using computations that result in much less data as the
result
like vector length is a single number no matter the vector dimensions.
Only such computations worth rewriting to GPU because the card has to
upload the initial data to its memory, do the computation then push the
results back to the main RAM so the CPU can access it. And the upload +
the massively parallel GPU computation + download must still be faster
than the naively parallelized (2, 4 or little more threads to exploit
CPU cores)
or non-parallelized CPU computation to be worth the rewrite.
Is there a pci-e32 with a faster bus clock on the horizon?
No idea.
There are so many programs that use/need floating point operations
on matrices that could benefit vastly from this. I hope someone(s)
can point to such future HW development.
NVIDIA's big Tesla machines with 6GB GPU memory were built exactly
to save on the upload/download time. Many large matrices (like initial data,
partial and final results) and can fit into such large amount of memory...
2:07 p.m.
JD írta:
On 07/15/2010 11:23 AM, Michael Miles wrote:
> On 07/15/2010 12:18 AM, JD wrote:
>
>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>
>>
>>> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net>
wrote:
>>>
>>>
>>>
>>>> Agreed that an OS kernel hasn't much use for a GPU. But it should be
>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
>>>> of usb ports to the card and move X completely to the video card. Just
>>>> like a remote X server only in the same box.
>>>>
>>>> I really think the OP was referring to having user mode code take
>>>> advantage of the high processing power of modern GPUs. It works now, but
>>>> could be improved if the OS contained specialized scheduling support for
>>>> these kinds of jobs.
>>>>
>>>>
>>> I understand that the GPU has no page faults, and is missing many of
>>> what we regard as the essential functions of a normal processor? Also
>>> getting large amounts of data in or out of the GPU is slow - it is
>>> fast partly because there is a lot less overhead compared to a single
>>> processor and partly from the advantage of multiple cores. I was
>>> speaking to someone who has been working with GPU processing for
>>> several years and was skeptical about getting code to run reliably
>>> across different GPUs... and of course CUDA is vendor specific as fa
>>> as I know? So speed gain is dependent on the kind of processing needed
>>> but if anything goes wrong then it can easily crash the system.
>>>
>>> Anyone had any experience with using the GPU could perhaps comment?
>>>
>>>
>> Sorry to barge in this late into this thread....
>> Was the originator of the thread interested in the kernel
>> to use the gpu for floating point operations or integer
>> operations?
>> If floating point, the x86 (among others) already has an
>> integrated fpu, and the integer logic is already in the cpu (or alu).
>> So I do not understand what sort of computations the originator
>> of the thread would like to see done on the gpu.
>>
>> jd
>>
>>
> The other OS's Mac and Windows are using the GPU in its video
> conversion programs.
> The newer programs will have selections to activate the GPU for computation.
>
> I have been using the GPU for scientific computation for quite a while now.
> Seti@home is very much a hobby and it takes samples from the areciebo
> telescope and analyse data looking for "You guessed it, ET"
> It will crunch numbers very fast compared to a normal CPU.
>
> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
> Gflops .
>
> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
> to a full teraflop.
> That kind of speed would be well accepted if an OS would use it
> generally or software that is written for Video conversion to use it
> greatly reducing time.
>
>
> That's what I would like to see, more focus on speeding up video
> conversion especially with HD video and it seems that the GPU is a very
> inexpensive way to add a lot of power to your machines
>
A teraflop?? WHoa! Can the PCI bus really feed the gpu with
an instruction stream that will yield that performance?
Err, no. GPUs are massively parallel beasts. They can't reach level of
performance via a discrete instruction stream, not to mention even
the PCIe bus couldn't cope with it really. The high performance comes
from the GPU programmes are executed by their hardware threads
in parallel on large amounts of data.
I mean most pc's out there are in people's homes still pci
(33 or 66 MHz
bus).
Relatively, fewer are on pci x16 which is a much faster bus.
Thanks for your feedback.
1:23 p.m.
On 07/15/2010 12:18 AM, JD wrote:
On 07/14/2010 11:41 PM, mike cloaked wrote:
> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net> wrote:
>
>
>> Agreed that an OS kernel hasn't much use for a GPU. But it should be
>> easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
>> of usb ports to the card and move X completely to the video card. Just
>> like a remote X server only in the same box.
>>
>> I really think the OP was referring to having user mode code take
>> advantage of the high processing power of modern GPUs. It works now, but
>> could be improved if the OS contained specialized scheduling support for
>> these kinds of jobs.
>>
> I understand that the GPU has no page faults, and is missing many of
> what we regard as the essential functions of a normal processor? Also
> getting large amounts of data in or out of the GPU is slow - it is
> fast partly because there is a lot less overhead compared to a single
> processor and partly from the advantage of multiple cores. I was
> speaking to someone who has been working with GPU processing for
> several years and was skeptical about getting code to run reliably
> across different GPUs... and of course CUDA is vendor specific as fa
> as I know? So speed gain is dependent on the kind of processing needed
> but if anything goes wrong then it can easily crash the system.
>
> Anyone had any experience with using the GPU could perhaps comment?
>
Sorry to barge in this late into this thread....
Was the originator of the thread interested in the kernel
to use the gpu for floating point operations or integer
operations?
If floating point, the x86 (among others) already has an
integrated fpu, and the integer logic is already in the cpu (or alu).
So I do not understand what sort of computations the originator
of the thread would like to see done on the gpu.
jd
The other OS's Mac and Windows are using the GPU in its video
conversion programs.
The newer programs will have selections to activate the GPU for computation.
I have been using the GPU for scientific computation for quite a while now.
Seti@home is very much a hobby and it takes samples from the areciebo
telescope and analyse data looking for "You guessed it, ET"
It will crunch numbers very fast compared to a normal CPU.
I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
Gflops .
I have a slow video card Nvidia 9400GT. The bigger ones will go right up
to a full teraflop.
That kind of speed would be well accepted if an OS would use it
generally or software that is written for Video conversion to use it
greatly reducing time.
That's what I would like to see, more focus on speeding up video
conversion especially with HD video and it seems that the GPU is a very
inexpensive way to add a lot of power to your machines
3:58 p.m.
On 07/15/2010 11:38 AM, JD wrote:
On 07/15/2010 11:23 AM, Michael Miles wrote:
> On 07/15/2010 12:18 AM, JD wrote:
>
>> On 07/14/2010 11:41 PM, mike cloaked wrote:
>>
>>
>>> On Thu, Jul 15, 2010 at 5:27 AM, john wendel<jwendel10(a)comcast.net>
wrote:
>>>
>>>
>>>
>>>> Agreed that an OS kernel hasn't much use for a GPU. But it should be
>>>> easy to add a small general purpose CPU (ARM or Intel Atom) and a couple
>>>> of usb ports to the card and move X completely to the video card. Just
>>>> like a remote X server only in the same box.
>>>>
>>>> I really think the OP was referring to having user mode code take
>>>> advantage of the high processing power of modern GPUs. It works now, but
>>>> could be improved if the OS contained specialized scheduling support for
>>>> these kinds of jobs.
>>>>
>>>>
>>> I understand that the GPU has no page faults, and is missing many of
>>> what we regard as the essential functions of a normal processor? Also
>>> getting large amounts of data in or out of the GPU is slow - it is
>>> fast partly because there is a lot less overhead compared to a single
>>> processor and partly from the advantage of multiple cores. I was
>>> speaking to someone who has been working with GPU processing for
>>> several years and was skeptical about getting code to run reliably
>>> across different GPUs... and of course CUDA is vendor specific as fa
>>> as I know? So speed gain is dependent on the kind of processing needed
>>> but if anything goes wrong then it can easily crash the system.
>>>
>>> Anyone had any experience with using the GPU could perhaps comment?
>>>
>>>
>> Sorry to barge in this late into this thread....
>> Was the originator of the thread interested in the kernel
>> to use the gpu for floating point operations or integer
>> operations?
>> If floating point, the x86 (among others) already has an
>> integrated fpu, and the integer logic is already in the cpu (or alu).
>> So I do not understand what sort of computations the originator
>> of the thread would like to see done on the gpu.
>>
>> jd
>>
>>
> The other OS's Mac and Windows are using the GPU in its video
> conversion programs.
> The newer programs will have selections to activate the GPU for computation.
>
> I have been using the GPU for scientific computation for quite a while now.
> Seti@home is very much a hobby and it takes samples from the areciebo
> telescope and analyse data looking for "You guessed it, ET"
> It will crunch numbers very fast compared to a normal CPU.
>
> I bench my Phenom 2 965 at 3 gflops/cpu while the GPU will be doing 54
> Gflops .
>
> I have a slow video card Nvidia 9400GT. The bigger ones will go right up
> to a full teraflop.
> That kind of speed would be well accepted if an OS would use it
> generally or software that is written for Video conversion to use it
> greatly reducing time.
>
>
> That's what I would like to see, more focus on speeding up video
> conversion especially with HD video and it seems that the GPU is a very
> inexpensive way to add a lot of power to your machines
>
A teraflop?? WHoa! Can the PCI bus really feed the gpu with
an instruction stream that will yield that performance?
I mean most pc's out there are in people's homes still pci (33 or 66 MHz
bus).
Relatively, fewer are on pci x16 which is a much faster bus.
Thanks for your feedback.
PCI-E only will handle that kind of speed.
It's also good to have a video card with fast ram and lots of it.
The new Fermi chips coming out and mindboggling fast, over a tflop
So yes seeing them take over some of the bigger computations for video
conversion would be great.
For instance the Nvidia 295 has 240 stream processors and is able to do
1788.48 gflops.
Put two or three together in a sli config and you've got some power there
http://en.wikipedia.org/wiki/GeForce_200_Series
This page will give you an idea of what these things do.
The 400 series uses Fermi and lets take the 480 gtx for instance, 480
stream processors
Now we are talking about 4+ tflops.
That's getting quick
As well Nvidia cards are well noted for over clocking.
My little 9400 runs at 550 and shader runs at 1375.
I can push those up to 700 and 1800 shader and no artifacts and no problems.
Michael
5054
days inactive
5072
days old
44 comments
13 participants
participants (13)
-
Arthur Bela -
Bill Davidsen -
Christofer C. Bell -
Darr -
Genes MailLists -
Howard Howell -
JD -
John Wendel -
Kwan Lowe -
Michael Miles -
mike cloaked -
Robert Myers -
Zoltan Boszormenyi