Saturday, May 26, 2012
Tuesday, May 8, 2012
Friday, April 20, 2012
Friday, April 13, 2012
Pseudonyms, Anonymity and Accountability
There once was a time when I wrote about things besides GPU computing regularly on this blog. My goal was to write about a variety of subjects and to have fun exercising those creative-writing-parts of the brain. It didn't take long for that practice to stop.
"Why?" - I hear you ask...
Even though hardly anyone would expect to get any use out of reading posts of any length involving my random thoughts on politics, detailed opinions on favored wines whiskeys or my propensity to drink both of them regularly, blasphemous religious references, or not-so-creative hack-jobs posing as "stories" in which juvenile ideas on peckers and boobs would be thinly polished over in a veneer of big words and predictable plots - the uselessness of it all is no insurance that it wouldn't get me in trouble. So my own self-imposed thought police took over and I stopped blogging about anything personal. For the most part.
The result has been that unless you're interested in GPU programming, (and...of course, I wish everyone were interested in GPU programming), or found use for the highly (I think) practical albiet narrowly targeted posts on scientific computing, I've written little that would be of interest to you in almost a year.
Not that I don't think I've written any interesting posts; my point is that I've stopped even thinking about writing controversial, sacrilegious, scandalous, divisive or just wantonly explicit posts on any public forum. (unless you count the time where I openly advocated using FORTRAN...)
Why? Because Stu is my real name(*) and - for reasons I cannot fully defend - I have become worried that even scarcely-read and mostly useless babbling about controversial subjects can come back to haunt me some day.
Another blogger posted an interesting discussion on whether or not certain people (in this case, mostly public school teachers) should have their "on-line activity" (like Facebook and blog posts, tweets, etc...) held to standards more exacting than those allowed by strictly legal rights.
My short answer to that question is: "Any time the public's perception of your beliefs or behavior matters for your job, you will be held to a higher standard; there is little you or I can do about it." Of course there are some lucky-duckies with tenure who can afford not to care.
One obvious option is to use a pseudonym and in so doing achieve a small modicum of anonymity.
There are both moral and practical pitfalls to this strategy of course and some other bloggers that I've read spent some time musing over the extent to which on-line anonymity has destroyed any sense of decency and accountability for our words, or on-line behavior in general.
As a result I put together a short essay on my views of the good/bad of the use of pseudonyms and it's impact on accountability as well as its effect on civility in online interactions. I'm not sure what the point of the whole essay is; it is notably without a conclusion. At any rate, even at risk of embarrassing myself on a blog containing my own name - I'll just throw these opinions out there and rest easy in the knowledge that most potential readers have simply stopped reading by now after wondering why I'm wasting their time babbling about something other than GPUs.
Anonymity can be very good.
In my opinion, the principle benefit of anonymity is the ability of disassociation: separate the idea from the person so that the idea can be judged on its own merits. Musicians, Politicians, philosophers, writers and artists of all types have employed the shield of a pseudonym to enrich the world of ideas.
Think of Hamilton, Madison and Jay writing the Federalist Papers under a pen name. Think of Voltaire, Ayn Rand, Mark Twain, George Orwell, and Dr. Seuss; all pseudonyms. Would Mary Ann Evans have had her fiction published if she hadn't called herself George Eliot instead? Would Ann Landers have provided such frank and sure advice if instead the author had to use her own name, Esther Friedman, and suffered from the rebuke of lifetime acquaintances who knew that she didn't always follow her own guidance? These people were not failing to stand behind their ideas; they simply wanted people to consider the ideas - not the imperfect human minds that produced them.
There is something to be said, of course, for standing behind your principles with your own name. John Hancock and other signers of the Declaration of Independence didn't seem to have much trouble taking accountability. Not everyone is similarly endowed; we cannot all have the courage of Galileo or Martin Luther or - for that matter - Martin Luther King.
Those are the big ideas - but the small ideas can bring needless suffering to those who express them as well.
Given that we have morphed into a society where people only seem to "communicate" over open, infinitely replicable mediums, the resulting burden of accountability can be suffocating. Consider the teacher who airs a complaint about a few inept and unruly students on a Facebook wall post; or wants her friends and family to know that she's having fun and unwinding with a few fruity drinks while on vacation with her husband, and winds up unemployed as a result. To those people, pseudonym and the associated degree of anonymity can be liberating.
Still, nowadays, I don't know if such fronts work so well. Especially on the internet, the anonymity afforded by a pseudonym is only a thin veil; transparent to anyone who is willing to take the time to look.
Anonymity - such as it is - and the resulting freedom also often comes at the cost of credibility. Many opinions only seem to "matter" if they come from real people with (maybe not-so-real) credentials. Those (sometimes) capable people who are willing to present their ideas to a wider audience regularly take a beating from anonymous tomato-throwers. Here I think of Nobel Prize-winning social and physical scientists, Pulitzer Prize-winning authors or simply brilliant, wise and good-tempered citizens who bother to share a piece of their hard-earned wisdom or well-considered opinions, only to be shouted-down by crowd of mouth-breathing nincompoops.
Which brings us to the bad side of anonymity on which many people can agree on.
Anonymity reveals an inherent weakness in human nature.
I am convinced that, not-so-deep down, most people (not all...I hope) are endowed with a limitless reservoir of boiling contempt towards most other people; at least people who live and work around us. (the rest of humanity, we simply do not care about enough to hate) Though polite society asks us to keep this bottled up inside, anonymous comments or profane and libelous screeds published under false identities provide a mechanism to release the internal pressure of suppressed hatred. You may not accept such an extreme view, but I can only say that there is a reason why all those smart folks I mentioned before decided that it was better if they used a false name and kept their thoughts and ideas away from those who knew them personally. This has been true even before Jesus observed that a prophet can find honor everywhere except in his home town.
That doesn't mean I think such behavior is "ok" or "healthy" or anything like that; just that it seems to be a natural consequence of the fact that we're human. I'm not sure there is any way to fix it. Ever.
(*) Ok...just my real first name. You have to dig into the bowels of my blog to get my last name.
"Why?" - I hear you ask...
Even though hardly anyone would expect to get any use out of reading posts of any length involving my random thoughts on politics, detailed opinions on favored wines whiskeys or my propensity to drink both of them regularly, blasphemous religious references, or not-so-creative hack-jobs posing as "stories" in which juvenile ideas on peckers and boobs would be thinly polished over in a veneer of big words and predictable plots - the uselessness of it all is no insurance that it wouldn't get me in trouble. So my own self-imposed thought police took over and I stopped blogging about anything personal. For the most part.
The result has been that unless you're interested in GPU programming, (and...of course, I wish everyone were interested in GPU programming), or found use for the highly (I think) practical albiet narrowly targeted posts on scientific computing, I've written little that would be of interest to you in almost a year.
Not that I don't think I've written any interesting posts; my point is that I've stopped even thinking about writing controversial, sacrilegious, scandalous, divisive or just wantonly explicit posts on any public forum. (unless you count the time where I openly advocated using FORTRAN...)
Why? Because Stu is my real name(*) and - for reasons I cannot fully defend - I have become worried that even scarcely-read and mostly useless babbling about controversial subjects can come back to haunt me some day.
Another blogger posted an interesting discussion on whether or not certain people (in this case, mostly public school teachers) should have their "on-line activity" (like Facebook and blog posts, tweets, etc...) held to standards more exacting than those allowed by strictly legal rights.
My short answer to that question is: "Any time the public's perception of your beliefs or behavior matters for your job, you will be held to a higher standard; there is little you or I can do about it." Of course there are some lucky-duckies with tenure who can afford not to care.
One obvious option is to use a pseudonym and in so doing achieve a small modicum of anonymity.
There are both moral and practical pitfalls to this strategy of course and some other bloggers that I've read spent some time musing over the extent to which on-line anonymity has destroyed any sense of decency and accountability for our words, or on-line behavior in general.
As a result I put together a short essay on my views of the good/bad of the use of pseudonyms and it's impact on accountability as well as its effect on civility in online interactions. I'm not sure what the point of the whole essay is; it is notably without a conclusion. At any rate, even at risk of embarrassing myself on a blog containing my own name - I'll just throw these opinions out there and rest easy in the knowledge that most potential readers have simply stopped reading by now after wondering why I'm wasting their time babbling about something other than GPUs.
Anonymity can be very good.
In my opinion, the principle benefit of anonymity is the ability of disassociation: separate the idea from the person so that the idea can be judged on its own merits. Musicians, Politicians, philosophers, writers and artists of all types have employed the shield of a pseudonym to enrich the world of ideas.
Think of Hamilton, Madison and Jay writing the Federalist Papers under a pen name. Think of Voltaire, Ayn Rand, Mark Twain, George Orwell, and Dr. Seuss; all pseudonyms. Would Mary Ann Evans have had her fiction published if she hadn't called herself George Eliot instead? Would Ann Landers have provided such frank and sure advice if instead the author had to use her own name, Esther Friedman, and suffered from the rebuke of lifetime acquaintances who knew that she didn't always follow her own guidance? These people were not failing to stand behind their ideas; they simply wanted people to consider the ideas - not the imperfect human minds that produced them.
There is something to be said, of course, for standing behind your principles with your own name. John Hancock and other signers of the Declaration of Independence didn't seem to have much trouble taking accountability. Not everyone is similarly endowed; we cannot all have the courage of Galileo or Martin Luther or - for that matter - Martin Luther King.
Those are the big ideas - but the small ideas can bring needless suffering to those who express them as well.
Given that we have morphed into a society where people only seem to "communicate" over open, infinitely replicable mediums, the resulting burden of accountability can be suffocating. Consider the teacher who airs a complaint about a few inept and unruly students on a Facebook wall post; or wants her friends and family to know that she's having fun and unwinding with a few fruity drinks while on vacation with her husband, and winds up unemployed as a result. To those people, pseudonym and the associated degree of anonymity can be liberating.
Still, nowadays, I don't know if such fronts work so well. Especially on the internet, the anonymity afforded by a pseudonym is only a thin veil; transparent to anyone who is willing to take the time to look.
Anonymity - such as it is - and the resulting freedom also often comes at the cost of credibility. Many opinions only seem to "matter" if they come from real people with (maybe not-so-real) credentials. Those (sometimes) capable people who are willing to present their ideas to a wider audience regularly take a beating from anonymous tomato-throwers. Here I think of Nobel Prize-winning social and physical scientists, Pulitzer Prize-winning authors or simply brilliant, wise and good-tempered citizens who bother to share a piece of their hard-earned wisdom or well-considered opinions, only to be shouted-down by crowd of mouth-breathing nincompoops.
Which brings us to the bad side of anonymity on which many people can agree on.
Anonymity reveals an inherent weakness in human nature.
I am convinced that, not-so-deep down, most people (not all...I hope) are endowed with a limitless reservoir of boiling contempt towards most other people; at least people who live and work around us. (the rest of humanity, we simply do not care about enough to hate) Though polite society asks us to keep this bottled up inside, anonymous comments or profane and libelous screeds published under false identities provide a mechanism to release the internal pressure of suppressed hatred. You may not accept such an extreme view, but I can only say that there is a reason why all those smart folks I mentioned before decided that it was better if they used a false name and kept their thoughts and ideas away from those who knew them personally. This has been true even before Jesus observed that a prophet can find honor everywhere except in his home town.
That doesn't mean I think such behavior is "ok" or "healthy" or anything like that; just that it seems to be a natural consequence of the fact that we're human. I'm not sure there is any way to fix it. Ever.
(*) Ok...just my real first name. You have to dig into the bowels of my blog to get my last name.
Friday, March 9, 2012
GPU Computing with Matlab: A Casual Comparison between Parallel Computing Toolbox and Jacket
Lately a number of researchers at my school have expressed interest in taking the plunge with GPU computing. They hope to get performance improvements but they're also heavily invested in the MATLAB programming model; I don't blame them. They've asked me about Jacket and they've asked me about the Parallel Computing Toolbox and now that they have endured long afternoons with me babbling excitedly like a amphetamine-soaked chipmunk they probably regret asking.
Nonetheless, I'm here to share my thoughts with you as well.
I know I've made several posts about this general subject before and it's hard not to feel a bit sheepish about writing on this subject yet again. Still, I find that in the 9 months since I wrote my last summary on this subject, my opinions have changed quite a bit.
Disclaimer:
This comparison is not going to be fair. It can't be; I don't really have the time for a comprehensive and carefully controlled and thoroughly documented study. This is just a blog post and these are just my opinions formed over several months of doing little other than GPU computing.
With an occasional glass of Scotch mixed in of course.
I ask that you take this into consideration and please don't bother to send me hate-mail if you think I've cheated somewhere. I am not trying to.
Also, in cases where I discuss code performance or GPU speed-ups that I've obtained, please don't bother to tell me my code is weak. I know.
I do, however, hope that even if this comparison is not fair, at least it will be useful.
I will group my comments in three broad categories:
I. Price.
II. Performance.
III. Capabilities.
If you've got better things to do than read my babbling then maybe you'll want to skip to my final answer and here it is:
Price: Parallel Computing Toolbox (PCT) costs less. A lot less if you're a student. If you're a professional working for a company or a government organization, the money you spend on either product probably isn't even a consideration. Still, for those folks who plan to pay out of their own pocket, PCT is less expensive.
Performance: I've gotten better performance from Jacket. Whether I'm simply casting my data to the GPU and praying for performance or if I'm incorporating tuned kernels using the Jacket's SDK or PCT's CUDAKernel interface - Jacket has been faster in every case. Mostly by a factor of 4x or so. Sometimes more.
Capability: Jackets graphics functions are much superior to what you get with PCT; not even in the same ballpark. The sparse linear algebra add-on for Jacket gives you a capability that is simply unavailable with PCT.
There are probably more comparisons that can be made - but those are the ones that stick in my mind the most.
If you want to know more about why I came to the above conclusions: keep reading.
Price
Jacket costs money. A base license for academic folks runs at $350. If you get the optional Software Development Kit (SDK) - and I strongly suggest you do - you're going to have to cough up another $350. If you do research with numerical PDEs using finite element methods and are accustomed to using MATLAB's sparse matrix functionality, you'll also need the Sparse Linear Algebra (SLA) add-on; that'll set you back another $140. All told, it's pretty easy to drop $1000 on Jacket. If you're like me, you will probably not think too hard about using Jacket unless someone else buys it and makes it available to you.
On the other hand - if you're not like me and you work for an organization that is willing to fork out a little cash on software so they don't have to pay you a LOT of cash for developing new software, a thousand bucks may not be a barrier at all.
The PCT costs money too. Something like $30 if you're a student and you already have the student version of MATLAB. Not too shabby. That's less than I spent for my last bottle of 12 year old Bruichladdich.
If you're solely looking at price and you just want something that will get you started with GPU computing while holding tight to MATLAB; PCT is the choice for you.
Before you stop reading though, I think there are more things to consider than just cost.
Performance
Jacket wins.
Yeah, it's not fair to say it that way.
Still, I'm going to say it. For new MATLAB applications, my process follows something like:
a) simple prototyping. Get the program to work and make sure it's right.
b) vectorize. Get the program to run reasonably well using just MATLAB. Usually this results in a speedup of about 5x compared to step (a), but for poorly written prototype code, the speedup seen here can be more than 100x. How your write your MATLAB matters a lot.
c) Create a basic GPU-accelerated version where the only changes you make to the code are to cast the relevant variables to the GPU. For my code, Jacket has outperformed PCT every time at this step. Actually, PCT is usually outperformed by the step (b) MATLAB code. I'm sure it's not like this for every application but this is simply what I've observed for my codes.
d) I used to think that good performance was not obtainable in a MATLAB environment. That's not true. To obtain really good performance with either PCT or Jacket, I've found it absolutely essential to make use of their lower-level CUDA programming functionality. For PCT, that means chunks of my time-critical code needs to be re-written using the CUDAKernel interface. I give a simple example of how to do that in this post. For Jacket, I employ the SDK features to do more-or-less the same thing and I give details of how to do this here. At this level Jacket also wins.
The outcome of using the Jacket SDK is the creation of a new function that looks and smells exactly like a function delivered with the Jacket library. This means a lot to folks like me who really want the basic application code to remain mostly unchanged. With the PCT, your original code becomes littered with feval(...) invocations and thread launch configurations and other details that, I think, are better tucked away. Just my opinion.
With Jacket and the SDK, I've found that I can obtain performance equal to what I can get with a fully compiled executable. My single-GPU 3D lattice Boltzmann models churn through a reasonably good 450 million lattice point updates per second on my GTX-580 which is basically what I get with pure C++/CUDA code. (sometimes less...depending on the LBM model. For comparison, the same program on a CPU-only vectorized MATLAB implementation performs a bit under 2 million lattice point updates per second. With a multi-threaded C++ code using OpenMP and icpc compiler, I can hit a bit less than 20 million updates per second on my Intel i5-2500.)
With the PCT model - employing the exact same kernel with the same thread launch configuration - I top out at a little under 100 million lattice point updates per second. I assume the 4x performance hit has to do with the run-time interpretation of the ptx code, but I don't pretend to really know.
The Jacket SDK also provides you a bit more flexibility than the PCT CUDAKernel feature in that Jacket SDK allows more access direct access to GPU data. With Jacket SDK, you can get access to a pointer to GPU data and feed that to any CUDA-enabled function you can think of. With PCT - all you can employ is a kernel; there is no way to access the underlying data outside of the bounds of individual kernels. For users who hope to incorporate CUDA-accelerated functions, libraries or even whole applications into their MATLAB program, this added flexibility can be a big incentive to take a closer look at Jacket with the SDK.
Capabilities
Jacket is more capable.
If you need to do sparse matrix operations, you want Jacket.
Sure you could try to implement your own equivalent of a sparse matrix data type in MATLAB and write kernels to try and achieve the same behavior. I'm getting queezy just now as I sit here and think about that prospect. Either that or it's the fish sandwich I had for lunch.
No.
It's the idea of me trying to cobble together my own high-performance sparse matrix library. I do need to graduate some day after all.
Graphics. I get excited whenever I talk about the graphics functionality of Jacket. Maybe it would be safest for us all if I just stop there. Bottom line, Jacket provides excellent 2D and 3D graphics to go with GPU-borne data. Performance impact of run-time visualization is about on the order of 10% - 20% in my experience. In short: it's awesome.
For MATLAB's PCT? - Not so good. The positive thing I can say is that MATLAB's built-in graphics has convenient and useful features for creating movies from a sequence of plots that Jacket doesn't seem to directly support. (though, there's no law against sending the data to the CPU and then processing with MATLAB's built-in functions if you *really* need to save a movie.)
I would say more about the breadth of GPU-accelerated features of the two libraries but I can't. I simply don't know everything about each package's feature set. Anyway, you probably only care about whether features critical to your particular application are supported; you'll just have to check that out yourself.
Well, I hope that wasn't too long or boring. I would re-read this a few more times and try to make it more interesting or funny, but it's Friday afternoon, the sun is shining and I think it's time to walk around for a while.
Have a great weekend!!
Nonetheless, I'm here to share my thoughts with you as well.
I know I've made several posts about this general subject before and it's hard not to feel a bit sheepish about writing on this subject yet again. Still, I find that in the 9 months since I wrote my last summary on this subject, my opinions have changed quite a bit.
Disclaimer:
This comparison is not going to be fair. It can't be; I don't really have the time for a comprehensive and carefully controlled and thoroughly documented study. This is just a blog post and these are just my opinions formed over several months of doing little other than GPU computing.
With an occasional glass of Scotch mixed in of course.
I ask that you take this into consideration and please don't bother to send me hate-mail if you think I've cheated somewhere. I am not trying to.
Also, in cases where I discuss code performance or GPU speed-ups that I've obtained, please don't bother to tell me my code is weak. I know.
I do, however, hope that even if this comparison is not fair, at least it will be useful.
I will group my comments in three broad categories:
I. Price.
II. Performance.
III. Capabilities.
If you've got better things to do than read my babbling then maybe you'll want to skip to my final answer and here it is:
Price: Parallel Computing Toolbox (PCT) costs less. A lot less if you're a student. If you're a professional working for a company or a government organization, the money you spend on either product probably isn't even a consideration. Still, for those folks who plan to pay out of their own pocket, PCT is less expensive.
Performance: I've gotten better performance from Jacket. Whether I'm simply casting my data to the GPU and praying for performance or if I'm incorporating tuned kernels using the Jacket's SDK or PCT's CUDAKernel interface - Jacket has been faster in every case. Mostly by a factor of 4x or so. Sometimes more.
Capability: Jackets graphics functions are much superior to what you get with PCT; not even in the same ballpark. The sparse linear algebra add-on for Jacket gives you a capability that is simply unavailable with PCT.
There are probably more comparisons that can be made - but those are the ones that stick in my mind the most.
If you want to know more about why I came to the above conclusions: keep reading.
Price
Jacket costs money. A base license for academic folks runs at $350. If you get the optional Software Development Kit (SDK) - and I strongly suggest you do - you're going to have to cough up another $350. If you do research with numerical PDEs using finite element methods and are accustomed to using MATLAB's sparse matrix functionality, you'll also need the Sparse Linear Algebra (SLA) add-on; that'll set you back another $140. All told, it's pretty easy to drop $1000 on Jacket. If you're like me, you will probably not think too hard about using Jacket unless someone else buys it and makes it available to you.
On the other hand - if you're not like me and you work for an organization that is willing to fork out a little cash on software so they don't have to pay you a LOT of cash for developing new software, a thousand bucks may not be a barrier at all.
The PCT costs money too. Something like $30 if you're a student and you already have the student version of MATLAB. Not too shabby. That's less than I spent for my last bottle of 12 year old Bruichladdich.
If you're solely looking at price and you just want something that will get you started with GPU computing while holding tight to MATLAB; PCT is the choice for you.
Before you stop reading though, I think there are more things to consider than just cost.
Performance
Jacket wins.
Yeah, it's not fair to say it that way.
Still, I'm going to say it. For new MATLAB applications, my process follows something like:
a) simple prototyping. Get the program to work and make sure it's right.
b) vectorize. Get the program to run reasonably well using just MATLAB. Usually this results in a speedup of about 5x compared to step (a), but for poorly written prototype code, the speedup seen here can be more than 100x. How your write your MATLAB matters a lot.
c) Create a basic GPU-accelerated version where the only changes you make to the code are to cast the relevant variables to the GPU. For my code, Jacket has outperformed PCT every time at this step. Actually, PCT is usually outperformed by the step (b) MATLAB code. I'm sure it's not like this for every application but this is simply what I've observed for my codes.
d) I used to think that good performance was not obtainable in a MATLAB environment. That's not true. To obtain really good performance with either PCT or Jacket, I've found it absolutely essential to make use of their lower-level CUDA programming functionality. For PCT, that means chunks of my time-critical code needs to be re-written using the CUDAKernel interface. I give a simple example of how to do that in this post. For Jacket, I employ the SDK features to do more-or-less the same thing and I give details of how to do this here. At this level Jacket also wins.
The outcome of using the Jacket SDK is the creation of a new function that looks and smells exactly like a function delivered with the Jacket library. This means a lot to folks like me who really want the basic application code to remain mostly unchanged. With the PCT, your original code becomes littered with feval(...) invocations and thread launch configurations and other details that, I think, are better tucked away. Just my opinion.
With Jacket and the SDK, I've found that I can obtain performance equal to what I can get with a fully compiled executable. My single-GPU 3D lattice Boltzmann models churn through a reasonably good 450 million lattice point updates per second on my GTX-580 which is basically what I get with pure C++/CUDA code. (sometimes less...depending on the LBM model. For comparison, the same program on a CPU-only vectorized MATLAB implementation performs a bit under 2 million lattice point updates per second. With a multi-threaded C++ code using OpenMP and icpc compiler, I can hit a bit less than 20 million updates per second on my Intel i5-2500.)
With the PCT model - employing the exact same kernel with the same thread launch configuration - I top out at a little under 100 million lattice point updates per second. I assume the 4x performance hit has to do with the run-time interpretation of the ptx code, but I don't pretend to really know.
The Jacket SDK also provides you a bit more flexibility than the PCT CUDAKernel feature in that Jacket SDK allows more access direct access to GPU data. With Jacket SDK, you can get access to a pointer to GPU data and feed that to any CUDA-enabled function you can think of. With PCT - all you can employ is a kernel; there is no way to access the underlying data outside of the bounds of individual kernels. For users who hope to incorporate CUDA-accelerated functions, libraries or even whole applications into their MATLAB program, this added flexibility can be a big incentive to take a closer look at Jacket with the SDK.
Capabilities
Jacket is more capable.
If you need to do sparse matrix operations, you want Jacket.
Sure you could try to implement your own equivalent of a sparse matrix data type in MATLAB and write kernels to try and achieve the same behavior. I'm getting queezy just now as I sit here and think about that prospect. Either that or it's the fish sandwich I had for lunch.
No.
It's the idea of me trying to cobble together my own high-performance sparse matrix library. I do need to graduate some day after all.
Graphics. I get excited whenever I talk about the graphics functionality of Jacket. Maybe it would be safest for us all if I just stop there. Bottom line, Jacket provides excellent 2D and 3D graphics to go with GPU-borne data. Performance impact of run-time visualization is about on the order of 10% - 20% in my experience. In short: it's awesome.
For MATLAB's PCT? - Not so good. The positive thing I can say is that MATLAB's built-in graphics has convenient and useful features for creating movies from a sequence of plots that Jacket doesn't seem to directly support. (though, there's no law against sending the data to the CPU and then processing with MATLAB's built-in functions if you *really* need to save a movie.)
I would say more about the breadth of GPU-accelerated features of the two libraries but I can't. I simply don't know everything about each package's feature set. Anyway, you probably only care about whether features critical to your particular application are supported; you'll just have to check that out yourself.
Well, I hope that wasn't too long or boring. I would re-read this a few more times and try to make it more interesting or funny, but it's Friday afternoon, the sun is shining and I think it's time to walk around for a while.
Have a great weekend!!
Tuesday, February 14, 2012
Monday, December 19, 2011
Some Useful Tools for Numerical Solution of PDEs on a Workstation
1. Forgive me for starting my babbling right away - but given how long I've held out on posting - I'm nearly bursting at the seams.
2. This post is meant to introduce a series of posts on - well, the title says it - numerical PDEs on a workstation, but I'm not sure if I'm addressing anyone who is interested; well...not really, but these are subjects that seem to get less air-time.
The posts are:
I. Mesh generation using GMSH
II. CUDA-accelerated Sparse matrix assembly and solution using CUSP; and
III. Run-time visualization of CUDA-accelerated programs with jacket and libjacket.
3. Obviously, these are only tools for the numerical solution of PDEs, not the whole tool chest and - like all tools - they are useful for more than just working with PDEs. Still, I had to give my post something for a name.
4. One question you may be asking yourself: Who cares?
That is a good question.
5. I sense that I'm sitting in the middle of a great divide. On one side sits the large body of students, researchers and professionals who do pretty much all of their numerical work with MATLAB. If you can't do it on a single computer using MATLAB: it's just unreasonably hard to do.
6. On the other side are the not quite so large body of professionals who are completely uninterested in a computational technique that does not scale to a 100 TB data-set running on a 100,000 node supercomputer.
7. In summary, I'm talking about problem sizes that are too big to be reasonable, but too small to be interesting - depending on who you talk to.
8. For me, however, this type of problem is exactly where my research fits. Too hard to just throw over to MATLAB - it would take weeks or months to complete; but not so hard or large that it justifies a supercomputer....as if I had access to a supercomputer....or really have the training and expertise to use if effectively if I did.
9. Naturally, I have turned to GPU computing with CUDA to try and solve my problems - where possible leveraging MATLAB - and for the most part, it has been a successful if not actually a shoe-dampening good time.
10. Some of these experiences I've written about in earlier posts. If you love MATLAB but your computations take too long and you've got a CUDA-capable GPU, you should read this post first. Check out my other posts on those subjects if you find them helpful.
11. But if you're doing work with your "desktop supercomputer" I hope you find some of these posts useful.
2. This post is meant to introduce a series of posts on - well, the title says it - numerical PDEs on a workstation, but I'm not sure if I'm addressing anyone who is interested; well...not really, but these are subjects that seem to get less air-time.
The posts are:
I. Mesh generation using GMSH
II. CUDA-accelerated Sparse matrix assembly and solution using CUSP; and
III. Run-time visualization of CUDA-accelerated programs with jacket and libjacket.
3. Obviously, these are only tools for the numerical solution of PDEs, not the whole tool chest and - like all tools - they are useful for more than just working with PDEs. Still, I had to give my post something for a name.
4. One question you may be asking yourself: Who cares?
That is a good question.
5. I sense that I'm sitting in the middle of a great divide. On one side sits the large body of students, researchers and professionals who do pretty much all of their numerical work with MATLAB. If you can't do it on a single computer using MATLAB: it's just unreasonably hard to do.
6. On the other side are the not quite so large body of professionals who are completely uninterested in a computational technique that does not scale to a 100 TB data-set running on a 100,000 node supercomputer.
7. In summary, I'm talking about problem sizes that are too big to be reasonable, but too small to be interesting - depending on who you talk to.
8. For me, however, this type of problem is exactly where my research fits. Too hard to just throw over to MATLAB - it would take weeks or months to complete; but not so hard or large that it justifies a supercomputer....as if I had access to a supercomputer....or really have the training and expertise to use if effectively if I did.
9. Naturally, I have turned to GPU computing with CUDA to try and solve my problems - where possible leveraging MATLAB - and for the most part, it has been a successful if not actually a shoe-dampening good time.
10. Some of these experiences I've written about in earlier posts. If you love MATLAB but your computations take too long and you've got a CUDA-capable GPU, you should read this post first. Check out my other posts on those subjects if you find them helpful.
11. But if you're doing work with your "desktop supercomputer" I hope you find some of these posts useful.
Subscribe to:
Posts (Atom)