Computation MMXII

2012
Not planning on using OpenCL for your projects going forward.

http://www.youtube.com/watch?v=Oi-bkNEaJJ4

Seriously, if you aren't learning OpenCL, you're going to be obsolete if you're a low-level C/C++ programmer, game programmer, AI programmer, etc.

C programmers
obsolete
2020
ISHYGDDT

>2012
>Not using Erlang for concurrent programs

>>1
Show me one GPU with free open source drivers on which OpenCL may run.

>>4
None. That ought to be motivation for freedom advocates to develop free drivers for this.

>>4
Clang is open source and compiles OpenCL C kernels, with target support for all of the major CPUs and intermediate bytecode output for both nVidia and AMD GPUs (PRX and AMD ISA). Intel, AMD, ARM, and nVidia all use Clang for their commercial OpenCL products already and contribute to Clang. You just need to roll your own OpenCL runtime, which isn't that hard, the spec is fairly small compared to say OpenGL. There are several open source OpenCL implementations being developed around Clang already that you can use as a starting point.

https://launchpad.net/pocl
http://libclc.llvm.org/
http://cgit.freedesktop.org/~steckdenis/clover/

And OpenCL isn't just for GPUs. It's for all types of compute devices. CPUs, GPUs, FPGAs, heterogenous cores like the PS3's Cell SPUs, or AMD's next-gen APUs which will have a multi-core x86-64 CPU, an ARM Cortex A5 core, and next-gen Radeon GPU all on the same die.

The best way to use it is as a task-oriented and grid-oriented threading engine for your CPU code. OpenCL can call into your host C/C++ functions, you just pass it a function pointer when scheduling a task.

OpenCL makes stuff like OpenMP or POSIX Threads/C11/C++11 threads obsolete.

>>6
AMD's next-gen APUs which will have a multi-core x86-64 CPU, an ARM Cortex A5 core, and next-gen Radeon GPU all on the same die.
And of course the specifications will cover just enough to use the first x86-64 CPU and nothing else.

>>6
Also, Khronos is planning on adopting a future edition of LLVM IR as the official intermediate language and ISA for OpenCL 2.0, so you can compile your compute kernels and run it everywhere. All of the vendors are standardizing on it.

AMD has open-sourced their OpenCL LLVM backend already for Mesa/X.org.

http://www.phoronix.com/scan.php?page=news_item&px=MTAyNTg

>>7
No reason to be so pessimistic. You're thinking of nVidia. AMD has been open sourcing their stuff since around 2008. There are open source drivers in the Linux kernel sources contributed by AMD for current Fusion platforms already.

And another thing. Any new language that comes out emphasizing concurrency, like say a new Haskell or Scala... if it isn't using OpenCL in its runtime, it's doing it wrong.

>>9
Yeah, sorry.

And Intel's Intel Many Integrated Core Architecture (MIC, aka Knight's Corner), is programmable with OpenCL. The hardware specs are being fully published.

http://en.wikipedia.org/wiki/Intel_MIC

The many-core concurrency revolution is here, and it's not through garbage like Haskell, Scala, or Clojure. It's through C and OpenCL.

>>12
and it's not through garbage like Haskell, Scala, or Clojure. It's through C and OpenCL.
C is fucking shit, and Haskell and Scala and Clojure are worse.

>>13
List processing is shit because the hardware will never be as efficient for it. Now I don't want to hear you say "b-but Sussman, what about Lisp machines!?" It will always be a more efficient use of the electrons and transistors when they are employed for bounded homogenous arrays. Why? Because that's how the Universe works! Someone needs to make a new compiled Lisp-like language that provides abstractions for grid-computing and that uses OpenCL in the backend.

>>14
I'm sure such a thing already exists, but I'm sort of working on one right now. It is easy enough to provide multi threaded implementations of the higher order functions, but to really do it like how it is done in OpenCL could be a challenge. LISP and all high level languages in general tend to have lots of high level objects that consists of a complicated structure of references, and your input needs to be in flat arrays to be processed using opencl. Unless it's really worth the trouble, I'd recommend just using openMP instead.

>>14
Lisp is actually perfect for this.  Think about it. The only three "reference types" are symbol/string, cons and lambda, and the two former are immutable.  It becomes trivial to declare types in a few places and use static analysis to determine the types of everything everywhere (if the deduction system fails, just add a few more type hints!).  And the compiler only has to deal with those three reference types that it understands perfectly.

I use PPL, ``faggot''

>>14
Challenge accepted. I'm inventing a Lisp oriented architecture. Come at me bro.

>>17
Microsoft's shit will never gain wide-scale use. PPL, DirectCompute, C++AMP. It's all shit. Microsoft is dying, and the sooner you get away from them, the better off you will be.

Even where they force it for the XBox Next/720, because game developers still have to write an OpenCL code path for the other consoles and platforms, it's smarter to invest time in building an OpenCL layer for the XBox that compiles down into DirectCompute shaders that can be reused on multiple different game projects, instead of spending that time on a separate engine path per project.

>>16

You can't pass nested structures to openCL, so this is a bit of a problem. You can however, pass in an array of data that references other parts of the data using array indeces. So maybe if you pass in the entire heap as one argument to every kernel, and represent all references as array indeces into the heap, then maybe it could work.

>>19
>Microsoft is dying, and the sooner you get away from them, the better off you will be.
Typical freeturd spreading FUD like he spreads shit over his face every time he loads GAHNOO shitware.

>>15
It doesn't exist, because the people who put together toy Lisp languages don't seem to understand how to write software that makes the most efficient use of common CPU hardware. OpenMP isn't really suited for GPUs, FPGAs or auxiliary CPU cores. OpenCL is. Many types of problems are better executed on in-order compute cores and GPUS/FPGAs with more FLOPs/watt, so there is a use case.

>>16
A Lisp-like could be perfect for it, but Common Lisp out of the box is horrible. You can't use linked-lists or other linked structures. It would need to be less imperative, at least on the GPU/FPGA side of things, and focus more on functional/flow-oriented/data-oriented programming where transforms on immutable data are executed in parallel and synchronization is performed via barriers on task dependencies. Any object orientation is out of the question.

Furthermore, the runtime for the language and how "objects" in the language are laid out in memory needs to be in Structure of Array order. Homogenous bounded arrays, not all grouped together in traditional structured or OOP fashion of Arrays of Structures. No pointers and cyclic references to other objects, but rather memory offsets into the homogenous arrays or hash-codes for open-addressed hash-table lookups.

Garbage collection is also out, upper bounds for all memory usage need to be known ahead of time (either compile time or as a function of the size of loaded assets/data at runtime), allocations are performed using fast linear allocators, and memory is released implicitly when tasks are finished executing and data goes out of scope.

It would need to be something like this, but with a Lisp-like syntax:

http://www.flowlang.net/p/flow-manifesto.html

>>22

Garbage collection is also out

Why? I mean sure, the garbage collector couldn't do anything while a kernel was running, but it could do collecting between kernel executions.

>>21
Look at you.  Just look at yourself.  Shameful.

In fact a copying collector could be implemented pretty easily and efficiently in a kernel.

Only shameful if he's not been paid at least to white knight for the poor little microsoft.

>>23
Because garbage collection relies on references and object nesting to determine what is garbage and what is still alive. You're thinking in terms of objects, and you can't do that for GPU/FPGA programming. You need to think in terms of linear buffers and homogenous arrays. You aren't writing functions that operate on single rinky-dink object, but rather functions that transform huge amounts of data of the same type. Think game programming, CAD/3D modeling rendering, computer vision, medical simulations, data mining, etc.

If you want to do rinky-dink "Hello World" programs or stdin/stdout stream processing, just use C or Common Lisp.

Implicit memory allocation and "collection" if you want to call it that is probably easier to implement than a general purpose garbage collector. It's similar to how stack allocation works in C or C++, but instead of a sequential/imperative order, stack frames go in and out of scope at common task dependency barriers.

>>24
He's probably one of those novice programmers who is stuck on Microsoft operating systems, using his Visual Basic or Visual C# language to write his half-broken programs. I bet he has never experienced the command line.

>>27
Yeah, but if you impose that restriction on the language one will be able to feel it. I'm sure it would be useful, and well suited for the applications you listed, but it would be a niche language. Once your application is outside of the niche, the language would no longer be useful for you. You would need a more general set of features to fall back on in the back ground to make it a general purpose langauge. There has to be something that it can offer that isn't already available with plain OpenCL and a set of bindings to your favorite langauge.

>>29
Just because it's not for "Hello World" applications or simple utilities doesn't mean it can't be mainstream.

See R for example.

http://www.r-project.org/

The continued search for a better general purpose programming language that is easy for stupid people to understand will be a fruitless endeavor. Things have already peaked. There isn't going to be anything really better than Lisp or D or Go or Scala, etc. Any improvements will be minute and incremental. And we can't expect hardware to help us here. We aren't going to get much faster clock cycles, and even if we do, we'll again find ourselves stuck once again. We're up against the fundamental limits of the Universe.

The real bleeding edge of computation isn't going to be anywhere near general purpose programming languages for humans and won't be ever again.

We have to fundamentally move beyond where we're currently at now to scale things up to run in parallel. We need to think about how data is physically situated in our hardware, about how far it has to travel to be transformed by a processor... close at hand from a cache, or do we have to load it in from disk or secondary storage? It matters, because it costs power and time just moving it from one location to another. We need to find ways to most efficiently work with our data in the real sense.

And we need to manage complexity in fundamentally different ways as well. Alan Kay has some good ideas here with parser combinators and PEGs, in which you build a bunch of DSLs that fit your abstractions elegantly using tools that make it very easy to do so, but also keep things tied to fundamentals: everything is data and functions that transform that data, nothing more.

None of that object-oriented crap, that stuff is a total mistake. Object Oriented Programming is Computational Marxism.

>>28
Cool assumptions. I actually have used GNU/Shitnux for a couple years. I have grown to hate it. I don't touch VB. I do work with C++ and C# extensively.

Skid detected

>>31
I do work with C++ and C# extensively.
I've been telling the FDA for years that extensive use of C++ and C# causes permanent brain damage, but still they refuse to listen to me.

>>30

It sounds like you'd be perfectly set with C and OpenCL, and I'm not sure what language you even want. You seem to want features and then claim that the features are a step in the wrong direction. If you want complete control over how everything works, then stick with C and OpenCL. I think it would be more productive to specify a high level specification of what you want and how it can be computed, and let a compiler create an optimal way of managing everything for you. This wont be easy for every application, and ultimately you'd sometimes have to use straight OpenCL and C to get the best performance, but there is probably something that can induce a decent model for most cases. Although even then, not every problem can be efficiently solved with a highly parallel algorithm. You wont necessarily be able to compete with an alternative implementation running on a multicore CPU, where more synchronization methods are possible. And then there are other forms of parallel computing, like many machines networked over a lan. The OpenCL model of shared memory becomes less relevant, and tools like Erlang start to look more suitable.

Marxism
Oh it's you again.

>>33
nice dubs.

>>30
Relevant:
http://gamesfromwithin.com/data-oriented-design
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Data%20Oriented%20Luddites]]
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
http://macton.smugmug.com/gallery/8936708_T6zQX#!i=593426709&k=ZX4pZ

>>33
It sounds like you'd be perfectly set with C and OpenCL
Exactly, which is what I'm already doing. It was someone else who said C is shit, not me. They obviously wanted a Lisp language instead.

>>36
C is undefined shit.

This just in today!

AMD and ARM have announced they will be fully open-sourcing their entire OpenCL stacks for Linux, and have formed the Heterogeneous System Architecture Foundation with Texas Instruments and MediaTek to promote heterogeneous computing.

http://www.phoronix.com/scan.php?page=news_item&px=MTEyMzQ
http://www.phoronix.com/image-viewer.php?id=0x2012&image=amd_fusion_hsa_lrg
http://hsafoundation.com/

>>38
I was already a AMD fan for their ATI support. This only increases my respect for them.

AMD's OpenCL implementation isn't shit either, it beats out Intel's OpenCL implementation running on Intel or AMD hardware.

http://www.phoronix.com/scan.php?page=article&item=amd_intel_openclsdk&num=3

>>36
oh, nevermind then. sorry.

>>34
thanks