| 1 |
On 23:24 Thu 17 Jul , Adam Stylinski wrote: |
| 2 |
> There are very few pitfalls, none of which I see as real killers. |
| 3 |
> These include: |
| 4 |
> |
| 5 |
> 1.) Closed source compiler: Yes this stands against what we believe, |
| 6 |
> and yes by closing their source they're protecting the trade secrets |
| 7 |
> of their architecture. It also could be more difficult to debug, |
| 8 |
> although that's highly unlikely, they have the idb (intel debugger) |
| 9 |
> which works very much like gdb. |
| 10 |
|
| 11 |
Doesn't really matter, although we could never move to it as the default |
| 12 |
without violating our social contract. |
| 13 |
|
| 14 |
> 2.) Linking issues: So far it's pretty versatile, but it doesn't |
| 15 |
> always cooperate with gcc compiled apps. It may be a good strategy to |
| 16 |
> make the troublesome apps which won't compile with ICC compile with |
| 17 |
> ICC. |
| 18 |
|
| 19 |
Pretty sure you didn't mean ICC twice here, but sure. |
| 20 |
|
| 21 |
> Pro's: |
| 22 |
> |
| 23 |
> 1.) Bloody fast machine code. Intel obfuscates their architecture but |
| 24 |
> they give back to the community as much as possible to make their |
| 25 |
> hardware marketable toward the open source sysadmin, developer, etc |
| 26 |
> etc. Their drivers are open and they develop for the kernel |
| 27 |
> constantly. This cooperation leads me to believe that they would |
| 28 |
> assist a team of developers in making 100% icc compatible code. |
| 29 |
|
| 30 |
OK. This involves upstream projects more than us, though. |
| 31 |
|
| 32 |
> 2.) Bloody fast compilation time. In my experience the compiler works |
| 33 |
> much faster even with heavy optimization. |
| 34 |
> |
| 35 |
> 3.) Takes full advantage of SSE enabled hardware. SIMD instructions |
| 36 |
> are quite useful, code is extremely vectorized. |
| 37 |
|
| 38 |
Sure, sure, speed is nice. |
| 39 |
|
| 40 |
> 4.) will project gentoo toward the power user more, helps the gentoo |
| 41 |
> image, and overall will make linux a more professional operating |
| 42 |
> system (and a quite competitive alternative to something like a |
| 43 |
> SPARC+Solaris configuration). |
| 44 |
|
| 45 |
I don't buy any parts of this argument, although the rest of your email |
| 46 |
is pretty good. |
| 47 |
|
| 48 |
> This would also make cluster farms and science application more |
| 49 |
> respectful toward the gentoo community. The academic and research |
| 50 |
> world already uses ICC to compile their apps for the sake of speed. |
| 51 |
> The interprocedural optimizations for both the fortran and c/c++ |
| 52 |
> compilers make it a must. |
| 53 |
|
| 54 |
Yes, ICC is nice. And people can already use it easily within Gentoo for |
| 55 |
performance-critical apps. |
| 56 |
|
| 57 |
> 5.) It's free, albeit a commercial product. As gentoo is entirely |
| 58 |
> non-profit, there is no restriction when it comes to licensing. The |
| 59 |
> binaries won't be sold for the intel-compiled livecd, and the compiler |
| 60 |
> itself with a fetch restriction allows the user to legally register |
| 61 |
> for their free non-commercial license. |
| 62 |
|
| 63 |
OK, so we can't sell icc-compiled software in our Gentoo store, so the |
| 64 |
releases would always remain built with gcc. |
| 65 |
|
| 66 |
-- |
| 67 |
Thanks, |
| 68 |
Donnie |
| 69 |
|
| 70 |
Donnie Berkholz |
| 71 |
Developer, Gentoo Linux |
| 72 |
Blog: http://dberkholz.wordpress.com |
Archives