News for hackers. Stuff that matters.
Re:“Land initial Rust MP4 parser and unit tests” by nitrogen on Thursday June 18, 2015 @10:50PM (#9742763)
A while back there was a blog post (I think by Dark Shikari) about the use of assembly in x264. I couldn't find it by searching, but basically the very best C versions of essential image processing algorithms were orders of magnitude slower than the hand-crafted assembly versions, especially with SIMD instructions.

To create a viable codec, a functional spec compiler would have to close that performance gap. Edit: it might be possible to create a set of SIMD algorithmic building blocks (e.g. like liboil[0]) that could be verified for correctness then incorporated into the compiler.

[0] https://wiki.freedesktop.org/liboil/

Re:“Land initial Rust MP4 parser and unit tests” by teacup50 on Thursday June 18, 2015 @11:18PM (#9742834)
There has been work on typed assembly that could also apply: http://research.microsoft.com/en-us/projects/talproj/
Re:“Land initial Rust MP4 parser and unit tests” by peteretep on Thursday June 18, 2015 @11:32PM (#9742881)
Conveniently computers are getting orders of magnitude faster and cheaper, while the software on them - by virtue of complexity - has an increasing attack surface.

I will happily trade a video player utilising 4% of my CPU power and with fewer potential vulnerabilities than one using 0.4%.

Re:“Land initial Rust MP4 parser and unit tests” by nitrogen on Friday June 19, 2015 @12:38AM (#9743028)
When it comes to video encoding, the tradeoff is often between encoding live video or not encoding live video.

I think there's also an important tradeoff to be made in how much of a carbon footprint we dedicate to software. I really don't think we should be trying to make software expand to consume all available resources. We have to be both efficient and secure.

Re:“Land initial Rust MP4 parser and unit tests” by Too on Friday June 19, 2015 @01:08AM (#9743101)
Even when you are on a mobile device constrained by battery?