Emacs and LLDB

Posted Feb 16, 2015 14:13 UTC (Mon) by rsidd (subscriber, #2582)
In reply to: Emacs and LLDB by PaXTeam
Parent article: Emacs and LLDB

Apple deliberately switched to a compiler that yielded slower executables. I really don't know how I can say this more clearly..

Emacs and LLDB

Posted Feb 16, 2015 15:40 UTC (Mon) by PaXTeam (guest, #24616) [Link] (4 responses)

did they switch from gcc 4.6 to llvm 2.0? i didn't think so either. you entered the discussion about a 10-20% impact not mattering and showed no evidence for it. note that we're not talking about your pet projects but an entire operating system.

Emacs and LLDB

Posted Feb 16, 2015 15:49 UTC (Mon) by rsidd (subscriber, #2582) [Link] (3 responses)

1. You said they switched within the gcc 4.2 timeframe and claimed that at that time llvm outperformed gcc.
2. I pointed out benchmarks showing gcc 4.2 slightly outperforming llvm 2.8, which is a release that occurred four years later.
3. I pointed out that a fair comparison would be between gcc 4.2 and llvm 2.0
4. I said that if you were wrong about it being gcc 4.2, I am willing to benchmark any CPU-bound program of your choice on the relevant version of gcc and the relevant (current at that time) version of llvm (llvm-gcc or clang as the case may be).
5. I claimed that the benchmark would show gcc handily outperforming llvm.
6. I claim that Apple made the switch despite a clear performance loss, for other (excellent) reasons. I claim that a 20% performance loss in CPU-bound tasks does not matter if there are significant other advantages.

How much clearer can I be?

This is my last comment unless you follow up with a benchmark of your choice and the relevant gcc version.

Emacs and LLDB

Posted Feb 16, 2015 16:31 UTC (Mon) by PaXTeam (guest, #24616) [Link] (2 responses)

> You said they switched within the gcc 4.2 timeframe.

i never said that, but quote me back if you feel otherwise. what i did say was this:

> [...]the gcc they used at the time (4.2 and older, ones not under GPLv3)

there's some irony in that you talked about me not reading you carefully whereas it's clear that you misunderstood 'used [by Apple] at the time' as 'the current release of gcc at the time'. the two were quite different already exactly because Apple decided to stick with pre-GPLv3 versions of gcc. therefore the choice they had to make wasn't between gcc and clang versions du jour at all (which is what you've been trying to talk about).

Emacs and LLDB

Posted Feb 16, 2015 16:43 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

Ahh, understood you now. Apple stuck with a slow, outdated version of gcc for 4 years until llvm came up to speed (figuratively rather than literally), because later versions of gcc had the wrong licence. Apparently some things do matter more than speed!

(Note that several phoronix benchmarks don't compile on llvm 2.8, it wasn't yet good enough technically: speed wasn't the issue. Also, there's nothing in gpl3 that should have stopped Apple using it, other than feeding paranoia.)

Emacs and LLDB

Posted Feb 19, 2015 17:04 UTC (Thu) by dakas (guest, #88146) [Link]

GPLv3 comes with an automatic patent license grant. It's been put into the license explicitly to throw a monkey wrench into patent games. Now the GPLv2 only grants additional rights alleviating copyright. Its scope automatically is limited to anything in the same copyright realm. So if Apple adds a bit of code to GCC, the GPLv2 turns this particular bit of code into a non-proprietary item. Apple does not risk anything apart from the code they put into GCC explicitly.

Patents are an entirely different game: a patent license is not restricted to only the code you contribute, and the most silly and trivial thing might be worth billions in bargaining power.

So I disagree with "there's nothing in gpl3 that should have stopped Apple using it". With a sane technology patent situation, that might have been the case. But there is no sanity in patents, so avoiding the GPLv3 in order not be cut off from windfalls for trivialities makes sense.