derf_

For those not familiar with Greg's work, this presentation on the testing he did for the Opus codec is informative: https://www.ietf.org/proceedings/82/slides/codec-4.pdf

Particularly slide 20.

The difference between copyright and patents is that as a property right, copyright has a clear boundary: you know whether you copied someone else's stuff [1]. You can infringe a patent without knowing of its existence, and even if you do know and actively try to work around it, the only reliable way to determine if you are successful is in an expensive lawsuit.

Imagine if you wanted to put an addition on your house and needed to file a multi-million dollar lawsuit that could stretch over a decade before you could determine whether it would cross your neighbor's property line.

[1] There's still some gray area around fair use, but the contrast with patents is night and day.

> How is this worse than starting a business without a patent?

The argument in the article is that if you don't have the resources to commercially exploit a patent yourself, then no one else will pay you for your invention, because a) the frictional costs in licensing from you are too high, especially when b) they can just steal the idea, since you are too poor to defend yourself in court.

That creates an inefficient market.

Personally, I think the effect of b) is smaller than implied, since an inventor could always sell the patent to a troll who can afford to defend it (though discounted by some large risk premium)... nevertheless I've heard of it happening.

The effect of a) is very real. Just consider any software product given away for free... even a requirement to count how many copies are distributed for the purposes of computing a royalty may be inimical to the business model.

That patch doesn't affect the x87 asm in sysdeps/x86_64/fpu/e_expl.S, though, does it? Good to hear it's fixed for some cases, though.

Don't forget to add in the fact that you could have been earning that non-zero salary potential for two years instead of paying tuition...

When I started my Ph.D., early on they ran the numbers with us. The increased starting salary from having a Ph.D. (probably somewhere in the $15...$20k range... I forget the exact number) will never make up for the four year head-start someone who stops at a Bachelor's degree gets on actually drawing a salary, once you discount to net present value (even when you factor in a graduate student's meager stipend).

That's good to hear.

I take it back, we did measure average case performance of expf() (though not expl()), and it was slower than exp():

16:12:48 < gmaxwell> ha. So, completely eliminating all the doubles made celt slower.

16:13:23 < gmaxwell> I'm guessing that this is because I used the C99 float versions of the math functions and they suck.

16:13:57 < gmaxwell> looks like 3% slower or so.

16:14:05 < gmaxwell> <3 GLIBC.

16:26:02 < gmaxwell> with float approx the no-doubles is .9% faster. Whoohoo. ;)

17:24:06 < derf> Yes. Don't use the float versions of libc functions, at least not on x86-64.

17:24:24 < Dark_Shikari> what the heck did they do ?

17:24:53 < derf> They reset the rounding modes on entrance and exit of expf(), for example, regardless of whether or not they're already correctly set up.

17:25:07 < derf> Apparently this is really slow.

17:25:32 < gmaxwell> derf: I was hoping that they'd be fixed by now.

"Float approx" refers to our custom polynomial approximation of exp(). Given that, I think it's safe to infer that expl() would also have been slower than exp() in the average case. That was in 2010, though. This appears to have been fixed for expf() in 2012 (which now uses SSE/AVX instead of x87 asm on x86-64), but not for expl().

See also the Firefox bug from 2011: https://bugzilla.mozilla.org/show_bug.cgi?id=648186

We didn't measure average case performance, but for worst-case performance the "orders of magnitude" comment is absolutely backed by measurement. See also my comment at https://news.ycombinator.com/item?id=8830667

In our case, we only needed about 12 bits of accuracy anyway, so we wound up writing our own implementation using polynomial approximations (which have the benefit of predictable running times regardless of the quality of your C library). The fact that you need to do this in any context where worst-case performance is a concern might be surprising to some people. It was to me before I read glibc's code.

In many contexts, the problem is not the absolute performance, but the variation in performance. For example, we want the Opus codec to be relatively insensitive to timing analysis, since Opus audio is often encrypted and transmitted over a network. Large variations represent an information leak that could be exploited by an external observer.

When we started looking at actual timings, we found that it was mostly pretty consistent, except for huge slowdowns in some frames. The cause? glibc's exp() slow path.

There's an x87 asm implementation for x86-32 in sysdeps/i386/fpu/e_exp.S [1]. For x86-64, it falls back to the generic C code for exp(), in sysdeps/ieee754/dbl-64/e_exp.c. The sad part is that there is x86-64 asm for a few variants (exp10l, exp2l, expf, expl), but since these are not C90, people tend to avoid them for more portable versions.

So, ironically, it can be orders of magnitude faster to compute a long-double expl() than a double-precision exp().

[1] Even the asm contains a lot of extra code to handle edge cases that Intel screwed up, like returning NaN for exp(+/- Inf).

Why would laws be sufficient? There are plenty of people who would like to do the same things the NSA would like to do who are not concerned with laws. As Schneier says, "today's top-secret NSA programs become tomorrow's PhD theses and the next day's hacker tools."

Changing economics by deploying more PFS ciphersuites and shifting to technology which requires active attacks instead of passive ones can give real, practical improvements in privacy, even against state actors.

You could also just modulate the lambda used in the trellis quantization so that it is less aggressive in smooth blocks, and more aggressive in textured blocks. It's not as good as being able to change the quantizer, but you can get somewhere around half the benefits of real activity masking by changing lambda alone.

Well, it's not just "git"... it's any of the tools people use to compare and collaborate on text files. Throw it in a Rietveld instance or Gerrit, and you can review changes and make comments like with any other code review. If you prefer just throwing it into kdiff3 or something, you can do that, too. If you like Word's "Track Changes", LyX has that (though that means everyone has to use LyX as their editor).

The point is that a simple text-based source format opens up the possibility for lots of different collaboration models that the Word software monoculture prevents.

The U.S. patent system makes it impossible to guarantee anything with respect to patent infringement. But how many royalty-free codecs does Xiph need to develop and deploy at scale [0-4], without anyone filing lawsuits, before people believe that success here is possible?

P.S., in case it's not clear, I've volunteered for the Xiph.Org Foundation for over a decade.

[0] https://en.wikipedia.org/wiki/Vorbis#Support

[1] https://en.wikipedia.org/wiki/List_of_hardware_and_software_...

[2] https://en.wikipedia.org/wiki/Speex#Applications

[3] https://en.wikipedia.org/wiki/Theora#Playback

[4] https://en.wikipedia.org/wiki/Opus_%28audio_codec%29#Support

Even for real-time use cases, the range of bitrates where (spatial) SVC provides an advantage over simulcast is relatively small, and it's not a big advantage. Plus, it's a patent minefield. I've also seen people argue that it has a computational complexity advantage over coding multiple streams, but a properly written simulcast encoder can share a bunch of the work between encodes as well (libvpx has an implementation of this for VP8, for example, for use in WebRTC).

Unlike OpenGL, OpenCL allows writes to arbitrary addresses computed by the OpenCL kernel. To be safely run on the web, you have to solve a very difficult validation problem to prove that an arbitrary kernel won't do bad things. I don't think anyone has adequately solved that problem. As stated at <https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30>, "The future for GPU compute in Firefox is ARB_compute_shader, which is now part of ES 3.1."

12:37:59 <+xiphmont> no, the lag is intentional.

12:38:11 <+xiphmont> it seems wrong... but exact tracking felt worse.

Bitrate peeling is not a design goal, no.

So that would be U.S. entities, then? Mt. Gox was headquartered in Japan.

In my case, a substantial amount of my work on Opus was done literally from my basement (sorry, I didn't have a garage).

I hear there are also about 4 and a half million homo sapiens there, though presumably they are an introduced species.

There are many other things that can go wrong long before this happens. Think joints, ligaments, tendons...

I say this as someone who once walked 100 km in a bit under 21 hours. I am not an athlete. When I was done my knees had swelled to the size of grapefruits and I could not bend my legs anymore.

Thanks.

Link to the full set (top of the page): https://people.xiph.org/~xiphmont/demo/

Can you file a bug? https://bugzilla.mozilla.org/enter_bug.cgi?product=Air%20Moz...

We certainly thought so (I was Thomas's mentor this summer).

Yes, I think anonymity in reviews is largely a myth, even in "double blind" reviews. For many topics, there are only a few research groups actively pursuing them, and you can often tell from what other work they cite, what datasets they use, etc., which lab it is. So identifying at least some of the authors is relatively easy. You might not get the exact grad student right, but you probably know their advisor.

Identifying reviewers is a little harder, but it's usually not difficult to make educated guesses unless they are, as you put it intentionally vague. Otherwise the other comments on this article about bad reviews from 'people from "a different camp" simply disliking a given approach' and the like would be impossible to justify.

If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-p...

In the absence of some forcing function, the trend is for it to get worse, not better.

Then why wouldn't they have a conversation with project managers for their company to pay them to be open source developers, instead of other people?