亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: ［zz］高性能Linux Kernel項目—LinuxDNA ［性能真的提高 40%？］ [打印本頁]

作者: prolj 時間: 2009-02-28 13:50
標題: ［zz］高性能Linux Kernel項目—LinuxDNA ［性能真的提高 40%？］
http://linux.solidot.org/article ... 313201&from=rss
旨在提供高Linux kernel性能的項目LinuxDNA，本月初成功實現(xiàn)用Intel C/C++編譯器(ICC)編譯了Linux kernel 2.6.22，不僅沒有編譯錯誤，而且完全可充當一個完整Linux系統(tǒng)的核心，開發(fā)者使用的Linux系統(tǒng)是基于Gentoo Linux。早期研究發(fā)現(xiàn)，用ICC編譯Linux內(nèi)核，在性能上可以提升40%。開發(fā)者以前使用的是ICC 8，目前已換到10.1和11版本。該項目的負責人Thaidog稱：“ 編譯一個新內(nèi)核的所有指示都已公布在網(wǎng)站（雖然針對的是Gentoo，但其它任何發(fā)行版都適用）。任何有編譯內(nèi)核能力的人都可輕松完成�！彼硎鞠Ｍ芫S護一個與當前Linux內(nèi)核并存的kernel源�，F(xiàn)在的新內(nèi)核對應的是2.6.22，因為.22版之后內(nèi)核發(fā)生了一些變動，使得編譯的難度加大了，但并非是不可能的。

40% 啊

看來 GCC 改進空間很大啊

的確有改進 GCC 寄存器分配這么個項目

作者: chenyx 時間: 2009-02-28 13:55
提高40%,的確很強

作者: cjaizss 時間: 2009-02-28 17:51
說實在的,我并不明白他的"性能提高40%"是什么意思

作者: jqbsx 時間: 2009-02-28 21:41
just info:

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://www.coyotegulch.com/reviews/linux_compilers/index.html (new)
http://www.coyotegulch.com/revie ... tel_gcc_bench2.html (old)

http://www.linuxjournal.com/cont ... x-intel-cc-compiler
(40% is mentioned here)

作者: prolj 時間: 2009-02-28 22:28

原帖由 jqbsx 于 2009-2-28 21:41 發(fā)表
just info:

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://www.coyotegulch.com/reviews/linux_compilers/index.html (new)
http://www.coyotegulch.com/reviews/intel_comp/intel_gcc ...

其實這個意義不是很大，因為你跑的 testcase 不一樣得分也是不一樣的。
客觀的說，在 x86 上， ICC 做的很好（不過有人和 VS 比說 VS 編譯出來的代碼效率更高）， GCC的確有很大的改進空間（每個 Arch 都是，寫出來高水平的 md 不容易，我現(xiàn)在體會到了），有人的文章說 CSDN 上說 ICC 將會取代 GCC 我就找啊，沒找到，可能么？不記得 ORC 了？ FSF 不買帳誰都沒轍！這個只能說 ICC 某些方面做的很好，然后 GCC 的開發(fā)人員去趕緊追趕。
不否認我也使用 OpenSolaris 去跑 SUN cc 了，可是在 OpenSolaris 上連 GCC 4 都無法編譯（也許可以，太麻煩了）我就放棄了，意義不大，5 年之后 SUN cc 和 ICC 還有那個 ORC 對 GCC 還會有多少優(yōu)勢？10 年之后還會誰還會存在？

作者: OneThird 時間: 2009-02-28 22:38
據(jù)說使用GNU hash的工具鏈也能很大程度的提升性能。

作者: prolj 時間: 2009-03-01 20:18
標題: 回復 #6 OneThird 的帖子
Ubuntu 使用了 GNU hash，別的我就不關(guān)心了。
binutils 我還是算了，僅僅可以 port 就算了，不打算深究了。

作者: albcamus 時間: 2009-03-02 12:27
標題: 回復 #5 prolj 的帖子
> 其實這個意義不是很大，因為你跑的 testcase 不一樣得分也是不一樣的。

對，得看什么樣的benchmark

>客觀的說，在 x86 上， ICC 做的很好（不過有人和 VS 比說 VS 編譯出來的代碼效率更高）， GCC的確有很大的改進空間（每個 Arch 都是，寫出來高水平的 md 不容易，我現(xiàn)在體會到了）

icc估計更多microarchitecture 級別的優(yōu)化，而不是通用的優(yōu)化。 Intel的icc開發(fā)工程師也有很多給gcc的x86 backend提補丁的

>不否認我也使用 OpenSolaris 去跑 SUN cc 了，可是在 OpenSolaris 上連 GCC 4 都無法編譯（也許可以，太麻煩了）我就放棄了，意義不大，5 年之后 SUN cc 和 ICC 還有那個 ORC 對 GCC 還會有多少優(yōu)勢？10 年之后還會誰還會存在？

opensolarsi上編譯gcc不麻煩，我就在用gcc 4.3.1呢。我的筆記，僅供參考：

44) 在Solaris/x86 上編譯gcc

(注意，只針對4.0以及更新的gcc)

準備:

-> 安裝libintl， sunfreeware上有；
-> 安裝libmpfr和libgmp，用blastwave安裝即可；

配置：

$ gtar jvxf gcc-4.3.1.tar.bz2
$ cd gcc-4.3.1
$ mkdir src
$ mv * src/
$ mkdir obj/ dst/
$ cd obj/

$ ../src/configure --prefix=/export/home/soft/gcc-4.3.1/dst/ --with-gnu-as \
--with-as=/usr/sfw/bin/gas --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-shared --enable-languages=c,c++ --with-gmp=/opt/csw/ --with-mpfr=/opt/csw/

/* 你可以直接：
   *
   * $ gmake
   * 來編譯gcc；也可以：
   *
   * $ make bootstrap
   * 讓gcc把編譯過程分成3個stage，每一個stage的結(jié)果用來編譯下一個stage，這是
   * 一個bootstraping的過程。如果硬盤空間不足，還想bootstrap，那就：
   *
   * $ gmake bootstrap-lean
   */
$ gmake bootstrap

/*{{{*/ 如果出現(xiàn)錯誤:
libcpp/下編譯時找不到libintl_gettext等符號:
$ cd libcpp/
$ vi Makefile 給CFLAGS加上-L/usr/local/lib -lintl
$ gmake

//繼續(xù)
$ cd ..
$ gmake

其他目錄出現(xiàn)這個錯誤也是一樣的辦法。
/*}}}*/

[FYI] Solaris上是否可以用gcc和GNU ld來編譯、連接程序？ gcc官方文檔推薦使用SUN的link-editor，
      亦即/usr/ccs/bin/ld，而不是GNU ld。

   網(wǎng)上有人說，如果編譯gcc時指定了--with-gnu-ld，那就可以把GNU ld的路徑export到環(huán)境變量
   GCC_EXEC_PREFIX中去，gcc就可以使用GNU ld了。 (該方法尚待驗證)

作者: cjaizss 時間: 2009-03-02 12:38

原帖由 albcamus 于 2009-3-2 12:27 發(fā)表
> 其實這個意義不是很大，因為你跑的 testcase 不一樣得分也是不一樣的。

對，得看什么樣的benchmark

>客觀的說，在 x86 上， ICC 做的很好（不過有人和 VS 比說 VS 編譯出來的代碼效率更高）， GCC的確有 ...

ICC是專用編譯器，對于專門硬件的優(yōu)化肯定是講究的多的，專用和通用的差別還是很大的

作者: albcamus 時間: 2009-03-02 12:42

原帖由 cjaizss 于 2009-3-2 12:38 發(fā)表

ICC是專用編譯器，對于專門硬件的優(yōu)化肯定是講究的多的，專用和通用的差別還是很大的

而且， icc之所以可以編譯某些特定版本的kernel，也是因為它對gcc做了選項和語法上的全面兼容。

即使這樣，也不是每個kernel版本都可以用icc編譯的。

作者: cjaizss 時間: 2009-03-02 12:56

原帖由 albcamus 于 2009-3-2 12:42 發(fā)表

而且， icc之所以可以編譯某些特定版本的kernel，也是因為它對gcc做了選項和語法上的全面兼容。

即使這樣，也不是每個kernel版本都可以用icc編譯的。

不過我懷疑不是icc去支持gcc語法、選項，而是去修改代碼，包括C源碼、makefile。

作者: prolj 時間: 2009-03-02 13:01

原帖由 albcamus 于 2009-3-2 12:27 發(fā)表
icc估計更多microarchitecture 級別的優(yōu)化，而不是通用的優(yōu)化。 Intel的icc開發(fā)工程師也有很多給gcc的x86 backend提補丁的

opensolarsi上編譯gcc不麻煩，我就在用gcc 4.3.1呢。我的筆記，僅供參考：
44) 在Solaris/x86 上編譯gcc
(注意，只針對4.0以及更新的gcc)
準備:

恩，這個我準備好好看看 intel 的那一卷優(yōu)化手冊。
我就是編譯 libmpfr 和 libgmp 的時候出錯了，沒心思找那個原因。那個軟件管理器里面沒發(fā)現(xiàn)我才編譯的，算了不關(guān)心了， KUbuntu 非常好用， Solaris 那優(yōu)秀的 Kernel 和 Dtrace 對我一點吸引力都沒有。
想跟你問一下，那個 OpenSolaris 的 ISO 上是 x86 和 x64 的內(nèi)核都有，那么我裝在 x64 上的時候，內(nèi)核是 x64 的， app 呢？ SUN 這個 x86 的概念讓我很漿糊。它在一個 ISO 里面有兩套內(nèi)核，不會也有兩套 app 吧？
btw ，你現(xiàn)在在寫東西？看你有好多筆記。
btw btw ，那個 md 文件的最詳細描述在 internals 里面。

作者: prolj 時間: 2009-03-02 13:03
標題: 回復 #11 cjaizss 的帖子
icc 是購買的一個小公司的前端，好像還有幾個商業(yè)編譯器也都是買的那一家的，的確是號稱“全面兼容 GCC ”當然后端兼容靠他們自己，那個賣前端的公司只能兼容那些 BT 的 GNU 擴展

據(jù)說有 GNU/Linux distro 用 ICC 編譯的，但是我用過之后覺得一點都不快，反而很慢，這個不是說 ICC 不好，想必有其他原因。

[ 本帖最后由 prolj 于 2009-3-2 13:18 編輯 ]

作者: albcamus 時間: 2009-03-02 14:02
標題: 回復 #12 prolj 的帖子
幾年前就記筆記了，總計有：

linux：

kernel

tips

programming

arch

acpi

hardware

english

solaris tips

solaris kernel

$ wc -l *
  1372 linux_acpi.txt
  2633 linux_arch.txt
420 linux_english.txt
572 linux_hardware.txt
  6902 linux_kernel.txt
  3150 linux_programming.txt
  6994 linux_tips.txt
806 solaris_kernel.txt
403 solaris_mdb.txt
  2496 solaris_tips.txt
25748 total

作者: system888net 時間: 2009-03-02 14:52
關(guān)注ls各位大拿的討論.

作者: prolj 時間: 2009-03-02 15:33

原帖由 albcamus 于 2009-3-2 14:02 發(fā)表
幾年前就記筆記了，總計有：

linux：

kernel

tips

programming

arch

acpi

hardware

english

solaris tips

solaris kernel

$ wc -l *
1372 linux_acpi.txt
2633 linux_ ...

提供匿名 svn 訪問不？我們都學習學習你的積累

作者: albcamus 時間: 2009-03-02 23:05
標題: 回復 #16 prolj 的帖子
不夠丟人的……

作者: emmoblin 時間: 2009-03-03 00:14
如期說改進gcc還不如就用集群編譯來的更容易。提高可以更大。
對于一般用戶，就算編譯慢點也是無所謂的

作者: albcamus 時間: 2009-03-03 00:39
標題: 回復 #18 emmoblin 的帖子
這里說的不是編譯速度，而是編譯出來的結(jié)果，運行的速度。

作者: prolj 時間: 2009-03-03 00:46

原帖由 emmoblin 于 2009-3-3 00:14 發(fā)表
如期說改進gcc還不如就用集群編譯來的更容易。提高可以更大。
對于一般用戶，就算編譯慢點也是無所謂的

有一個叫 distcc 的東西，但是對代碼質(zhì)量一點提高都沒有
改進 GCC 不僅僅是提高編譯速度，看現(xiàn)在的開發(fā)分支吧
Active Development Branches
General Infrastructure

var-tracking-assignments-branch
This branch aims at improving debug information by annotating assignments early in the compilation, and carrying over such annotations throughout optimization passes and representations. This branch is maintained by Alexandre Oliva. This branch is now tracking GCC 4.4; a separate 4.3 branch was maintained for some time, but there are no plans to maintain it any further.
struct-reorg-branch
This branch is for the development of structure reorganization optimizations, including field reordering, structure splitting for trees. These optimizations are profile information driven. This is a subbranch of tree-profiling. This branch is being maintained by Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings, Mostafa Hagog.
autovect-branch
This branch is the successor to the lno-branch. The purpose of this branch is tree-level autovectorization work, and related work that the autovectorizer could use or benefit from (like data-dependence analysis, loop nest optimizations).
graphite-branch
The purpose of this branch is to develop an infrastructure for loop transforms using the polyhedral model.
lto
This branch aims to implement link-time optimization. Patches and discussion on this branch should be marked with the tag [lto] in the subject line.
boehms-gc
The goal of this branch is to test Boehm's GC feasibility as the garbage collector for GCC proper. This is a part of Google Summer of Code project, described in detail at http://gcc.gnu.org/wiki/Garbage_collection_tuning. The branch is maintained by Laurynas Biveinis.
ra-improvements
This branch aims to implement several improvements to the current register allocator. Examples include implenting a lower-triangular conflict matrix and register coalescing. It is hoped that these improvements will not only help the current allocator, but will be useful to the other register allocation projects such as RABLE and YARA. This branch will be merged with the dataflow-branch from time to time. The patches for this branch should be marked with the tag [ra-improvements] in the subject line. The branch is maintained by Peter Bergner.
ira
This branch contains the Integrated Register Allocator (IRA). It is based on work done on yara-branch. The latter is more of a research branch because one of its goals (removing reload) is too remote. The ira branch is focused to prepare some code for GCC mainline, hopefully in time for GCC 4.4. IRA still uses reload; it is called integrated because register coalescing and register live range splitting are done on-the-fly during coloring. The branch is maintained by Vladimir Makarov < vmakarov@redhat.com> and will be merged with mainline from time to time. Patches will be marked with the tag [ira] in the subject line.
ira-merge
This branch contains bug fixes for the Integrated Register Allocator (IRA). It is branched from trunk at revision 139590 when IRA was merged into trunk. It is used to track IRA related regressions. Only IRA fixes from trunk will be applied to this branch. Its goal is there should be no "make check" and performance regressions against trunk at revision 139589. The branch is maintained by H.J. Lu <hjl.tools@gmail.com> and Vladimir Makarov < vmakarov@redhat.com>.
sel-sched-branch
This branch contains the implementation of the selective scheduling approach. The goal of the branch is to provide more aggressive scheduler implementation with support for instruction cloning, register renaming, and forward substitution. The branch is maintained by Andrey Belevantsev <abel@ispras.ru> and Maxim Kuvyrkov < mkuvyrkov@ispras.ru> and will be regularly merged with mainline. Patches will be marked with the tag [sel-sched] in the subject line.
incremental-compiler
This branch contains change to turn GCC into an incremental compiler. The branch is maintained by Tom Tromey tromey@redhat.com. Patches for this branch should be marked with the tag [incremental] in the subject line.
gc-improv
This branch is for the development of garbage collector improvements. It is the successor to the boehm-gc branch, but without integration with Boehm's GC. The branch is maintained by Laurynas Biveinis.
milepost-branch
This branch is for GCC developments done in the Milepost project. (http://www.milepost.eu). The branch is maintained by Mircea Namolaru namolaru@il.ibm.com. Patches should be marked with the tag [mpost] in the subject line.
melt-branch
This branch is for a Middle End Lisp Translator branch, including both the plugin Lisp-like facility and static analyzers developped with it. This branch is maintained by Basile Starynkevitch basile@starynkevitch.net. Use the [MELT] tag for patches.
var-mappings-branch
This branch is for improving debug information based on tracking multiple variables per computed value. The branch is maintained by Richard Guenther and Michael Matz. Patches should be marked with the tag [varmap] in the subject line.
stack
This branch contains a new stack alignment framework to automatically align stack for local variables with alignment requirement. The branch is maintained by H.J. Lu <hjl.tools@gmail.com>, Joey Ye <joey.ye@intel.com> and Xuepeng Guo <xuepeng.guo@intel.com>. Patches should be marked with the tag [stack] in the subject line.
mem-ref
This branch is for lowering the GIMPLE IL for memory accesses to a flat representation. See the GCC wiki for a more detailed project description. The branch is maintained by Richard Guenther. Patches should be marked with the tag [mem-ref] in the subject line.
gcc-in-cxx
This branch is for converting GCC to be written in C++. Patches should be marked with the tag [gcc-in-cxx] in the subject line. This branch operates under the general GCC maintainership rules, except that any non-algorithmic maintainer is additionally permitted to approve changes which permit compilation with C++. The branch is maintained by Ian Lance Taylor.
thread-annotations
This branch contains the implementation of thread safety annotations and analysis (http://gcc.gnu.org/wiki/ThreadSafetyAnnotation). The branch is maintained by Le-Chun Wu. Patches and discussion on this branch should be marked with the tag [thread-annotations] in the subject line.
rtl-fud-branch
This branch is for the development of factored use-def chains as an SSA form for RTL. Patches should be marked with the tag [rtl-fud] in the subject line. The branch is maintained by Steven Bosscher and Kenneth Zadeck.
alias-improvements
This branch is for fixing the optimizers to efficiently work with a single alias symbol and for stripping the operand scanner, data-structures and alias computation according to this simplification. Patches should be marked with the tag [alias] in the subject line. The branch is maintained by Richard Guenther.
transactional-memory
This branch is for the development of transactional memory support for gcc. Patches for this branch should be marked [trans-mem] in the subject line. The branch is maintained by Richard Henderson.
c-4_5-branch
This branch is for C standards conformance improvements for GCC 4.5. Patches for this branch should be marked [4.5 C] in the subject line. The branch is maintained by Joseph Myers.
named-addr-spaces-branch
This branch is the development branch to add named address space support for architectures that have multiple address spaces. The CELL/spu architecture adds an __ea keyword to describe extended memory in the host chip address space instead of the local CELL/spu address space. The branch was created by Ben Elliston, and is now maintained by Michael Meissner.
dwarf4
This branch is for support of DWARF-4 features. DWARF-4 is currently under development, so changes on this branch will remain experimental until Version 4 is officially finalized.
plugins
This branch adds plugin functionality to GCC. See the plugins wiki page for details.

作者: ericqchem 時間: 2009-03-03 12:33

原帖由 prolj 于 2009-2-28 22:28 發(fā)表

意義不大，5 年之后 SUN cc 和 ICC 還有那個 ORC 對 GCC 還會有多少優(yōu)勢？10 年之后還會誰還會存在？

10年后誰會存在？gcc會，intel,pgi,absoft,pathscale,xlc,acc, sun cc都會，其實各種編譯器主要應用在科學計算領(lǐng)域，只是icc兼容性太好了，所以現(xiàn)在有人用它編譯通用軟件。
不可否認gcc編譯科學計算代碼性能是最濫的。只有像龍芯集群那樣的沒有專用編譯器的才會用。一般的hpc機群沒有不買商業(yè)編譯器的（當然也有用D版的,呵呵）。

作者: prolj 時間: 2009-03-03 12:50

原帖由 ericqchem 于 2009-3-3 12:33 發(fā)表
10年后誰會存在？gcc會，intel,pgi,absoft,pathscale,xlc,acc, sun cc都會，其實各種編譯器主要應用在科學計算領(lǐng)域，只是icc兼容性太好了，所以現(xiàn)在有人用它編譯通用軟件。
不可否認gcc編譯科學計算代碼性能是最濫的。只有像龍芯集群那樣的沒有專用編譯器的才會用。一般的hpc機群沒有不買商業(yè)編譯器的（當然也有用D版的,呵呵）。

absoft沒有聽說過，孤陋寡聞，小白了，呵呵。 IBM 的 xlc 肯定是有保障的， HP 的 acc ？ HP 手里死掉的東西還少么？ acc 很強么？何況這種拿不到代碼編譯器對我這樣的愛好者有啥意義？就算拿到了代碼，連 Linux 內(nèi)核都編譯不了有什么吸引力？搞一個 HPC 很容易，因為指標單一，你搞一個通用的試試看？軟件匱乏就沒人用，我是用 PC ，當然只考慮我這點需求，相信絕大多數(shù)人都和我一樣是使用 PC ， HPC 對我們來說都是買不起的，呵呵。
不可否認目前 gcc 編譯科學計算代碼性能是比較濫的。 hpc 機群買得起商業(yè)編譯器（盜版也是他們的事情）。龍芯？不了解，不談這個。
科學計算市場很大么？非主流很好玩兒么？科學計算也是 Fortran 為主吧？ GFortran 是挺差勁的，連 PGI 都不如。這是目前的現(xiàn)狀，5年之后呢？10年之后呢？現(xiàn)在我還什么都不敢說，不過這讓我做了一個決定。

[ 本帖最后由 prolj 于 2009-3-3 13:00 編輯 ]

作者: xiegang112 時間: 2009-03-03 12:57
標題: 回復 #1 prolj 的帖子
Sun的cc和intel的icc評測下來，性能都比gcc強。這也可能它們都為專門的平臺做了優(yōu)化有關(guān)。

作者: system888net 時間: 2009-03-03 23:51

原帖由 emmoblin 于 2009-3-3 00:14 發(fā)表
如期說改進gcc還不如就用集群編譯來的更容易。提高可以更大。
對于一般用戶，就算編譯慢點也是無所謂的

原帖由 albcamus 于 2009-3-3 00:39 發(fā)表
這里說的不是編譯速度，而是編譯出來的結(jié)果，運行的速度。

大拿們說了兩個方面的東西:
1. 并行編譯,提高了編譯的速度.
2. 編譯出能并行執(zhí)行的程序,在多節(jié)點的環(huán)境下可以有效的提高程序的執(zhí)行性能.

[ 本帖最后由 system888net 于 2009-3-3 23:52 編輯 ]

作者: system888net 時間: 2009-03-03 23:54
標題: 回復 #24 system888net 的帖子
而且這里都牽扯到粒度和分解模式的問題.

作者: mik 時間: 2009-03-03 23:59
所謂的 Linux DNA 項目就是使用 ICC 編譯 linux kernel ???

作者: mik 時間: 2009-03-04 00:04
icc 編譯器并沒有什么好吹捧的

只不過是 intel 在 c/c++ 編譯中生成非通用編譯器（如 gcc）中不會使用的特定指令而已，一般是些 SSEx 指令。

如果，在 gcc 中使用嵌入?yún)R編的形式使用這些特定指令，效果是一樣的。

作者: prolj 時間: 2009-03-04 03:54

原帖由 mik 于 2009-3-4 00:04 發(fā)表
icc 編譯器并沒有什么好吹捧的

只不過是 intel 在 c/c++ 編譯中生成非通用編譯器（如 gcc）中不會使用的特定指令而已，一般是些 SSEx 指令。

如果，在 gcc 中使用嵌入?yún)R編的形式使用這些特定指令，效果是 ...

正是如此！我了解了一下 ORC 的 port ，覺得和手工生成代碼沒什么區(qū)別。 ICC 優(yōu)于 GCC 的地方主要是循環(huán)翻譯成 SSE 。而沒有說一種優(yōu)化算法可以在一種編譯器上實現(xiàn)卻無法應用在另一個編譯器上。

作者: BigMonkey 時間: 2009-03-04 10:05
gcc的性能優(yōu)化參數(shù)有不少，例如
-marh
-mcpu
-m 64-bit
等等，請問測試的時候用了么？

以前聽Intel的人說過，如果GCC選擇合適的編譯參數(shù)，那么ICC的編譯出程序的性能優(yōu)勢并不大(<10%)。

作者: cjaizss 時間: 2009-03-04 10:21

原帖由 BigMonkey 于 2009-3-4 10:05 發(fā)表
gcc的性能優(yōu)化參數(shù)有不少，例如
-marh
-mcpu
-m 64-bit
等等，請問測試的時候用了么？

以前聽Intel的人說過，如果GCC選擇合適的編譯參數(shù)，那么ICC的編譯出程序的性能優(yōu)勢并不大(

這倒也是,gcc還有那么多的編譯參數(shù),仔細比對的人可能不多。

作者: Magicloud 時間: 2009-03-04 11:08
一般gentoo的編譯參數(shù)都比較優(yōu)化，如果icc依然強勁，那只能是再次證明gcc有多爛。
不要說開源、兼容……之類的狗屁，只是把高級代碼編譯成機器碼，不能發(fā)揮硬件應有性能的叫教學編譯器！
按樓上諸位的邏輯，I和A花心思作那些sse之類的功能都是給科學計算用？因為我做普通用途，因為未來我可能改用非x86架構(gòu)，所以我就沒資格發(fā)揮硬件應有性能？而很明顯的，這個錯誤的原因不在于那些可憐的c程序員。

作者: prolj 時間: 2009-03-04 11:26

原帖由 Magicloud 于 2009-3-4 11:08 發(fā)表
一般gentoo的編譯參數(shù)都比較優(yōu)化，如果icc依然強勁，那只能是再次證明gcc有多爛。
不要說開源、兼容……之類的狗屁，只是把高級代碼編譯成機器碼，不能發(fā)揮硬件應有性能的叫教學編譯器！
按樓上諸位的邏輯，I ...

你仔細看別人回帖了么？ Intel 的 compiler team 對這個我想比你我都熟悉吧？

原帖由 BigMonkey 于 2009-3-4 10:05 發(fā)表
gcc的性能優(yōu)化參數(shù)有不少，例如
-marh
-mcpu
-m 64-bit
等等，請問測試的時候用了么？

以前聽Intel的人說過，如果GCC選擇合適的編譯參數(shù)，那么ICC的編譯出程序的性能優(yōu)勢并不大(

你了解任何一個編譯器的后端么？
你知道 ORC 的效率比 GCC 好還是差么？你知道你所謂的“非教學”編譯器的代碼就一定很好？
你看過任何開源并且用于生產(chǎn)的編譯器么？
你看見 GCC i386 的 port 里面有 mmx.md 和 sse.md 了么？
你跑了測試了么？對于指針滿天飛的一般應用 GCC 比 ICC 差多少？
你知道怎么測寄存器壓力么？

作者: Stout 時間: 2009-03-04 14:12

作者: OraBSD 時間: 2009-03-04 22:08

各位達人真牛啊!長見識了.

作者: siseniao 時間: 2009-03-07 21:08
其實就是軟件和硬件結(jié)合的問題，當然在這方面硬件的制造商肯定有優(yōu)勢的，但是差距不會有40%那么夸張

作者: rawa9999 時間: 2009-03-08 14:03
GCC有多少種后端，ICC不過針對X86做了大量優(yōu)化，要是編譯mips上的代碼就不行了吧，我偏愛GCC，自由軟件的杰作。

作者: sharpshootor 時間: 2009-03-09 10:41
我好像有看過這個新聞，不是說內(nèi)核部份性能提高40%，整體提高4%到8%左右嗎

作者: prolj 時間: 2009-03-09 10:53

原帖由 rawa9999 于 2009-3-8 14:03 發(fā)表
GCC有多少種后端，ICC不過針對X86做了大量優(yōu)化，要是編譯mips上的代碼就不行了吧，我偏愛GCC，自由軟件的杰作。

如果 Intel 找個人作 MIPS 支持， ICC 很快就可以支持 MIPS ，只是 MIPS 對 Intel 來講是雞肋還是雞大腿呢？ Intel 曾經(jīng)生產(chǎn) ARM 的時候不知 ICC 支持 ARM 不，但是至少從 ICC 支持 x86 x64 和 IA64 上來看， port 決定不會比 GCC 復雜和繁瑣（GCC port 是我見過最繁瑣的）。
ICC 對 X86 的浮點優(yōu)化很好，而且充分利用了 MMX 和 SSE �？� Intel 的優(yōu)化手冊上，有好多針對芯片內(nèi)部的優(yōu)化，比如針對取指的優(yōu)化，針對解碼的優(yōu)化。這個正如 mik 所說，沒什么值得驕傲的，如果我是開源編譯器的 commiter 我也不會考慮去做那么細的針對某個芯片內(nèi)部的優(yōu)化，考慮一下我改進一個算法，所付出的勞動和所帶來的好處，還是在那里一個 cycle 一個 cycle 的有化芯片資源呢。
同樣， GCC 的 X86 后端改進一下比 ICC 不會差到哪里去。我有改進 X86 代碼生成質(zhì)量的計劃，只是還沒有確定去改進 LLVM 還是 GCC ，抑或二者都做。誰再說開源編譯器不行，用實際行動否定他。

作者: rawa9999 時間: 2009-03-09 19:22
針對一個處理器做好優(yōu)化絕對不是一件簡單的事情，java發(fā)展那末多年arm上在針對java字節(jié)碼有了優(yōu)化，自由軟件可能不如商業(yè)軟件做的細，但是技術(shù)上絕對沒問題，自由軟件是為理想而編程，某一方面可能遜色于商業(yè)軟件，但是整體上不會比商業(yè)軟件差，mips跟X86區(qū)別很大GCC能將一段源程序準確無誤的生成兩種平臺的目標代碼做的不比delphi差，甚至還好，除此之外還有眾多交叉編譯器�，F(xiàn)在軟件業(yè)已經(jīng)到了社會化大分工的時代，將來任何的商業(yè)保守軟件都會被無情淘汰，自由軟件絕對不是山寨版。

作者: system888net 時間: 2009-03-09 21:03
大家說的有道理.

作者: hansion3406 時間: 2012-07-26 03:14
回不回呢，考慮再三，還是不回了吧。

作者: justmao945 時間: 2012-09-04 23:12
ICC是收費的吧？這種重要的部件不開源是不會被廣泛用在linux上的？

作者: fly3ds 時間: 2013-10-04 15:35

prolj 發(fā)表于 2009-03-09 10:53
如果 Intel 找個人作 MIPS 支持， ICC 很快就可以支持 MIPS ，只是 MIPS 對 Intel 來講是雞肋還是雞大腿呢 ...

吹牛誰不會啊。你還有改進GCC生成X86代碼的計劃，那我還有飛向人馬座的計劃呢。要是這么容易改，早就有人改好了。

作者: fly3ds 時間: 2013-10-04 15:36

Magicloud 發(fā)表于 2009-03-04 11:08
一般gentoo的編譯參數(shù)都比較優(yōu)化，如果icc依然強勁，那只能是再次證明gcc有多爛。
不要說開源、兼容……之 ...

沒人求你用，不用趕緊滾蛋。

作者: fly3ds 時間: 2013-10-04 15:38

rawa9999 發(fā)表于 2009-03-08 14:03
GCC有多少種后端，ICC不過針對X86做了大量優(yōu)化，要是編譯mips上的代碼就不行了吧，我偏愛GCC，自由軟件的杰 ...

我以為ICC只能在X86機器上運行。在這文出現(xiàn)之前，我以為ICC只能在Windows上運行，沒想到還有Linux版本的，哈哈。

作者: fly3ds 時間: 2013-10-04 15:43

rawa9999 發(fā)表于 2009-03-09 19:22
針對一個處理器做好優(yōu)化絕對不是一件簡單的事情，java發(fā)展那末多年arm上在針對java字節(jié)碼有了優(yōu)化，自由軟件 ...

你也胡扯了。Delphi什么時候能”準確無誤的生成兩種平臺“的代碼？據(jù)我所知，Delphi只在Windows x86機器上出現(xiàn)過。Linux上的Delphi據(jù)說被稱為Ky***，就是沒人真的用過。

作者: fly3ds 時間: 2013-10-04 15:47
本帖最后由 fly3ds 于 2013-10-04 15:47 編輯

mik 發(fā)表于 2009-03-03 23:59
所謂的 Linux DNA 項目就是使用 ICC 編譯 linux kernel ???

其實，能編譯成功也算是個不小的奇跡。GCC在標準之外搞了很多自己的私貨，Linux里夾雜著gcc的私活，要用ICC編譯成功，肯定要做很多修改，是個不小的挑戰(zhàn)，起碼我是不敢想的。

作者: fly3ds 時間: 2013-10-04 15:50

cjaizss 發(fā)表于 2009-03-02 12:56
不過我懷疑不是icc去支持gcc語法、選項，而是去修改代碼，包括C源碼、makefile。

你是正確的，肯定是修改Linux核心代碼以便讓ICC編譯通過。怎么可能是修改ICC適應GCC語法選項，那還叫ICC嘛。

歡迎光臨 Chinaunix (http://72891.cn/)