都在讨论C，很少有C++

reiase

回复 53# walleeee


放弃吧，有钱去买个MAC，没钱装个虚拟机跑Ubuntu

walleeee

回复 59# 鬼谷子大师


根本就不是喜欢不喜欢的问题。

取中文名字，你不嫌登录的时候麻烦？是不是也要输入中文？

walleeee

回复 61# reiase


你只是考虑到了一面。cygwin并非是我不能用linux虚拟机这些而选的替代。我2个机器，开个linux还不简单么？只是我需要在win下使用linux工具，这个cygwin做得还行。如果仅仅要个linux独立环境，我装个colinux说不定比你虚拟机更方便。

walleeee

回复 60# reiase


你说的你仔细想过么？

第一个连接，我看都不想看。jit的确会让这些语言快很多，逼近不过是个欲望，什么叫逼近？差10倍算不算，差100倍算不算？
python的jit比java的如何？

第二个。你没看它们的代码？基本就是个套接字网络读写。这种东西比较在我看来，不过就是一个缓存，谁把这里处理得好，那战胜其他是显然的，一点不足奇怪。

IO是一大块，你通并而说太过笼统。不过即便就通并来说，就内存这个层面的io就比cpu速度低了不知道多少数量级，而这个层面的io，那个语言本身能避免？没有谁本省能避免。唯一的改进地方就是做缓存，比如前面那个什么说的pool。

什么叫现代C++的性能无非就靠泛型？
我不知道你在说些什么。

比如图像处理，正常的都用unsigned char

我更是不理解你要表达什么。你知道为什么用这个么？为什么不用char？是效率因素么？你别轻易答，不然后面会有很多人来吐槽你。

再比如数值计算，好些库直接用double

算了。你没理解。

如果只有一种类型，泛型的性能优势还在吗

算了，你根本就不理解。

性能始终是一个领域内部的问题，最终还是靠这个领域内部的方案来解决。

这个倒是说的不错。当然，你也等于说了一句白话。你把“性能”二字换成其他，比如“质量”，你觉得是不是依然很有道理。。。

reiase

回复 65# walleeee

那你所说的C++的性能优势是指什么呢？C++如何做到的呢？

你确实没看第一个例子，貌似pypy的numpy实现速度不输C，并且还可能快一点。说实话，基于JIT的运行时优化的吸引力还是很大的。比如可以针对运行时的CPU生成代码，或者针对输入图像的大小，生成一个优化的计算代码。运行时代码生成也有在库这个层面做的，例子是liboil。

第二个例子大概是处理http事物的，包含IO和调度。随便你怎么说吧，反正在大量请求下，C++也不是实现高性能Web服务器的唯一选择了。

图像处理就看情况了，对一般GUI和娱乐用图像，8位量化足够了。好吧，你是想说雷达，MRI什么的要用16位量化图像？貌似这些领域的研究所用库和一般图像处理所用库不同。看到过一个基于模版实现的图像处理库（MS的，opencv的库不超过20M，还自带个lapack），lib文件有六百M之多。当时忘记关心它是怎么对齐行到4字节的了。之前看过一个对blas库性能比较，boost库给出的blas实现（ublas）是性能最好的，超过了c和fortran的几个实现。你说为啥C++实现的blas库比c的更高效呢，难道不是因为泛型吗。不过现在还没找到办法让opencv或者numpy链接boost的blas实现。

walleeee

回复 66# reiase

那你所说的C++的性能优势是指什么呢？C++如何做到的呢？

你说呢？native不够么？我觉得c/c++以及其他编译型做到这些天经地义，没什么可奇。

貌似pypy的numpy实现速度不输C

pypy以及numpy这些我都大概看过，是有些效率，只是我持强烈的怀疑态度。什么叫不输c？都不输c了，那还不赶快大吹特吹，让c在这一领域速速消失。

说实话，基于JIT的运行时优化的吸引力还是很大的

你仔细看我的帖子了么？我没说它们没用，我甚至说了，它们的确有效。

比如可以针对运行时的CPU生成代码，或者针对输入图像的大小，生成一个优化的计算代码。运行时代码生成也有在库这个层面做的，例子是liboil

这些是想得美好，跟50年代号称，2000年就能实现完全的人工智能一样。现在都2012了。

C++也不是实现高性能Web服务器的唯一选择了

c++当然不是唯一。甚至现在大多著名的你说的web服务器也不是c++写的。我不知道你是否看明白了我的帖子，我再说什么你看懂了么？我也不觉得你这些是在反驳我，因为我从你回帖看出来你根本就没看懂我的意思。可能是我的表达不太适合。

图像处理就看情况了，对一般GUI和娱乐用图像，8位量化足够了

这里如上。我依然不觉得你看懂了。而且你这里和你自己之前的在我看来也是在表达其他，并不是为了支持你前面的论点。

看到过一个基于模版实现的图像处理库（MS的，opencv的库不超过20M，还自带个lapack），lib文件有六百M之多

基于模版的，怎么又来了lib？还600多m。

当时忘记关心它是怎么对齐行到4字节的了

怎么又扯到4字节对齐？

之前看过一个对blas库性能比较，boost库给出的blas实现（ublas）是性能最好的，超过了c和fortran的几个实现。

你这里中间毫无联系的又转到了blas库。你想表达什么？前后有逻辑关系么？

你说为啥C++实现的blas库比c的更高效呢，难道不是因为泛型吗

算了。你可能不知道模版可以编译时计算。所以你觉得都归到了泛型。
还有，你也不知道模版扩张之后的代码可以比C代码有更多的编译器优化机会。所以你也归到了泛型手里。
就像经常可以看到为什么c++的sort比c lib的qsort快这种问题。
ps,
boost那个是模版库。你用他编译的时候是不是特别慢？编译出来的执行文件特别大？你用spirit么？你编译起来很爽么？
你还觉得boost很好么？如果很好，为什么那么多sdk不赶快去捧boost臭脚？为什么google会对Boost保持强烈的观望态度？
ps，
知道PyUblas么？这个可能可以满足你。

reiase

回复 67# walleeee

你说呢？native不够么？我觉得c/c++以及其他编译型做到这些天经地义，没什么可奇。

native什么都不算，好不好。你在p4上的native代码，拿到core 2上还算不算不算native。有jit生成的native代码native吗？

pypy以及numpy这些我都大概看过，是有些效率，只是我持强烈的怀疑态度。什么叫不输c？都不输c了，那还不赶快大吹特吹，让c在这一领域速速消失。

我对jit还是比较看好的，比如一个循环。jit可以在N很小的时候做unroll，native代码只能跑死循环。unroll对效率的提升还是很高的。

这些是想得美好，跟50年代号称，2000年就能实现完全的人工智能一样。现在都2012了。

有些库的运行方式类似jit，先根据问题生成计算代码，再执行。比如很多正则表达式的实现。或者某些FFT计算库。

c++当然不是唯一。甚至现在大多著名的你说的web服务器也不是c++写的。我不知道你是否看明白了我的帖子，我再说什么你看懂了么？我也不觉得你这些是在反驳我，因为我从你回帖看出来你根本就没看懂我的意思。可能是我的表达不太适合。

让C++骄傲的高性能应用是哪些呢？非C++不可的高性能计算。我们不要中间换概念，你对非python，javascript这些非native代码的性能有疑问，我给你了一个例子。所以不用管web服务器是用C还是C++。

基于模版的，怎么又来了lib？还600多m。

这个我也不清楚，接手项目的时候，发现代码目录2个多G，里边放了两份这个库的拷贝，最大的就是一堆lib文件，dll文件反而很小。记得一份lib文件要600M，预编译头文件目录还800M。我对MS的开发环境不熟，还想问问你是怎么回事呢。

算了。你可能不知道模版可以编译时计算。所以你觉得都归到了泛型。

你是说元编程metaprogramming？我一直以为元编程是指Qt的metadata技术和Python的元编程。刚查了下，发现C++的元编程是指Template metaprogramming。这玩意儿是从函数式语言借来的吧，哥表示这个不新鲜。

还有，你也不知道模版扩张之后的代码可以比C代码有更多的编译器优化机会。所以你也归到了泛型手里。
就像经常可以看到为什么c++的sort比c lib的qsort快这种问题。

深深叹口气。C++就这么一个有点，哥咋能不知道。要不要我帮你补充上linkage code generation。

boost那个是模版库。你用他编译的时候是不是特别慢？编译出来的执行文件特别大？你用spirit么？你编译起来很爽么？
你还觉得boost很好么？如果很好，为什么那么多sdk不赶快去捧boost臭脚？为什么google会对Boost保持强烈的观望态度？

boost里大多数库都是head file only的，慢很正常。你不用跟我解释为啥慢，你也不要解释预编译头文件占磁盘。Window底下用起来省事的库没几个，VC里加lib文件的过程恶心死了。哥不太用C++，所以cppers内部矛盾哥不了解。

知道PyUblas么？这个可能可以满足你。

不知道，PyUblas可以链接到C库上去吗？用这玩意儿还不如用PyCUDA。

现在的cpper已经不承认C++是OO语言了，都认为C++是GP语言。“GP == 高性能”又不是我发明的。

OwnWaterloo

reiase 发表于 2012-04-20 17:20
回复 67# walleeee

native什么都不算，好不好。你在p4上的native代码，拿到core 2上还算不算不算native。有jit生成的native代码native吗？

jit: 同一source， 在p4上是p4的native， 在core 2上是core 2的native， 需要运行时编译。 效率且不说，至少运行时库得带一个编译器。
native: 也是同一source， 为什么就不能在p4上编译成p4的native， 在core 2上编译成core 2的native？ 运行前编译， 编译者需要编译器， 发布不需要连编译器一起发布。

walleeee

回复 68# reiase

native什么都不算，好不好。你在p4上的native代码，拿到core 2上还算不算不算native

你想说什么？你想走极端？你非要把p4的native拿去给core2，我还能说什么？你为什么不干脆搞个不能运行更靠谱，那个时候你觉得我们再谈效率有意思么？

有jit生成的native代码native吗？

你这是问句还是反问句？我正我看不懂你的意思。
我一直在强调，jit对一些脚本，比如你的python，的确有很大的性能提升，这个是可以拿出公正测评的。我也同意。
但是jit也就仅此而已了。

我对jit还是比较看好的，比如一个循环。jit可以在N很小的时候做unroll，native代码只能跑死循环

你似乎太小看那么多开发人员和那么多研究人员以及几十年的研究时间，这些对编译器技术的贡献，在你眼中居然敌不过jit的一个loop展开。唉。不知道他们听到了是想笑还是想哭。

unroll对效率的提升还是很高的。

这要看场合。unroll了的代码扩展也是弊病。所以这是一个权衡。说本质吧，就是时间和空间的权衡。但是目前大多是时候时间显得要比空间重要，因为空间可以人为来补充，但是时间至少目前是不能被人为控制。当然，将来我就保不准了。

比如很多正则表达式的实现

pcre引入了jit。这个我知道。有测评也显示，在大多数时候效率会高一些，也并非全部。总之jit是一个中间层面的优化，远没有达到编译器直接优化的级别强度。

或者某些FFT计算库

fft据我所知很多都是直接针对cpu体系结构编汇编。当然也有直接写c这些高级代码的。但是你说的jit搞fft，我倒是孤陋寡闻了。

让C++骄傲的高性能应用是哪些呢？

你自己说的boost的blas算不算一个？你怎么能自己前后说法不一。
还有太多，我懒得说了，别忘了，c++的历史足够产生太多的优秀项目。

非C++不可的高性能计算

什么叫非c++不可，我从来没觉得什么事情是非c++不可，也更不会觉得非你说的jit这些如此等等不可。什么叫非什么不可？
你难道不觉得几十年前希尔伯特就已经在这个事情上败了么？

你对非python，javascript这些非native代码的性能有疑问

我哪里在说我对这些非native代码有性能疑问？我只是在说你说native已经被Jit超越这一定论。说你这个论点太缺乏考虑而已。

发现代码目录2个多G，里边放了两份这个库的拷贝

用boost就是自取灭亡。懂么？自取灭亡。你看boost多少年了，至今被多少人接受？他的问题太多，尽管有一些的确不错的东西，只是仅仅为了这些就引入boost，得不偿失。

最大的就是一堆lib文件，dll文件反而很小

这些都是表象。boost的完整编译版本就有几个g。我编译过几次boost，每次都等大半天。
除了这些表象，boost问题是还大量用模版，整个大多都是模版，你如果感兴趣，用用spirit这个被吹得神乎其技的bnf本地代码生成器，你试试，你就知道我为什么那么讨厌boost，那么反对把boost用到产品中。

记得一份lib文件要600M，预编译头文件目录还800M

你的肯定不是完整版本。2年前就不止这个大小。

我对MS的开发环境不熟，还想问问你是怎么回事呢。

问题非常多。所以就是如果能不用就不要用，得不偿失。而且在我看来，boost几乎也没什么大用，或者你说的非用不可的地方。

元编程

佛说这是元编程，菩萨说那是元编程，上帝说你们说都不对，这才是元编程。

C++就这么一个有点，哥咋能不知道

我举了一个例子，你就说只有这一个。唉，我也不知道说什么好了。

linkage code generation

这里也是一个权衡问题。
我前面在考虑，既然c++的abi是一个问题，为什么不学习java，把连接推迟到加载的时候，也就是把连接推给操作系统，加载时连接。这样不就可以解决abi问题了么？但是又想回来，这个过程可能会影响效率，而对于c/c++这些以效率为命的语言而已，以及视效率为命的计算机技术多年遗留下来的意识，可能不会去牺牲这一点效率换来abi问题的解答。

Window底下用起来省事的库没几个，VC里加lib文件的过程恶心死了

这些都是基本功。还行吧，我觉得还行，这些都是必须要面对的，不是你想不想的问题。
你用Python这些用起来很爽吧，我也用。不过套用bs的一句话来说“java是平台，他不是一门单纯的语言”懂了我的意思吧？

哥不太用C++，所以cppers内部矛盾哥不了解

你的帖子我基本看的出来。不过不要紧，我并非说什么，只是看到你觉得jit是万能药，所有说了一下自己的看法而已。

不知道，PyUblas可以链接到C库上去吗？用这玩意儿还不如用PyCUDA。

PyUblas是用来让python用boost的blas的连接体。你刚才不是说boost的blas很好，最高效么？你不是说你很想在python中用boost的这个功能么？我给你提出来，你又突然说这个不如pyCUDA。唉，我不知道你要干什么，你说想向东，然后我给你说了东的方向，然后你跟我说，你想去西。唉。我真累。算了。

现在的cpper已经不承认C++是OO语言了，都认为C++是GP语言。“GP == 高性能”又不是我发明的

我算是被你雷得皮胶柔嫩。GP==高性能？。。。。。。
既然你不太用c++“哥不太用C++”那我觉得就没必要继续说了。

总之，我时不时跳出来给c++辩护，并不是我在说c++多么的好，更不是说c++就是我主要用的语言，甚至我对c++比你更恼火。明白这个就好。

reiase

回复 69# OwnWaterloo


如果想把C++代码编译成p4上的native代码，就不可能带core 2的sse4优化。带了sse4优化，在p4上就跑不起来了，直接报告非法指令。有些手段能够让p4执行p4的native代码，core 2执行core 2的native代码：
1. 动态库动态加载，先检测CPU，根据CPU加载对应CPU的编译结果
2. 使用liboil等库，生成代码。大概就是用liboil的语法写个函数，运行时，让liboil编译这段代码成native代码。因为目标是SIMD指令，所以liboil语法类似汇编。
3. fatelf或者Universal binary，同一个二进制文件，同时包含p4和core 2的编译结果。

不过这些都不是语言层面上解决的。其实JIT也不是语言层面上的技术。