Really breaking new ground here. What should FFmpeg have been written in? I can think of a few candidates, but I think they share a number of those "wonders".
> If you're a C programmer and somebody says like: I've that optimization that makes your program 3% faster you go: wow! Then you come and say: well, now I make it half as fast you go: w00t?! But then you remember that people actually use ruby to serve web pages.
I'd say this would be actually worth it for a far more secure FFmpeg.
It's been around since 2006, but I haven't really heard of anyone using it. I wonder why.
It never compiled on 64bit architectures, and to get it to compile with 4.0 or 4.1 (newer versions of gcc won't work) you need to fetch it from SVN (last commit is dated May 2009)... and obviously: no distribution still ship such an old version of the build tools... you'd need something like debian lenny, which does not even receive security updates anymore
This is like saying "my bulletproof vest will stop nearly every round fired at it". Too bad it only takes ONE...
But Modula-2 had Lilith to offer, while C had UNIX.
Compiler support across various platforms: are there compilers available and do they generate good code?
Mindshare: how big is the intersection of people who know the language and have the domain knowledge to contribute to the project?
Or are you perhaps just wishing that history had taken a different turn?
There'll be a HN topic A FFmpeg reimplementation in JavaScript soon enough ...
There is also Intel Lab's HRC (Haskell Research Compiler) that does have SIMD capabilities [2]. Unfortunately, there isn't a public release of HRC yet.
---
[1]: https://ghc.haskell.org/trac/ghc/wiki/SIMD
[2]: http://dorchard.wordpress.com/2013/10/14/automatic-simd-vect...
ISO/ANSI C also don't support SIMD, you have to go down to Assembly when writing portable code across C compilers.
also, I think you may be able to do reasonably well with icc and not much assembly
You don't need to work at the assembly level for this; you just need a language that can express vector operations in a way that doesn't require a compiler to solve the halting problem, and you need a compiler that knows how to compile such operations to SIMD.
Yes, ANSI C doesn't have such a construct, but GNU C (which I'd bet 95% of open-source code uses anyway) does.
(Plus x86's intrinsics are just plain ugly. It's easier to read asm.)
As for the architecture-independent SIMD in GNU C, it's something, but not quite flexible enough. Even C is really not a good enough language to consider implementing this in, because it has an overly-conservative memory model when it comes to char *, which aliases all other memory. For a library dedicated to parsing things which come in the form of bytestreams and 8-bit pixels, this means that most compiler optimizations are defeated right in the inner loops where you'd need them.
But restrict is only good in specific situations - if you have three pointers, and #2 can alias #1 but not #3, there's no way to express that.
It also tends to be used on function arguments, not at some higher up point of declaration. So when compilers inline the function and can see more global info about it, the restrict gets lost and optimization gets worse.
I think some kind of stronger 'typedef' would be better.
[1] http://msdn.microsoft.com/en-us/library/5ft82fed(v=vs.80).as...
map (uncurry (+)) (zip [1,2,3] [4,5,6])
The compiler needs to be able to see that the data conforms to all those restrictions (possibly more), and that's not a trivial thing to do.
Here's an example in Haskell: consider the case that the list of numbers was generated from a list of some other structure; something like "map x coordinates" to get all the X values from a list of X-Y-Z coordinates. For vectorization to work, those values need to be packed together in memory; however the structure isn't organized as such (at best, you'd have XYZXYZXYZ). That means a nontrivial memory copy, which will cost much more than the vectorization will gain you. So the structure needs to be reorganized, but then that might cause other pessimizations.