8 ms·
Modern GPU: a collection of well-written GPGPU programming tutorials
- DanielRibeiro 15y agoI find it interesting that you can write for the GPU using Haskell's GPipe: http://www.haskell.org/haskellwiki/GPipe/Tutorial http://www.haskell.org/haskellwiki/GPipe/Tutorial
- pp13 15y agoNice Link! We need more of these technical links on HN.
- rw 15y agoBack in the old days...
- saundby 15y agoYeah, like, back in the old days we had a link to an 8085 instruction reference card that got some attention. I think that was about four months ago... ;)
- _delirium 15y agoI dunno, I just did some random sampling of old HN frontpages on archive.org, and there's not much technical stuff--- mostly startup news.
- deleted 15y ago[deleted]
- rafedb 15y agoyeah, way too many "LOOK AT MY COOL STARTUP!" posts these days lol
- hvs 15y agoYou've been on this website for less than two months. You do realize that this site used to be called "Startup News", right?
- chollida1 15y ago> You do realize that this site used to be called "Startup News", right? Did it? I've been here for over 1300 days and I don't remember it ever being called Startup News. I guess my memory isn't what it used to be:)
- rafedb 15y agoActually, been around longer than that just finally made an account because there was something worth commenting on. Keep down voting tho because of not liking the truth being said about how this site is turning more into what I stated previously, or better yet emo posts about how xyz startup is failing and the founders want to know why people don't like them
- krisw 15y agoIf you want an "easy" way get into GPU development, AMD recently launched an interesting (open source) project that transparently compiles JVM bytecode into OpenCL: http://blogs.amd.com/developer/2011/09/14/i-dont-always-write-gpu-code-in-java-but-when-i-do-i-like-to-use-aparapi/ http://blogs.amd.com/developer/2011/09/14/i-dont-always-writ... Definitely the easiest way I've seen to begin mucking around with GPU development.
- profquail 15y agoYep, I've talked to the AMD engineers who wrote it -- bunch of very smart guys. My startup (TidePowerd : http://www.tidepowerd.com http://www.tidepowerd.com) has a product called GPU .NET which JIT-compiles CIL (.NET bytecode) directly into GPU machine code; essentially, we've extended the .NET VM onto the GPU to make GPGPU coding as seamless as we possibly could. We'll be releasing a new version next week with a much-improved API; if you're experimenting with GPGPU coding, please give it a try -- feedback is super-helpful in shaping the API into something that's both really powerful and really easy to pick up and start coding with. Oh, and GPU .NET is written in F# -- which we don't support just yet for writing your GPU code, but we're hard at work to add that (likely around the end of November)!
- 0x12 15y agoHow do you deal with documenting the way the code gets mapped on to the GPU architecture? I've found that small tweaks in how things are laid out can cause huge performance gains (or losses) and if you've managed to automate that it would be really great.
- profquail 15y agoWell, we've managed to automate some of it -- things like the memory allocation/transferring we've got down fairly well and the new API we'll be releasing soon will take care of any edge cases. For some things, like how your structs are organized/laid out, we haven't automatically optimized that yet -- but one advantage of using .NET (vs. native code like CUDA or OpenCL) is that the CLR specs allows a lot of freedom in implementation; so in the future, we could pretty easily implement some code to analyze your data layout / access patterns and reorganize things under the hood for better performance. All without you needing to rewrite your code, of course ;) As time goes by though, and solidify the rest of our codebase, we'll be able to spend more time adding optimizations to the JIT compilers to get your code running as fast as the hardware allows, as often as possible.