• 感谢大家的支持。准备抽奖送3本图书。

    需要有github账号,然后到抽奖链接的issue回复,给出自己的幸运号即可。 截止时间暂定为12.31号。

    抽奖链接: https://github.com/3dgen/cppwasm-book/issues/4

  • 另外,我们针对 C/C++用户提供了一个开源的教程《 C/C++面向 WebAssembly 编程》: https://github.com/3dgen/cppwasm-book

    欢迎关注

  • #99楼 @luikore 忘了说一点了, Go的pkg变化不会导致间接依赖的pkg被重新编译. 如果你是用 stdafx.h 的机制, 那每次在 stdafx.h 改点代码之后, 编译时间会很痛苦吧.

  • #113楼 @astaxie 70000行只是说明每个源文件编译时都要展开很多重复的代码, 如果有很多源文件, 这是很浪费编译时间和硬盘空间的. include和模板都是编译器的速度杀手.

  • #99楼 @luikore

    70000 行是哪里来的 -__-

    1. include 的问题可以用 stdafx/pch 解决, 现在很多 C++ 编译器已经优化过 include 了, 还拿好多年前的状况来说事...
    2. 与其说 Go 减少 pkg 的依赖, 不如说 Go 的 pkg 比 C++ 少太多, 当引入的 pkg 达到相同数量级的时候问题还是会出现.
    3. C++ 在未定义的处理上更人性化, 打开 -Werror=unused 同样可以禁止定义未使用变量(不止是变量, 还有很细粒度的控制). 最终集成 build 打开就可以, 开发时那种限制就是恶心人. C++ 编译速度和链接速度是可以自己做主的, 如果想忽略掉链接期优化, 关闭编译器开关即可, 链接就快多了. 但是 Go 的设计决定就把需要链接期优化的人都一竿子打死了.
    4. C++ parser 的二义问题都已经解决了. Go 的语法哪里便于优化?

    70000+是VC2010的结果, VC2012已经是80000+了:

    cat helloworld.cc #include

    int main() { std::cout << "Hello, World!" << std::endl; return 0; }

    cl /E helloworld.cc >helloworld-cc.txt 用于 x86 的 Microsoft (R) C/C++ 优化编译器 17.00.60610.1 版版权所有(C) Microsoft Corporation。保留所有权利。

    helloworld.cc

    wc -l helloworld-cc.txt 84316 helloworld-cc.txt

    1. stdafx/pch 已经说明了 include 的问题, 只是在补救而已. 再说如果代码在不同模块之间, 你愿意每个源文件被 stdafx/pch fuck 一次吗?
    2. 你还没有理解我说的意思: 如果pkg在一定数量之后, C/C++的每个库绝对会被include多次, 而依赖是树形结构, 这个是指数的差别.
    3. 又是一个语言的问题, 要靠编译器私活帮忙的例子. 你说的方法是语言标准吗, VC用户怎么办? Go语言如果需要运行速度的话, 可以期待gccgo的版本(这个运行速度优先级是高于编译速度的).
    4. 在解决二义问题时浪费了编译时间没有?
  • GO 的性能真的是很惊人啊 at 2013年09月27日

    #71楼 @luikore gcc 的 o2/o3 差别不大, 有个别的 o3 还不如 o2 快.

  • GO 的性能真的是很惊人啊 at 2013年09月27日

    #22楼 @rasefon

    go比c慢10倍的场景并不少见,比如二叉树测试:

    你知道这个测试为什么Go比C慢10倍吗? 你看过2个语言的测试代码没有? 我是看过的. C语言是基于apr的pool实现, 而已还开启了openmp优化(这是标准C语言吗?). Go语言是基于GC(不可否认Go语言的GC性能确实还有优化的余地), 如果也改用pool实现Go的测试就和C持平(17和15的差异).

    各种实现的对比在: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees

    Pool的实现代码在: http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=go&id=6

    这个测试的性能很不公平, 因为C使用了apr_pool和openmp. 那如果用Go写个汇编或opencl的版本是不是也可以呢?

  • GO 的性能真的是很惊人啊 at 2013年09月27日

    #19楼 @luikore Go编译器的性能在2012年底已经和C很靠近(GCC测试10%差距). 但是, Go1.1和1.2在runtime和很多库的改进还是很大的(包含网络部分). LLVM是很厉害, 有些测试也可以甩GCC很多.

  • GO 的性能真的是很惊人啊 at 2013年09月27日

    #10楼 @luikore Go有些库的性能确实比不完全是C写的极端优化的库性能要慢很多. 但是, 拿这个来证明Go语言比C语言慢10倍就比较扯了.

  • #95楼 @bhuztez

    搞编译器的朋友表示动态语言理论极限会比静态语言快...

    动态语言和静态语言有区别?

    估计只有被伊莫金人聚能的码农才能写那种理论极限的编译器

Go Ruby!