3 ms·

I'm working on a media library at the moment and it doesn't look like it would be an option. The main reasons. *GC is a non-starter. An HD frame buffer is

by yaur 12y ago

I'm working on a media library at the moment and it doesn't look like it would be an option. The main reasons. *GC is a non-starter. An HD frame buffer is around 3MB, a 4K buffer is around 13MB. Letting a GC manage your buffers will lead to heap fragmentation and bring down 32-bit builds relatively quickly. *Similarly you don't want to copy these things unless you have to so a strategy where each filter is responsible for its own buffers will result in roughly a 3x factor in memory bandwidth. *All of the downstream software is written in C. So just to get it into GO I either need to do another memcpy or use unsafe stuff in order to deal with it nativly in Go. This along with the above means that I would be looking at 2GB/s of memory bandwidth per stream instead of 500MB/s for a 4K stream. *My upstream targets include software written in Python and C#. Go appears to assume that it owns main, which is obviously a problem.

jerf 12y ago
Go can pass around byte buffers without copying them... a core use case for its core functionality as a network server. The real problem you'd hit with frame processing in Go is that it doesn't give you access to SIMD, nor does it have a nice GPU connection for computation. I like Go, but I don't really consider myself an "advocate", and part of that is not overpromising to people. If you've got really heavy-duty computational needs, like in science or graphics, it's a bad choice right now, and I expect it to remain so for the forseeable future because it's not a core concern of the devs, and I'm pretty sure they'd view it as dilution of their goals and value proposition. (Correctly, I might add.)