Chinaunix

标题: 都在讨论C，很少有C++ [打印本页]
作者: 家住马戏团    时间: 2012-04-15 22:53
标题: 都在讨论C，很少有C++
...
作者: tarside    时间: 2012-04-16 07:15
因为很少用 C++, 可以用 C 实现大部分的功能。
作者: hwp195    时间: 2012-04-16 13:30
把老子搞定了，儿子不在话下。。。。。。。。。。
作者: GFree_Wind    时间: 2012-04-16 13:41
因为CU更偏向Linux，而做linux的，使用C甚于C++
作者: yueliangdao0608    时间: 2012-04-16 14:06
作者: 家住马戏团    时间: 2012-04-16 21:37
回复 3# hwp195
小看c++了

   
作者: 0xC1988    时间: 2012-04-16 21:48
http://bbs.chinaunix.net/thread-3692320-1-1.html
这里C++讨论很热烈
作者: chinesedragon    时间: 2012-04-17 11:20
用C的人多而已
作者: ecloud    时间: 2012-04-19 20:55
家住马戏团 发表于 2012-04-16 21:37
回复 3# hwp195
小看c++了

我就小看他怎么着了？
在各个公司最新版本的编译器环境中，无论是VS .net还是Xcode，C#和ObjC的编译效率已经超过C++了。失去了效率这一根最后的救命稻草，C++这种不伦不类的东西可以入土为安了
作者: OwnWaterloo    时间: 2012-04-19 21:00
ecloud 发表于 2012-04-19 20:55
我就小看他怎么着了？
在各个公司最新版本的编译器环境中，无论是VS .net还是Xcode，C#和ObjC的编译效率已经超过C++了。失去了效率这一根最后的救命稻草，C++这种不伦不类的东西可以入土为安了


1. 吹牛前先检查稿子来源可信度
搞几个特例说某某语言效率超越C++是老早前就有的事了，并不需要最新版本的编译环境。

2. 不伦不类，怎么都是ObjC更适合。
不是靠着公司撑腰，这种垃圾连被历史车轮碾过的资格都没有。
作者: ecloud    时间: 2012-04-19 21:14
OwnWaterloo 发表于 2012-04-19 21:00
1. 吹牛前先检查稿子来源可信度
搞几个特例说某某语言效率超越C++是老早前就有的事了，并不需要最新版 ...

就靠公司撑腰怎么了？不靠大公司撑腰难道还要靠你撑腰？有用么？
现在连微软也不给C++撑腰了，杯具了吧，不服？
作者: OwnWaterloo    时间: 2012-04-19 21:18
ecloud 发表于 2012-04-19 21:14
就靠公司撑腰怎么了？不靠大公司撑腰难道还要靠你撑腰？有用么？
现在连微软也不给C++撑腰了，杯具了吧，不服？


1. 我老子是苹果怎么了？
痞气尽显无遗。

2. C++何时求那个微软撑腰了？
只会靠着公司撑腰的人，思考回路果然也只会继续依赖。

3. 有公司撑腰有怎么了，垃圾就是垃圾，不服？
作者: OwnWaterloo    时间: 2012-04-19 21:23
ecloud 发表于 2012-04-19 20:55
我就小看他怎么着了？


你小看又怎样么了？你还真当自己是个人物么？你算老几？
果粉你醒醒。
作者: ecloud    时间: 2012-04-19 21:27
OwnWaterloo 发表于 2012-04-19 21:18
1. 我老子是苹果怎么了？
痞气尽显无遗。

呵呵，现在是谁不服？好像不是我吧，而是类似LZ这样成天发牢骚贴的吧
看到人家写“垃圾Java代码”得人赚的钱比你们高，不服不是么？
看人家随便写个垃圾玩意儿扔App Store就能赚到美金眼红不是么？

谁不舒服谁心里清楚，嘴上逞能有什么用？何必为了个语言那么执着，那么纠结，跟命一样
作者: OwnWaterloo    时间: 2012-04-19 21:32
ecloud 发表于 2012-04-19 21:27
呵呵，现在是谁不服？好像不是我吧，而是类似LZ这样成天发牢骚贴的吧

ecloud 发表于 2012-04-19 21:27
看人家随便写个垃圾玩意儿扔App Store就能赚到美金眼红不是么？


又随意代表他人了？
你还真当所有人都稀罕那点美金？  你眼界也就这么点？

ecloud 发表于 2012-04-19 21:27
看到人家写“垃圾Java代码”得人赚的钱比你们高，不服不是么？


又开始玩特例了？


ecloud 发表于 2012-04-19 21:27
谁不舒服谁心里清楚，嘴上逞能有什么用？何必为了个语言那么执着，那么纠结，跟命一样


何必为了个商人、公司、产品那么执着，那么纠结，是它们是你老子吗？
作者: ecloud    时间: 2012-04-19 21:33
OwnWaterloo 发表于 2012-04-19 21:18
1. 我老子是苹果怎么了？
痞气尽显无遗。

还有要提醒你一点
要是没有微软的支持（当然还要感谢当年SUN打赢了官司），C++不会有今天的地位。真正实实在在推动过C++发展的就两个公司，Borland和微软
你们吃这碗饭的应该知恩图报，有一颗感恩的心。而不是成天拽来拽去的不把微软放在眼里。你能拿现在这个工资，不完全是个人的能力，微软也有一份在里面的
看看那些曾经牛到天上的写Delphi，4GL的人，如今的下场。你难道不应该感谢微软么？
作者: ecloud    时间: 2012-04-19 21:35
OwnWaterloo 发表于 2012-04-19 21:32
何必为了个商人、公司、产品那么执着，那么纠结，是它们是你老子吗？


成天在这里纠结执着的又不是我，是谁谁心里清楚，呵呵

拜拜了，您们慢慢纠结去吧
作者: walleeee    时间: 2012-04-19 21:37
回复 11# ecloud


微软不给c++撑腰么？算了吧，微软的人在笑你。还是老话，你如果不是故意，那就是无知。

还有，看你也是一个老id，不知道为何如此不智偏激片面。
作者: OwnWaterloo    时间: 2012-04-19 21:37
回复 14# ecloud

你就继续意淫，意淫ObjC效率高、意淫苹果你可以靠到死、意淫Java工作高、意淫他人对那个App Store眼馋得不得了、意淫大伙因此发骚。

作者: OwnWaterloo    时间: 2012-04-19 21:40
ecloud 发表于 2012-04-19 21:33
还有要提醒你一点
要是没有微软的支持（当然还要感谢当年SUN打赢了官司），C++不会有今天的地位。真正实实在在推动过C++发展的就两个公司，Borland和微软
你们吃这碗饭的应该知恩图报，有一颗感恩的心。而不是成天拽来拽去的不把微软放在眼里。你能拿现在这个工资，不完全是个人的能力，微软也有一份在里面的
看看那些曾经牛到天上的写Delphi，4GL的人，如今的下场。你难道不应该感谢微软么？


哟，你又开始吹历史了，你是不是肚子里就只有这点老账？翻多了不怕翻烂吗？
作者: OwnWaterloo    时间: 2012-04-19 21:42
ecloud 发表于 2012-04-19 21:35
成天在这里纠结执着的又不是我，是谁谁心里清楚，呵呵

拜拜了，您们慢慢纠结去吧


果粉说的是谁谁心里更清楚。慢走不送。
作者: walleeee    时间: 2012-04-19 21:45
讨论也好，纠结也好，说c++好也好，坏也好，难道就一定是工作中要用才来么？

比如想必你学了那么多东西，都用上了么？编程序只要手，是不是就该恨为什么生了脚，为啥不多生2只手，4个手多好

至于你说写app等等此类，你是在用当下去对比。你能保证10年后还这样么？你不能保证，没任何一个人有这个能力和资格保证，也没必要保证。退一万步，10年前c++的地位怎么样？相信你之前也是用的人，那个时候你没鹏臭脚？即便没捧，那你当时基本就是你现在所批评的对象，你觉得有意思么？

你能看懂我上面说的逻辑么？能明白我的意思么？好几层呢
作者: ecloud    时间: 2012-04-19 21:46
walleeee 发表于 2012-04-19 21:37
回复 11# ecloud


我现在旁边就坐着一个微软的人，正在嗑瓜子，你要跟他通话么？
他就是做IL的，当然了是些外围的东西，老外不会让中国做很核心的东西
但是微软下一步要把所有的编程环境IL化这事情难道你不知道么？好像是前年的旧闻了吧
完全IL化以后，什么C#,C++还是VB，仅仅是语法形式的区别罢了
作者: newmax123    时间: 2012-04-19 21:47
ecloud 发表于 2012-04-19 21:33
还有要提醒你一点
要是没有微软的支持（当然还要感谢当年SUN打赢了官司），C++不会有今天的地位。真正实 ...



您回去在看看书啊！
作者: OwnWaterloo    时间: 2012-04-19 21:49
回复 19# walleeee

好意提醒你一下……
此人屁本事没有，唯有小道消息特多。
你要和他比这个，我不说输赢，很费你时间。
CU估计也只有bbj大神能在这方面收服此妖孽了。
作者: walleeee    时间: 2012-04-19 21:54
回复 23# ecloud


可以啊，没意见。

微软是不可能那么快脱开的，你看的太简单的。表象而已。10年前就有人说java出来c++已死，可是至今好好，尽管什么排行榜这些下来了一些，不过过不是问题。

语法？你当IL是十全大补丸？IL也是好多年的事情了，你觉得如今平台多样化，还能有当年那么活力么？
同样，退一万步，看看市面上面试用的最多的语言，据我说只是c++，至于工作，不一定是c++。但是为什么会有这个现象，你能理解么？还有，大学为什么基本都是教c++为主要，而且大多的高校科研项目也是c++。为什么号称最大的项目kde也是c++？为什么android也要给c/c++提供native支持？为什么google那么多开源项目用c++？为什么？明白么？

你说的c#,vb等等此类，它们由他们的优势，但是一个问题之一，它们控制在ms手头，和c/c++本质上就有区别，尽管都是c系。
c++在ms的vc这些东西里面搞得不人不鬼，是谁的问题？你伟大的ms没有一份么？

你对为什么要编程的理解和我不一样，所以很多想法也不一致，这很正常。只是我觉得你以己度人，有些不妥。
作者: ecloud    时间: 2012-04-19 21:55
walleeee 发表于 2012-04-19 21:45
讨论也好，纠结也好，说c++好也好，坏也好，难道就一定是工作中要用才来么？

比如想必你学了那么多东西， ...

10年前跟我同住的哥们是写4GL的，写的一些简单的要死的程序，工资是我2倍
我可没纠结过，人家会人家运气好罢了，自己该干啥干啥，爱干啥干啥
12年来我只要一有机会肯定会在项目中推Python和Plone，但是我从来不会发什么纠结贴，大谈特谈这东西好用啊，上线快啊，比什么Java,PHP简单多了。自己觉得好自己就用偷着乐呗
但是兴趣归兴趣，干活归干活，虽然当年我写Java比不上人家4GL的，但是至少也不会弱于C++的，呵呵:wink:
作者: walleeee    时间: 2012-04-19 21:55
回复 25# OwnWaterloo


    我今天加了3000分，比较意外，第一次去清聊版炫耀了一下，结果那边人太热情了，太友善了，我招架不过来，它们还欢迎我常去，算了，我招架不了。
作者: OwnWaterloo    时间: 2012-04-19 21:58
walleeee 发表于 2012-04-19 21:54
你说的c#,vb等等此类，它们由他们的优势，但是一个问题之一，它们控制在ms手头，和c/c++本质上就有区别，尽管都是c系。


整个人都卖个公司了，就是他的衣食父母了，指望他能懂这些？
作者: OwnWaterloo    时间: 2012-04-19 22:01
回复 28# walleeee

分是浮云……  应该是因为这个：http://bbs.chinaunix.net/thread-1154982-1-1.html
清茶太水水水水了……  我根本就不敢踩进去……   浮不起来就完了……
作者: ecloud    时间: 2012-04-19 22:02
walleeee 发表于 2012-04-19 21:54
回复 23# ecloud

It's a job, just business!
不要把这东西当人生追求，等岁数大了你就明白了
作者: walleeee    时间: 2012-04-19 22:09
回复 27# ecloud


你的个人经历。只是有些偏激。


30年河东，30年河西，老话了。一般鼎盛时也是衰落始。对于技术这种东西，你想必也知道，并非某个技术好，就会成功，就能被接受，能被推广，如MMMIX所言，不是什么东西都可以人为。

python这些我早就说了，有他的好处，能方便你做事情就可以，没什么好争论的，吃亏的人当然说他不好，但是你有好处，当然就会出来反驳，正常。

c++的领域范围太广，现在有些被java和c#这些抢占了，特别是新出来的移动平台，都有抛开c++的趋势，但是又都抛不开。你觉得是技术不够抛不开么？

什么叫不会弱于c++？你说赚钱不弱于c++，还是程序效率不弱于c++还是别的什么不弱于？我不懂。
至于你前面说编译效率其他语言比c++高，这个倒可能，但是运行效率，那是不可能的。尽管现在时不时冒出什么java比c++快，一会python比c快，等等此类。我不知道这个对比有什么意思，说给傻逼听么？让傻逼自娱自乐？你这种老id应该不会跟他们一样乐吧？看过java/python这些的实现设计，或者代码就明白，这个事情不可能发生，最多就是相当的效率。做到这个很简单，写个python代码和c++代码，代码只有io操作，效率最后一定相当，比如读写文件10000万次，这些只是运行效率的一种而已。但是c/c++这些编译型语言，生成的都是native代码，没有可比性。不过我补充一点，是有些特殊例子会出现python比c++快，这时很可能是你c++代码写烂了，而python正好对口，有了缓存等等优势。这些都不具有可比性。
作者: walleeee    时间: 2012-04-19 22:10
回复 31# ecloud


对，是job。问题是我不只为了job，为job而job这没意思。无论如何我也没兴趣成为这个。
作者: walleeee    时间: 2012-04-19 22:11
回复 30# OwnWaterloo


嗯，还行吧，那边人太热情，只是这个感觉。
作者: ecloud    时间: 2012-04-19 22:18
walleeee 发表于 2012-04-19 22:09
回复 27# ecloud

移动平台？如果说iOS的话，还真没C++什么事
运行效率，C#和ObjC编译成的本地代码都比C++快了，至少在官方优化下是这样的，你可以说微软和苹果动手脚了，我也怀疑动了手脚，但是现实结果就是快，你也没辙

最后还是那句话，不要把个什么东西看得太神圣化，大公司要它死不过是分分钟的事情。Alpha那么好的东西还不是说死就死
不要在一棵树上吊死，见风使舵，才是做business的正确方法

我当年接触J2EE还是被两个原C++程序员带着的呢，以前根本不知道这东西咋回事，结果仨人现学现卖
做IT这行千万不能死脑筋，该扔的就扔，该跟进的就赶紧跟进
作者: ecloud    时间: 2012-04-19 22:31
最后一贴，再不跟了
说道C++，这个版里发牢骚说空话的居多，做实事的几乎没有

Google的C++单元测试框架：gtest，在dev c++（也就是mingGW）环境下无法编译。之前我找遍了网络没有一点信息。我就奇怪了是究竟你们写C++的人不爱做单元测试呢，还是gtest你们看不上眼（还有别的更好用的请推荐）

结果我这个既不懂也不鸟C++的人在万般无奈的情况下自己改了gtest的源代码，令其在MinGW环境下可以编译通过，其实就是很简单的一个修改，毫无难度
http://blog.chinaunix.net/uid-140978-id-3029195.html

这些成天嘴上挺C++得人，也不知道都在干啥
作者: walleeee    时间: 2012-04-19 22:35
回复 35# ecloud


objc和c#也都是编译型的，比c++快不少那是c++代码写得可能有问题，而非语言本省有问题。c#据我所知4.0的时候测评都还比c++慢了不知道多少。
objc我没写过。但是据我所知很多用objc的人咒骂他的语法比骂c+的数量也少不了多少，态度也不比你这里的激进少。我前面就说了，用objc的人，并非都如你一样觉得他好。是因为他能赚钱，至少能给它们赚钱，至少对它们而言比c++更能赚钱。

我没怀疑它们动手脚。在我看来没什么手脚好弄，从最下面的native看上来，不外乎就是预加载一些库，比如windows自己肯定会预载一些c#的依赖库，而且它们自己搞的一些程序也在用这些库，所以让你感觉好像快。比native代码，c/c++那是直接面向cpu的，你觉得如何，有可比么？jit这些都是浮云。在cpu计算级别，什么都是浮云。
还有就是有缓存，缓存的威力是巨大的，缓存优化得好，带来的价值客观程度比你单纯的语言计算性能更客观。为什么一些大型的云计算平台，比如openstack用python都敢搞，因为这个时候单纯语言的计算性能根本就不是个问题。况且现在的硬件发展速度有点快，一个xeon 1230这种很厉害的cpu才1k出头，内存也便宜，手机都有2g内存，快4g了。所以语言的单纯性能就显得不如以前重要。但是在特定的领域，科学计算，图形计算，以及我想看到的智能计算这些等等此类，还是需要语言级别的性能。
你c#这些搞的火热，还有个不可磨灭的工程是微软的宣传和平台绑定。以及google对android上java的控制。这些都是没办法的，所以我刚才跟你说，中立的语言和公司级别的语言是有本质区别的。

我没有看的神圣化。这个和vim和emacs圣战，windows和GNU/Linux圣战，开源和闭源圣战，开源和自由圣战。。。你去看热衷于这些的基本都是用泵，毫无疑问我自己以前也是。现在好多了。

见风使舵，还要看运气，就像你当年一样。
c/c++前景的精英化。会慢慢的淡出视野，但是也死不了。

c++程序员搞其他语言很正常啊，而且这根本就不是一个问题。语言难道有问题么？
理解了程序本身，差别就如你所言，只有语法级别以及一些考虑细节，尽管它们的确也是问题。
c++程序员去写其他，我看的多了。

“该扔的就扔，该跟进的就赶紧跟进”
经验之谈，受教谨记
作者: OwnWaterloo    时间: 2012-04-19 22:36
ecloud 发表于 2012-04-19 20:55
在各个公司最新版本的编译器环境中，无论是VS .net还是Xcode，C#和ObjC的编译效率已经超过C++了。失去了效率这一根最后的救命稻草，C++这种不伦不类的东西可以入土为安了

ecloud 发表于 2012-04-19 22:18
运行效率，C#和ObjC编译成的本地代码都比C++快了，至少在官方优化下是这样的，你可以说微软和苹果动手脚了，我也怀疑动了手脚，但是现实结果就是快，你也没辙


你也怀疑动了手脚？那你前面不是在说话而是在喷粪吗？才这么快就自己扇自己耳光了？
作者: OwnWaterloo    时间: 2012-04-19 22:41
ecloud 发表于 2012-04-19 22:31

最后一贴，再不跟了
说道C++，这个版里发牢骚说空话的居多，做实事的几乎没有

Google的C++单元测试框架：gtest，在dev c++（也就是mingGW）环境下无法编译。之前我找遍了网络没有一点信息。我就奇怪了是究竟你们写C++的人不爱做单元测试呢，还是gtest你们看不上眼（还有别的更好用的请推荐）

结果我这个既不懂也不鸟C++的人在万般无奈的情况下自己改了gtest的源代码，令其在MinGW环境下可以编译通过，其实就是很简单的一个修改，毫无难度
http://blog.chinaunix.net/uid-140978-id-3029195.html

这些成天嘴上挺C++得人，也不知道都在干啥


你不鸟你用毛个gtest啊？又要用又要说自己不鸟，嘴上说不要身体又很老实嘛？
你不懂你前面又发毛个言啊。

我了个去，你还当自己解决了个技术问题吗？
是论坛上没人帮助你这个菜鸟，没人理你那帖，所以你才怀恨在心嘛？
刚才意淫他人眼红App Store上捞美金，现在又把这种不值一提的东西拿出来，你就这点境界？ 害臊吗？
作者: bruceteen    时间: 2012-04-19 22:42
很激烈嘛，还是OwnWaterloo说话在理，不是胡搅蛮缠
作者: walleeee    时间: 2012-04-19 22:43
对于ecl这样的老id，我只是觉得ecl莫非是故意这样说。无论如何，10年的老id和前辈都值得尊敬，这个是基本的。
作者: ecloud    时间: 2012-04-19 22:46
OwnWaterloo 发表于 2012-04-19 22:41
你不鸟你用毛个gtest啊？又要用又要说自己不鸟，嘴上说不要身体又很老实嘛？
你不懂你前面又发毛个言啊 ...

如果你能找到，在任何地方，无论中国还是外国的论坛上，有我发过的关于gtest编译的求助贴
那么我收回今天我在此的所有发帖，并且不再在本版出现
否则
请你以后不要回我的帖子，我不想搭理你，你也别搭理我，就这样
作者: OwnWaterloo    时间: 2012-04-19 22:48
回复 41# walleeee

同清茶回复的，02年的id要尊重，12年的就不尊重？
还是02年的要尊重，12年的要尊重，但更尊重02年的？

这其实是一回事，以貌取人与以id注册年份取人。
作者: walleeee    时间: 2012-04-19 22:51
回复 43# OwnWaterloo


清茶传到这里

不是说02年该尊重，是尊敬

尊重是范义词，尊敬是下对上。

要知道，按照我国国情，02年注册，至今应该是30多岁了。这个行当里摸爬滚打10多年，我觉得还是值得尊敬的

当然，闻道有先后，术业有专攻，并非老id就一定比新id技术上厉害，或者见识上的优势。
作者: OwnWaterloo    时间: 2012-04-19 23:00
ecloud 发表于 2012-04-19 22:46
如果你能找到，在任何地方，无论中国还是外国的论坛上，有我发过的关于gtest编译的求助贴
那么我收回今天我在此的所有发帖，并且不再在本版出现
否则
请你以后不要回我的帖子，我不想搭理你，你也别搭理我，就这样


你还残留有逻辑没？你要不要在这个版出现、要不要收回你所有发帖以及我要不要回你帖子，这些与你是否发求助帖有几毛钱的关系？
你是不是终于找到个理由，以为可以体面的让我闭嘴，自己又有台阶下了？

另外：别说我愿意搭理你似的。我也很无奈啊，请你以后发言前过脑可以吗？


最后，从2011-11-27 16:04：
ecloud 发表于 2011-11-27 16:04

win平台只给VS和CB的工程文件，我用Dev C++/MinGW楞是没辙，试了好多方法都不成，下了个Code::Block也不成，导入sln后编译不成功，一大堆链接错误，大概是此工程压根儿就没考虑MinGW的库？强调的MS库？
后来用cygwin编译出来的gtest.a和gtest_main.a，只能在cygwin环境中用，一链接到MinGW编译出来的.o，就报一大堆链接错误
官方文档里说用cmake可以支持各种编译器环境，结果我下了个cmake，然后根本不好用
给个手工编译的文档能死乎？
神马J8东西做的一点都不人性化



到2011-11-28 10:21：
ecloud 发表于 2011-11-28 10:21
已经手工解决，需要改一小段代码（等会有空我会写个小文档）
已经成功在Dev C++ 4.9.9.2上编译出来了两个库，gtest.a和gtest_main.a



这大半天时间，原来仅仅是抱怨，不是在等人解答啊？
那我就不懂了，既然你那帖不是求助的，那你在这帖里抱怨个啥：
ecloud 发表于 2012-04-19 22:31
说道C++，这个版里发牢骚说空话的居多，做实事的几乎没有
这些成天嘴上挺C++得人，也不知道都在干啥


反正你自己也能解决，只是上来抱怨那东西做的不人性化而已？
那你管我们回不回你那个帖子，有没有做你所认为的实事？
作者: walleeee    时间: 2012-04-19 23:01
回复 36# ecloud


单元测试自己简单写写。不用gtest和cppunit这些。
这里有一个技巧就是尽可能在设计的时候就保持每个功能块尽可能小，不然测试太复杂。
当然，最后的集中测试是比较麻烦，所以我一般都是在走钢丝，这个比较尴尬。
想必gtest和cppunit这些也并不能很好的解决这个问题，不然我怎么会不用。
当然，还有很多其他的测试套件。

哦，改代码这个是司空见惯的，我倒觉得没你前面点到的那个问题好。
原因如下：
1.别人未必出了问题(gtest版本，你的g++版本)
2.别人改了未必要分享给你，没这个义务
3.开源的东西，改代码奇怪么？kernel人家taobao都要适当修改才能最大化利用
4.我看你代码不久是少了一个函数，可是这个函数在其他平台是正常的，人家gtest确没测试到你的mingw。这个不很正常么？
5.坛子里我看新手居多，大多是问一些语法初级问题。但是也不乏好帖，大家百家争鸣，各有长短，取长补短，这是好事。但是你看看csdn那边的论坛，装疯卖傻，装傻卖萌，那才让人疯。

如果你对c++感兴趣，大可以关注一下kde和qt以及chromium和webkit这些大型项目的设计，那个可是真刀真枪，来不得水。
牢骚贴在哪里是没人关注的。
作者: OwnWaterloo    时间: 2012-04-19 23:03
回复 44# walleeee

随便吧，你要尊重就继续尊重……
反正我是会以id注册年份作为态度的标准的……
希望你这段话不要被@pmerofc看见……
作者: walleeee    时间: 2012-04-19 23:05
回复 47# OwnWaterloo


。。。是尊敬，不是尊重，你看我原帖，一个字没改。

pmerofc？也有仇？。。。结仇广泛太难了，也被做到了。。。熊娘子。。。
作者: OwnWaterloo    时间: 2012-04-19 23:12
回复 48# walleeee

哦，这样……  那就换成尊敬好了。
如果pmerofc看到关于"长者就应该尊敬"等类似的话，不知道他会不会继续说谭浩强的故事……
作者: walleeee    时间: 2012-04-19 23:19
回复 45# OwnWaterloo



to: ecloud

我用了很久的cmake，之前也用auto工具，以及boost用的那个构建工具。总体来说，如果要想在多个平台编译，那cmake是不错的选择，可以生成多重构建文件。cmake不好就是稍微有一点大。多平台项目，反正我喜欢用cmake。当然，eclipse也是个选择。至于你说难用，那我不知道了。我基本没看cmake的说明，看几个例子就成了。

mingw去编译那些库也是不是长久之策。mingw的编译器和ms的编译器编译出来的效率有明显的差异，你可以自己去看测评。
当然，mingw编译那些库要方便一些，基本不用改代码，而非要用ms的编译器去，该代码就是家常便饭。cygwin依赖中间层，主要是常见的cywin1.dll这些东西。所以cygwin搞出来要慢很多。



to ow
说道这里突然想起：
你如果要在win下用emacs和vim这些传统的*nix编辑器，你把cygwin的Bin加到ms的环境变量path里面，会让emacs/vim好用很多。然后把HOME设置成 c:\user\你的名字 我是这样搞的。个人经验。还有一些细节用mklink来搞，这个软连接cygwin的shell和windows都认。而ln来搞就cygwin认，ms不认。
作者: walleeee    时间: 2012-04-19 23:21
回复 49# OwnWaterloo


我说了，尊敬是态度，问题还是得讨论。这有什么关系么？

pmerofc大可以挑他的错，我觉得很好啊。
作者: OwnWaterloo    时间: 2012-04-19 23:24
回复 50# walleeee

HOME设置过，而bin下的东西不是用的cygwin，而是到四处拼的，msys/gnuwin32(好像叫这个名字)/unixutls……
mklink……  xp压力很大……
作者: walleeee    时间: 2012-04-19 23:34
回复 52# OwnWaterloo


你这样不行。

1.gnuwin32已经早就不更新了，没法用。
2.msys我虽然装了，但是觉得没什么。只是Mingw依赖这个。其实mingw在我看来也用处不大，而且还不是Posix完整
3.unixutils也不行
4.windows自己的unix环境更是鸡肋

至少要vista才有mklink。不过mklink不重要，没有就算了，我用这个是因为我要把配置放到另外的地方，然后做个连接出来给home，我很多配置都管理在sourceforge，不然就要乱。我mingw，cygwin，linux公用一个配置，windows上的原生emacs/vim要和mingw/cygwin/linux的emacs/vim用一个配置。所以我要Mklink。

你如果没我这么复杂的要求，你可以不用mklink。把cygwin/bin加到path里面的好处是emasc就可以强很多。但是注意，cygwin/bin是加到path最后，不然可能有些小问题麻烦。

这是个经验。cygwin还是不错，比较方便，但是包不够多，有些东西还要自己去编译。只不过这个一般不是什么大问题。
作者: OwnWaterloo    时间: 2012-04-19 23:39
回复 53# walleeee

我用得挺好的，太复杂的unix tools我也没学过。
我不是系统管理员好吗
作者: walleeee    时间: 2012-04-19 23:40
回复 54# OwnWaterloo


原来如此。嗯，反正这个只是我个人用emacs的一点小技巧。

windows的那个unix环境真是块大鸡肋，死垃圾。
作者: OwnWaterloo    时间: 2012-04-19 23:46
回复 55# walleeee

Windows残念的地方太多了……
作者: 三月廿七    时间: 2012-04-20 10:06
LZ 是不是感觉自己被冷落了
作者: 三月廿七    时间: 2012-04-20 10:13
远离 面向对象， 远离尘嚣
作者: 鬼谷子大师    时间: 2012-04-20 10:42
哇哇，本帖后续讨论严重偏题啊，居然还论战上了。。

我是来凑热闹的，我喜欢C++，也喜欢C，两不相帮
作者: reiase    时间: 2012-04-20 13:09
我觉得不能说C#速度超过C++不可能。说到底，什么语言速度还都赶超不了汇编呢。

最近python都能凭借jit，数值计算上逼近C++。
http://morepypy.blogspot.com/201 ... rogress-report.html

我所知的另外一个例子是网络的例子，有人对比了几种框架
http://oddments.org/scalestack-vs-node-vs-twisted-vs-eventlet

两个例子，一个是CPU计算的，一个是IO的，C++在性能上都不是特别具有优势。

现代C++的性能无非就靠泛型，其实很多领域，压根是不要泛型的。比如图像处理，正常的都用unsigned char。再比如数值计算，好些库直接用double。如果只有一种类型，泛型的性能优势还在吗？性能始终是一个领域内部的问题，最终还是靠这个领域内部的方案来解决。
作者: reiase    时间: 2012-04-20 13:10
回复 53# walleeee


放弃吧，有钱去买个MAC，没钱装个虚拟机跑Ubuntu
作者: walleeee    时间: 2012-04-20 14:54
回复 59# 鬼谷子大师


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

取中文名字，你不嫌登录的时候麻烦？是不是也要输入中文？
作者: walleeee    时间: 2012-04-20 14:56
回复 61# reiase


你只是考虑到了一面。cygwin并非是我不能用linux虚拟机这些而选的替代。我2个机器，开个linux还不简单么？只是我需要在win下使用linux工具，这个cygwin做得还行。如果仅仅要个linux独立环境，我装个colinux说不定比你虚拟机更方便。
作者: walleeee    时间: 2012-04-20 15:06
回复 60# reiase


你说的你仔细想过么？

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

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

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

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

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

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

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

算了。你没理解。

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

算了，你根本就不理解。

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

这个倒是说的不错。当然，你也等于说了一句白话。你把“性能”二字换成其他，比如“质量”，你觉得是不是依然很有道理。。。
作者: reiase    时间: 2012-04-20 16:00
回复 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    时间: 2012-04-20 16:20
回复 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    时间: 2012-04-20 17:20
回复 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    时间: 2012-04-20 17:50
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    时间: 2012-04-20 17:58
回复 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    时间: 2012-04-20 18:01
回复 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也不是语言层面上的技术。
作者: walleeee    时间: 2012-04-20 18:02
回复 69# OwnWaterloo


真正的执行文件带着编译器一起发布，本省就是一个让人哭笑不得的事情。说以我后面引用“java是平台，不是一个单纯的语言”
这个段子。

如果什么时候c++也带一个前面我跟你说二进制解释执行，跨平台了，但是那个时候不知道又有多少人来骂了


ps.
简单的对比，不是故意就是无知。我还是觉得这句说的不错。
作者: OwnWaterloo    时间: 2012-04-20 18:06

reiase 发表于 2012-04-20 18:01
如果想把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也不是语言层面上的技术。


p4没有sse4，没法用这优化很正常。
带了sse4优化的在p4上跑不起来了？为什么带了sse4优化还要在p4上去跑啊…… 就不能另外编译一个只用p4指令的吗……

你还是没回答我的问题……
p4与core 2上的binary必须是同一个？  就不能在需要时分别各自编译出一套？
作者: reiase    时间: 2012-04-20 18:28
你想说什么？你想走极端？你非要把p4的native拿去给core2，我还能说什么？你为什么不干脆搞个不能运行更靠谱，那个时候你觉得我们再谈效率有意思么？
回复 70# walleeee
现实就是这样，基本上所有软件发布时候都是按照SSE2编译优化。

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

我不同意的，就是“仅此而已”

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

好像JIT就少有人研究了

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

template不也是空间换时间

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

fftw

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

之高那么一点点，还没法给其他库链接，有用吗？
还有，不要提历史上的。要C语言那种“永垂不朽”的项目。Qt不算，Qt的C++不是正统C++

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

我们在讨论native和非native的问题

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

有人说性能是C++的最后稻草，你说C#这种靠JIT的语言性能不行。所以我来举例，JIT的性能不错喽。

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

那个库没个问题？算了，Boost我也不懂，翻手册写过两行代码而已，没发言权

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

我没说Boost，我说的是在MS看到的一个，基于C++模版技术的图像处理库

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

我用MS环境的感觉就是：随便写写代码，早点让痛苦结束吧。

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

有数据能够说明java并不慢，慢的是jvm加载过程。

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

JIT不是万灵药，不过JIT是治Python问题的唯一药。我只是比较期待JIT能够给Python一个大加速。除JIT外，其他不太指望的上了。

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

我不直接用blas，我用的几个库要用blas。blas-reference、blas-atlas、rmblast、mkl和goto-blas是可以相互替换的，貌似ublas还不行。

另外，说OO是C++最微不足道的特性的就是OwnWaterloo

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

交流下看法嘛。大家平时做自己一块东西，难免会片面。
作者: AD8018    时间: 2012-04-20 18:32
说个现实问题吧，有没用于检测CPU支持的指令集的library?

作者: reiase    时间: 2012-04-20 18:33
OwnWaterloo 发表于 2012-04-20 18:06
p4没有sse4，没法用这优化很正常。
带了sse4优化的在p4上跑不起来了？为什么带了sse4优化还要在p4上 ...


发布二进制文件时候怎么发布呢？你只能发布给用户p4的二进制代码，这样p4和core 2都能跑。难道让用户自己判断自己的CPU，然后按需要下载？

自己做实验，都用-march-native，反倒不关心p4还是core2。
作者: reiase    时间: 2012-04-20 18:34
AD8018 发表于 2012-04-20 18:32
说个现实问题吧，有没用于检测CPU支持的指令集的library?


自己读/proc/cpuinfo就行了
作者: OwnWaterloo    时间: 2012-04-20 18:35
回复 74# reiase

>>  现实就是这样，基本上所有软件发布时候都是按照SSE2编译优化。

谈jit的优势时用极端条件，谈native劣势时用普遍条件……  这到底算神马……
现实难道不应该是：基本上大部分C#写的软件就是比同类的C++的慢且大？


>> 另外，说OO是C++最微不足道的特性的就是OwnWaterloo

是我啊，而且不仅仅如此。OO自身就是微不足道的，所以它是C++的最微不足道的特性。
作者: AD8018    时间: 2012-04-20 18:36
reiase 发表于 2012-04-20 18:34
自己读/proc/cpuinfo就行了


windows下呢？我查了下，没找到。
作者: reiase    时间: 2012-04-20 18:39
回复 79# AD8018

用CPUID指令
http://baike.baidu.com/view/1829765.htm

我没玩过，你自己试试吧
作者: reiase    时间: 2012-04-20 18:42
回复 78# OwnWaterloo


极端条件是相对的，对一种技术的极端条件，就是对另一种技术的普遍条件。

Paper上的算法无不是拿自己的普遍条件对比别人的极端条件
作者: walleeee    时间: 2012-04-20 18:46
回复 74# reiase


现实就是这样，基本上所有软件发布时候都是按照SSE2编译优化。

是么？请把“基本上”，“所有”这些去掉，或者你自己再想想。SSE2优化？你说得太容易了。

好像JIT就少有人研究了

还是蛮多。
luajit不也很火爆。
jit可是脚本类似语言的救星，救世主。

template不也是空间换时间

有些成分，但是不主要是换时间，换的也不只是运行时间，还有程序员编码的时间。

fftw

没听说过。但是我在他的Features里面没看到jit的任何影子。

之高那么一点点，还没法给其他库链接，有用吗？

我没说有用没用。是你自己前面在表达想用这个功能，然后我想起了给你找你，你又说不需要。我不知道你什么意思。
你现在更是说没用。我实在不知道你到底要什么。

要C语言那种“永垂不朽”的项目

那你给我找个？记住，要和你自己这里说的“要C语言那种“永垂不朽”的项目”unix么？
kde在你法眼中算大项目么？

Qt不算，Qt的C++不是正统C++

qt怎么成了不是正统c++？你凭什么说人家不是正统？就因为moc么？就因为信号和槽？
算了，我不想继续扯这些。

有人说性能是C++的最后稻草

别人放屁你也信了。

有数据能够说明java并不慢，慢的是jvm加载过程

既然慢的是jvm，那好。你是不是想说如果没有jvm，那java就会效率和c++一样了？呵呵，又要马儿跑，又要马儿不吃草，你以为天上掉下来的饼子真的存在？

JIT是治Python问题的唯一药

现有的一些脚本语言，jit效果还是明显。我也承认。

我只是比较期待JIT能够给Python一个大加速

pypy已经表现很出色了。不过一个脚本语言而已，要那么快干什么，我从来不因为性能而去批评一个脚本语言。
因为这个不是他存在的目的。

我不直接用blas，我用的几个库要用blas

我对线性计算库不了解，没碰到需要。所以无能为力。

说OO是C++最微不足道的特性的就是OwnWaterloo

我们原来的讨论似乎没有涉及到OO，所以这里就没必要展开。
作者: walleeee    时间: 2012-04-20 18:52
回复 75# AD8018


我一般搞cpuid

你可以研究cpuz这些
作者: OwnWaterloo    时间: 2012-04-20 18:54
reiase 发表于 2012-04-20 18:33
发布二进制文件时候怎么发布呢？你只能发布给用户p4的二进制代码，这样p4和core 2都能跑。难道让用户自己判断自己的CPU，然后按需要下载？

自己做实验，都用-march-native，反倒不关心p4还是core2。


不能自己判断CPU的人，他们又真在意那点时间效率损失？他们就真不在意空间上的损失？
先退一步假设确实会产生效率损失，这还不一定成立。

一直在用双重标准比较jit与native……
作者: walleeee    时间: 2012-04-20 18:56
回复 76# reiase


你难道不知道二进制分别发放是现在常见的linux打包规范？
作者: 家住马戏团    时间: 2012-04-20 19:06
吵的厉害，不过unixc玩家一贯抵制C++
Linux之父都对C++开过骂。
作者: walleeee    时间: 2012-04-20 20:05
回复 86# 家住马戏团


他那个骂法也被人拿来骂他，以他那个地位和声望在这个事情上也没有占到什么便宜。

unixc玩家无谓的抵制的都是一些用泵而已，真正的高手比较少看到出来直接冲锋，当然也有一些。
作者: wwwsq    时间: 2012-04-21 03:31
本帖最后由 wwwsq 于 2012-04-21 03:32 编辑
reiase 发表于 2012-04-20 18:01
回复 69# OwnWaterloo



C++程序编译的时候，常常是分硬件和操作系统版本的。二进制并不兼容。

Java fans常常连gcc是什么都不清楚，就开始发表高论了。
作者: reiase    时间: 2012-04-21 07:38
回复 85# walleeee


怎么分别打包发放呢？你举个例子

最基本的，Ubuntu有分别打包发放嘛？
作者: reiase    时间: 2012-04-21 08:07
OwnWaterloo 发表于 2012-04-20 18:54
不能自己判断CPU的人，他们又真在意那点时间效率损失？他们就真不在意空间上的损失？
先退一步假设确实 ...


模板实例化剩下的那点寻址时间、循环展开时间，和JIT把一般计算翻译成SIMD指令计算所剩的时间比，很难说谁更有用一点。看场景吧，之前嘲笑过STL号称高性能，却在真正对性能要求高的高并发环境下无大用处，也就拿来加速一下PC机上的MFC程序而已。一种技术，如果只能加速一般场景（对性能要求不高的场景），不能加速一些特例（比如高并发环境）...好吧，你也可以称它是高性能。

“JIT省的那点时间，你重新编译一下也能够找回来”，这种逻辑就跟”模板能省那点时间，你C代码写仔细一点也能找回来“一样，没有意义。

所以说白了，模板（好吧，我不说泛型了）这玩意儿提升性能跟JIT提升性能有啥不一样？算法的逻辑都固化了，内存访问的高效性要考模板这玩意儿保证？
作者: reiase    时间: 2012-04-21 08:48
是么？请把“基本上”，“所有”这些去掉，或者你自己再想想。SSE2优化？你说得太容易了。
回复 82# walleeee

为啥要去掉？哪个软件发布的时候开SSE2以上的SIMD指令优化。所有Linux二进制发行版，你能挑出来几种直接对Core 2+ CPU优化的，哪个分p4，core 2+两种二进制发布的。

有些成分，但是不主要是换时间，换的也不只是运行时间，还有程序员编码的时间。

主要是什么呢？不要扯编码时间，那玩意儿是用调试时间换的。

没听说过。但是我在他的Features里面没看到jit的任何影子。

没有jit，fftw只是在传入数据的时候对数据做优化

那你给我找个？记住，要和你自己这里说的“要C语言那种“永垂不朽”的项目”unix么？
kde在你法眼中算大项目么？

vi和perl算不算。KDE...只是大，而且要不是Qt给C++引入了metadata机制，KDE还不一定啥样呢。你觉得template技术对KDE贡献有多少呢？Qt官方对template技术的看法：http://qt-project.org/doc/qt-5.0/templates.html

qt怎么成了不是正统c++？你凭什么说人家不是正统？就因为moc么？就因为信号和槽？
算了，我不想继续扯这些。

有moc，Qt里的C++才比较像Objective-C。Qt的成功恰恰说明C++的不足。

别人放屁你也信了。

放这个屁的人不在少数，我是其中之一。

既然慢的是jvm，那好。你是不是想说如果没有jvm，那java就会效率和c++一样了？呵呵，又要马儿跑，又要马儿不吃草，你以为天上掉下来的饼子真的存在？

我说JVM慢了吗？我说Java效率低了吗？我只说JVM加载慢。

pypy已经表现很出色了。不过一个脚本语言而已，要那么快干什么，我从来不因为性能而去批评一个脚本语言。
因为这个不是他存在的目的。

”脚本语言“是对Python和Lua的侮辱。快的目的就是为了吧C++挤出市场。这年头Qt都玩Script了，KDE都开始用QML了。Native不是快吗，怎非要跑去用慢的script呢。

我对线性计算库不了解，没碰到需要。所以无能为力。

咱都不是学数学出身，没必要去折腾blas

作者: OwnWaterloo    时间: 2012-04-21 11:11
reiase 发表于 2012-04-21 08:07
模板实例化剩下的那点寻址时间、循环展开时间，和JIT把一般计算翻译成SIMD指令计算所剩的时间比，很难说谁更有用一点。看场景吧，之前嘲笑过STL号称高性能，却在真正对性能要求高的高并发环境下无大用处，也就拿来加速一下PC机上的MFC程序而已。一种技术，如果只能加速一般场景（对性能要求不高的场景），不能加速一些特例（比如高并发环境）...好吧，你也可以称它是高性能。

“JIT省的那点时间，你重新编译一下也能够找回来”，这种逻辑就跟”模板能省那点时间，你C代码写仔细一点也能找回来“一样，没有意义。

所以说白了，模板（好吧，我不说泛型了）这玩意儿提升性能跟JIT提升性能有啥不一样？算法的逻辑都固化了，内存访问的高效性要考模板这玩意儿保证？


你又把话题岔开了。不是在说jit与native吗？
好，你又提到SIMD， native就不能SIMD了吗？


再说你前面提到的发布。
用户不知道CPU是什么，只管下载？可否下载一个小的installer？它负责测试CPU，然后下载相应的binary。
对不知道CPU是什么的用户， 直接下载binary与下载这样一个installer没什么区别， 反正都是下一步下一步再下一步。 哦，还不用装runtime。


现在挺多软件有这样的小的installer，mingw, chrome, cygwin, 还包括你提到的ubuntu(wubi)。
但它们还没有根据cpu选择binary的功能。
为什么？ 至少我还没看出有这个必要。 到目前还没用过什么使用jit的软件效率比同类使用native的要高， 毫无威胁感。

不关心CPU是什么的人， 通常也不会计较、也难以察觉为p4编译的代码跑在了自己的core 2上那点可能的时间优化。
但空间优化是很容易被发觉的 —— runtime比软件本体还大

而关心那点效率的人， 知晓自己是什么CPU是自己的责任。
作者: 三月廿七    时间: 2012-04-21 14:08
c 最成功的项目是 gtk ， 无他
作者: walleeee    时间: 2012-04-21 16:42
回复 91# reiase


你难道不知道自己去看debian？不知道自己去找？我说东你扯西，一会又到了core 2+。算了，我不想和你继续讨论这些问题，想必你也不想和我继续费功夫，因为我点出的问题，你总是用另外一个问题来引开我。这样是无穷无尽的

主要是什么呢？不要扯编码时间，那玩意儿是用调试时间换的。

你难道看不懂中文？还有二字我写得明明白白，你居然就是看不见。
而且你非说编码时间使用调试时间来换，那我真是无能为力了。
你说我能辩么？我一辩，我都能猜到你要说什么，“我就是编码时间短，所以经常要花很多时间调试”，你说我还能说什么好？

没有jit，fftw只是在传入数据的时候对数据做优化

既然fftw所谓优化并非是在jit上，那你扯出fftw搞毛啊！！我们在说jit优化，你突然又来fftw，我以为这个是用来jit来做优化，你现在有跟我说没用jit，唉，我累了。

Qt官方对template技术的看法：http://qt-project.org/doc/qt-5.0/templates.html

这些不重要，一家之言，而且现代的编译器，比如gcc较新版本，对模版控制得也是非当年能比。
算了，我不跟你扯了，你居然又扯出来vi和perl。我不知道你到底想说什么，你对vi和perl很了解么？不是非常了解就不要抬出来，况且抬出来也对你的论调没任何益处。

Qt里的C++才比较像Objective-C

真是天雷滚滚，我已经皮胶柔嫩，你放过我吧。

Qt的成功恰恰说明C++的不足

。。。

我说JVM慢了吗？我说Java效率低了吗？我只说JVM加载慢。

你没说java效率低，我也没说java效率低，我真怀疑你看得懂我在说什么么？我已经三番五次的觉得你根本就没看懂我说什么，或者根本就没看。

Native不是快吗，怎非要跑去用慢的script呢。

对。我已经表述过原因了。我再重复一遍，你看得懂也好，看不懂也罢，同意也好，不同意也罢，无所谓。
现在的硬件已经非当年能比了，效率为优的语言也已经并非当年那么被需要，当时追求效率的领域永远存在，永远需要榨干语言能提供的每一寸性能。计算也已经远远不是当年的认识，现在更多的计算偏移到了日常计算，娱乐计算，这些并非对效率要求非常的高，至少不如之前对科学计算要求得高。这些，以及其他种种因素，导致了你说的脚本语言生命越来越强。这个说法，在我之前和ow的讨论帖子，就是他看不起我看那个帖子里面已经有完整的表达，你可以去翻。

咱都不是学数学出身，没必要去折腾blas

唉。我更是不了解，既然你并非要用blas，也并非对这个非常理解，你把他摆到我们讨论中干什么？况且这个对你的观点无任何的证明效果，你拿出来干什么？觉得我时间多，陪你东拉西扯么？

唉，不必再说了
作者: walleeee    时间: 2012-04-21 17:18
回复 92# OwnWaterloo


cu真是人才济济，说东道西，巧舌如簧。。。所谓乾坤大挪移，凌波微步，神乎其技
作者: walleeee    时间: 2012-04-21 17:22
回复 90# reiase


算了。你这段我就看得出来，你根本不是一路人。
作者: 幻の上帝    时间: 2012-04-21 17:47
回复 90# reiase


看哪个模板不爽改改就是了。
JIT太弱呢？自己写一个？
作者: OwnWaterloo    时间: 2012-04-21 17:55
回复 95# walleeee

不被忽悠是基本功……
作者: walleeee    时间: 2012-04-21 18:00
回复 98# OwnWaterloo


总之，碰到这样的神乎其技的角色，既然他说什么自觉的有道理，那就该追问到底，叫他给一个详细的具体的，白纸黑字的说法。

不被乾坤大挪移这种武功害死。因为就算你内力非人，武功无敌，他什么也不会，就会个乾坤大挪移，你就败局已定了，反倒你内力越厉害，都不过是在打自己
作者: ecloud    时间: 2012-04-22 12:26
你们扯了那么多页没用的东西
归根结底就是回到我最初的观点
优化神马的，作为一个用户，咱们这个层次的，无论你技术多么高超（就算吧），你有什么办法？
大公司只要做点手脚，你就得被迫接受现实，理论那些东西，根本不管用，他要你快你就快，他要你慢你就慢，办法多了去了
IA64就是个明显的例子，理论上的运行效率从来没有达到过。就算Intel改写了gcc，但是他没能力改写所有的库，或者说用IA64的指令集去优化所有的库。而有能力的人、公司和组织，从来没想过去这么做，其结果就是理论上很好的IA64完蛋了

JVM慢不是么？没关系，IBM的z系列机器直接用一种硬件JVM，运行class比COBOL编译成的二进制程序还快。这种东西要是用于Andriod手机，那可真要比iphone快得多了。可是IBM从来没打算过这么做，甚至在p系列机器上都不打算实装硬件JVM

但是从另一个方面，就算现在大型机跑Java比COBOL快了，但是那些大银行还是不愿意把以前的COBOL程序移植到Java。慢点咋了，人家不在乎啊

这就是现实
作者: ecloud    时间: 2012-04-22 12:29
三月廿七 发表于 2012-04-21 14:08
c 最成功的项目是 gtk ， 无他

我觉得是opengl



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2