2 ms·
If someone figured out how to write regular apps on a GPU (which would amount to parallelizing the app), it could change everything. 1. What would be a first s
by 6ren 16y ago
If someone figured out how to write regular apps on a GPU (which would amount to parallelizing the app), it could change everything.
1. What would be a first step towards this? It seems the big problem is that most code is sequential... and the opportunity is those parts that don't need to be, but just happen to be written that way.
2. Perhaps another opportunity is to try to remove the layers that make modern software so slow. Can they be distributed across all pipelines somehow?
3. Finally, a radical approach is not to try to convert existing apps, but to think about the whole problem of an app from the very beginning (what inputs will you get, what outputs do you want), and try to write that directly on a GPU. By making it concrete, you might see new tricks, perhaps by redefining the problem (the app's features).
- Synaesthesia 16y agoIt can't really be done trivially. A GPU is a massively parallel (hundreds of cores), very limited type of CPU, specifically made to execute vector operations.
- arctangent 16y agoI agree, and I can't wait for someone (or, more likely, some group) to figure out how to parallelise arbitrary programs across GPUs and CPUs in a way that is transparent to the programmer - or as nearly so as possible. I spend a lot of my "fun time" writing agent-based systems which involve multiple objects all running the same set of code within a single environment. A person could be forgiven for thinking that computers should be able to "just run it" on all these CPU or GPU cores but it doesn't work out that way right now unfortunately. I have tried Haskell but it's quite hard to do real work with, or maybe I am just dumb :-) No doubt answers will come with time. Perhaps the "pain" of slow CPU cores will force one (or some) of us to put in some time to writing the type of solution I refer to in my first paragraph. (The related concept of "peak oil" springs to mind.)
- sedachv 16y agoThis is what parallelizing Fortran compilers do. The space of programs that can be automatically parallelized is all computable programs (see http://en.wikipedia.org/wiki/Church–Rosser_theorem http://en.wikipedia.org/wiki/Church–Rosser_theorem). The space of programs that can be efficiently automatically parallelized is very small.
- adrianN 16y agoMany problems aren't parallelizable for reasonable definitions of the word (i.e. polylogarithmic depth and polynomial work: Nick's class) unless there are some major breakthroughs in complexity theory.
- sedachv 16y agoAs a class of problems, probably (although it hasn't been proven either way), but in terms of programs it comes down to the vagaries of data structures and algorithms - if the dataflow in your reduction graph makes it look like a linked list, there's only one way to reduce it. Guy Steele gave a really good talk about this at ICFP 2009: http://labs.oracle.com/projects/plrg/Publications/ICFPAugust2009Steele.pdf http://labs.oracle.com/projects/plrg/Publications/ICFPAugust...
- eru 16y agoThe good thing is that functional programmers will barely notice that they are using the new data structures. (It's still just filters and maps. Just your fold-functions will take slightly different arguments.)