Sanding our assholes with 150 grit. Slowly. Lovingly.

Graphics Card Cluster

The machines keep getting faster, but the programs keeping locking up? Why does a 2gig/768MB machine respond in several minutes after clicking on a folder. I don't want to blame software (again), because it happens on my Lin Machine and my Win machine. I am sure we can do some parallelizing with the graphics card.

I always have wondered how to use clustering on light tasks, for example 'opening a GUI application' or distributing tasks associated with 'clicking on menu items', stuff like that.

Basically, 'I' don't get overly excited about clusters that can calculate PI really fast. Anyway, I always read about these cheap graphics cards that have 100 million transistors. And, the speed in the graphics pipeline must be amazing.
So...I say use that graphics power to get rid of that, 'freshly reformatted machine, I have only 2 files open, clicking on the 'C:/' drive takes 4 minutes' problem.
Permalink Berlin Brown - at new job 
August 22nd, 2005
I'm not sure what causes the problem you speak of, but I'm pretty sure it is not graphics.

It was mentioned in a thread just the other day about how Windows makes th apps responsible for their own windows. This is part of the problem I suspect. I think something with accessing filesystem gets fubarred and the part that hands control back to the GUI is greatly delayed while it sorts itself out.

This is exactly the sort of reason that I created the above thread.
Permalink I am Jack's dainty desktop dimension 
August 22nd, 2005
Oh and grats on your new gig.
Permalink I am Jack's dainty desktop dimension 
August 22nd, 2005
"I'm not sure what causes the problem you speak of, but I'm pretty sure it is not graphics."

I figure that, but here is my logic. 'Graphics card is fast and not being used', 'CPU / Filesystem is locked up', Use the idle time on the graphics card.

Of course there are a lot of issues, but I know developers don't always think of parallelization, I thought I would put in a request for some bored hardware hacker out there.
Permalink Berlin Brown - at new job 
August 22nd, 2005
"Oh and grats on your new gig"

Thanks, I will try not to get fired.
Permalink Berlin Brown - at new job 
August 22nd, 2005
That's a good idea, really... that SETI thing and other parellel processing stuff could really benefit I bet, especially with how fast graphics cards are getting.

You get fired from your last gig?
Permalink I am Jack's dainty desktop dimension 
August 22nd, 2005
You've got a single IDE drive, don't you?

IDE drives are bigger, cheaper, and still monopolize the I/O bus and CPU when they need to think.

I don't know if SATA is any better.

<broken record>
I *do* know that SCSI has *always* been better.
</broken record>

BTW, if your whole system is locking up, that's the hard drive. If it's just one app, it might be the network subsystem timing out on a bunch of mapped drives that aren't connected any more.

Philo
Permalink Philo 
August 22nd, 2005
Here is a test for you:
Make a folder, and put 20 .txt documents in it.
Make folder #2 and put 20 word documents in it
Make folder #3 and put 20 .zip files in it.

Folder #2 should take slightly longer to render than folder 1 in windows explorer.

If it takes significantly longer to display #3 than the others, it is because windows is doing something stupid and trying to display the icons for the files. I've got a couple folders with 100+ zip files in it and it takes 2-10 minutes for a 2ghz machine to render the folder in windows explorer.
Permalink Peter 
August 22nd, 2005
Philo:

It is really more of a generic nuisance. It happens on a lot of machines that I use, the fastest of the fast with the top-notch ram. You are right, I can tackle the problem with fancy harddrives, but I wonder if we could streamline the smoothness of operating-system use through a little extra help from the graphics card.

Here is another one, I work with Java(flame me), that is a meaty application and the applications that are based on it are meaty. I can just hear the billions of cycles churning. There is only so much that a single CPU can do, I could opt for a second CPU or wait for those Intel multi-core things.
But, I guess I am looking at this from a layman-non-hardware person; but I can see that ATI Radeon X850 XT PE, 37.76 GB/s Bandwidth sucker just waiting for some playtime, sink it up with java apps or my other services that lockup.
Permalink Berlin Brown - at new job 
August 22nd, 2005
"I wonder if we could streamline the smoothness of operating-system use through a little extra help from the graphics card."

Uh, if the hard drive subsystem is consuming 100% of the CPU, what is the graphics card going to go on?

What you need is a hard drive controller that has a processor and RAM. However, hard drive controllers don't sell...

Philo
Permalink Philo 
August 22nd, 2005
Can't find the link at the moment, but there is a "general purpose" C compiler that targets graphics cards. Unfortunately, however, while the GOU is capable of a mind-boggling number of FP calculations a second it's heavily optimised for the kind of things that, well, a graphics card needs to do, and as a result it's really only efficient for a certain class of problem.
Permalink Mat Hall 
August 22nd, 2005
"Uh, if the hard drive subsystem is consuming 100% of the CPU, what is the graphics card going to go on?"

Why do you keep bringing up the harddrive? I don't know if it is the harddrive or whatever. I do know that running even a small number of heavy-duty applications degrades the performance of any machine, sometimes to a grinding halt. The harddrive may come into play, but it still doesnt solve the fact that I will have to reboot my machine and hope for the best nexttime.

Now, the next logic step is to buy more RAM or faster CPU, but at <4.0gigs, we are going to start seeing CPU speeds start to flatten, bus speeds flatten, so we wont be able to get any more speed that way. I am kind of dreaming up a naive solution, for example; take DirectX / OpenGL applications, they always run smoothly because the graphics card is doing all the crunchy. I wonder if (maybe with linux device-driver hacking) you could push data and requests through the graphics pipeline.


just a thought.
Permalink Berlin Brown - at new job 
August 22nd, 2005
"Why do you keep bringing up the harddrive?"

Because if the operation is IO bound (which seems exceedingly likely in this case) then adding more CPU power WILL DO NOTHING.

"I wonder if (maybe with linux device-driver hacking) you could push data and requests through the graphics pipeline."

The GPU is not a general purpose CPU so you really can't do much useful with it except display graphics. If you turn it into a general purpose CPU than you've done nothing but create another dual processor machine -- which we already have in abundance!
Permalink Almost H. Anonymous 
August 22nd, 2005
Berlin -
Run Perfmon and see which of the major subsystems is being pegged. Dollars to donuts it's not the CPU or graphics card -- it's almost certainly the hard drive.

I agree with Philo - if you want to see a system run fast, add four or five SCSI hard drives. They don't have to be high capacity -- in fact the smaller the better, usually. While the platter on the first drive is sloooowly making its way around to the read head, the controller has already sent I/O requests to the other drives. In the meantime, the main CPU is loafing, doing other stuff like painting the screen.
Permalink example 
August 22nd, 2005
As I brought up in a mini rant on the new desktop thread Windows is braindead in terms of dealing with block devices and their current status.

When you open any Explorer Window in any guise it runs around the installed block devices, the shortcuts in Network Neighbourhood and any mapped drives you've got in the always map this drive keys in the registry.

There might be a slight attempt at cacheing this information but its so marginal as to be useless in general use.

If there is any cause to block I/O at the point it interrogates for status or the driver it prods is ill written you'll get a delay and the times when you really notice it you have some device that's misbehaving.

There are other possible reasons for sluggishness, not tuning the swap drive can be one.
Permalink Simon Lucy 
August 22nd, 2005
Hmm, I am about to do what they should do in politics; change my position.

Ok, it is about beefing up my drives. I will have to read up on this stuff. Next question, if all of you have pointed to the drive, why don't they design drives such that they have the systems you presented. Drives are pretty cheap, they rarely put in multiple drives? It seems like a waste and a bad mark on the PC makers. On my home machine and my work machine, I counted '4 minutes' from the time I clicked on a folder. And, my server (Local BEA Weblogic) rarely runs properly.
Permalink Berlin Brown 
August 22nd, 2005
"design drives such that they have the systems you presented"

replace that with '...design PCs such that'
Permalink Berlin Brown 
August 22nd, 2005
Here's a slashdot article with links to some information about using GPUs for other tasks:

http://developers.slashdot.org/article.pl?sid=05/06/29/0021256&tid=231&tid=8

That said, I think the problem you're seeing is a combination of poor software design and a relatively slow hard drive. Drives have increased in size dramatically but their seek speed hasn't really changed much. We need a breakthrough in solid state storage.
Permalink Doug 
August 22nd, 2005
BTW, the bottleneck is the drive to some degree (this can be assuaged by splitting tasks among multiple drives and defragging mercilessly), but the real problem is generally the drive *interface*

IDE was designed to leverage the CPU for processing power. So it hammers the CPU when drive access is going on.

SCSI has the equivalent of a GPU for the drive controller. The next generation of SATA should have some of the features that makes SCSI faster.

Philo
Permalink Philo 
August 22nd, 2005
Interesting, see I learned something.

I am still going to play with the opengl, qsort.
Permalink Berlin Brown 
August 22nd, 2005

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: August, 2005 Other topics: August, 2005 Recent topics Recent topics