Hacker News Reader

Comment by onan_barbarian | Hacker News Reader

I reached the same conclusion ("Go is boring") myself, but with a different flavor.

After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go.

I understand that not everyone is excited about SIMD or generic programming or writing code for 32768 GPGPU threads... but Go feels like a missed opportunity in these respects, solving the problems of the mid-1990s with aplomb (which is good).

It seems more like 'a better Java' - solid, but not genuinely breaking any new ground in a way that creates a single good reason to use it.

View on HN

To be fair, no programming language has really taken a first-party approach to those specific problems.

SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines.

The main problem is that SIMD and GPGPU (even hardware accelerated graphics, to a lesser extent) are bolt-ons; they're not a core part of every computer, which is why they don't usually form a core part of any programming language. At best languages might choose to integrate this functionality into the standard library, but i don't think it will ever come built-in for a general-purpose language (maybe for a domain-specific language?).

I've actually been attempting to write a GPGPU interface between Go and OpenCL[1], so it's certainly not impossible to do GPGPU or SIMD in Go (via cgo), but it would require writing your own 3rd-party libraries or making additions to the go runtime/compiler to develop a novel interface to this functionality like goroutines that can run on the GPU (a dream many people in the Go community share).

[1] https://bitbucket.org/genbattle/go-opencl

> To be fair, no programming language has really taken a first-party approach to those specific problems.

APL (and it's descendants J and K) has everything needed to do justice to SIMD/GPGPU. And it had them since the early 60s. I am not aware of an APL compiler that actually uses GPU or SIMD instructions, but one is possible, and wouldn't require any change to the base language.

Not surprisingly, this is because the idiomatic model is closer to the SIMD mindset than to the "standard" (algol/pascal/c/java/python/go) mindset, which is why it is unlikely to ever become popular.

reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4? it's not much of a bolt-on anymore. one of the causes of the lack of good programming models for SIMD is that autovectorization was supposed to generate SIMD code for every application, but autovectorization isn't actually that great for many (most?) applications. (plus naive developers generally write terrible code--if array of structures versus structure of arrays doesn't make sense to you, you're probably writing code that cannot be autovectorized)

the lack of a magic compiler bullet is infinitely more true as soon as you look at anything remotely like a GPU, which gets into other more complicated problems due to a distinct memory space.

if I were to add any features like that to Go, I'd probably look in the direction of generating ISPC ( http://ispc.github.com/ ) or ISPC-like output. no need to solve the distinct address space issue (which you cannot solve), you have work creation so you don't need to do crazy scheduling hoops like persistent launches on the GPU, and it performs very well on Intel processors for SIMD-friendly applications.

> reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4?

Yeah, and the Athlon64 (and Opteron) for AMD.

I don't think the issue of separate address spaces is unsolvable. As long as you have a type system powerful enough to forbid aliasing between the CPU and the GPU code, you can do it. (For example, Rust's type system can encode task-local data.)

SIMD is really a big omission if you do a low level language these days. A modern language should really have first class vector types. I'm talking about static sized small vectors that run on SIMD, e.g. 4 x float32 or 8 x uint8. Not something matlab-esque.

Something along the lines of OpenGL shading language, OpenCL C or relevant vector extensions in modern C compilers. With GCC and Clang vector extensions, SIMD programming is fairly nice. (NOTE: GCC 4.8/git version vector extensions emit bad scalar NEON assembly so you can't really use them if you target ARM).

One particular thing about SIMD coding is the shuffling instructions which are hard to express in normal programming language terms as the order of the shuffling has to be static. GCC and Clang both have a shuffling function that requires the parameters to be compile time constants. But I prefer GLSL/OpenCL shuffle syntax, like vec.xxyy or vec.wzyx or vec.s0s0s1s1, and combinations like (vec4)(vec1.xx, vec2.yy). Too bad this syntax is not available on Clang or GCC when doing normal CPU C code.

NEON's shuffling instructions are rather odd to deal with. An odd thing about them is that Clang's ARM intrinsics actually use __builtin_shufflevector to implement NEON shuffles like vrev.

You picked Go for the wrong reason then. Go is not about parallel programming, which SIMD and GPGPU programming is. Go is about concurrency and that is a completely different beast.

What Go is good for is a different thing. It is good for writing a webserver, which you won't really like to do in SIMD or on a GPGPU. The reason is that a webserver requires you to handle independent activity where things are inherently uncoordinated: while one client is connecting, the other is being sent data.

Vice versa, where Go is bad, is when you want to handle massive parallel computation where each computation is the same and you have to wait until all computation is done before you can continue. This means that you have a sequential program, you have to wait, but not a serial one, since all the computations could be executed on SIMD or a GPGPU in parallel.

I think "Go is boring" is a too simplistic conclusion.

Go creates a genuinly unique programming environment. If you come from a C++ background (like me) you might think the C++ solution will always be structurally superior.

But this is not true. It has a really radical take on OOP, actually realizing some of the most extreme takes on OO from the C++ community: no class inheritance, only interface inheritance. Using the inheritance syntax for non-interfaces ("classes") does inheritance by composition.

Regarding templates: C++ has the best (imperative) language support for templates. But it also shows where it can lead... (typedef typename...) Boost has actually become a playground for clean template implementations that look like nothing but a mess.

> C++ has the best (imperative) language support for templates

D's template support is far superior: static if, constraints, compile-time function execution, string mixins, opDispatch. These features make templates much more practical and more powerful.

Hey, I'm really interested in exploiting the GPU for GP programming, and also in how the SIMD can help you... Would you be willing to give me some examples of the most common/useful uses?

Image processing and machine vision is a big one. Part of the skeletal tracking algorithm for Kinect is implemented as a set of shaders on the Xbox's GPU.

That's just one example, but anything that involves image processing is a prime example of something that can be optimized for GPGPU.

EDIT: To add another couple of examples:

- Digital effects; rendering, etc. Digital effects studios like Weta Digital are using GPGPU for speeding up their photo-realistic rendering [1].

- Physics simulations for games; games can now move resource-heavy activities like physics simulation from the CPU to the GPU, not only freeing up CPU resources, but also increasing the number of particles, etc. that can be simulated (look for n-body simulations as an example).

[1] http://blogs.nvidia.com/2010/01/nvidia-collaborates-with-wet...

Reply on news.ycombinator.com