lvsoft

@reus OK。bash + C是通过binary link还是通过process exec？如果是binary link，那么压根就没有多少bash扩展。如果是通过process exec，那么性能极差。无论哪种，都能说明你所举的bash例子没有任何意义。按照你的定义，pure bash下你几乎啥都做不，别说甩9条街了。

python不调用gevent，就算用raw socket最终也要调glibc的。java也是一样。
不然怎么创建fd？怎么进行网络IO？那么按照你的意思，这个“使用C”的边界到底在哪里？凭啥python通过gevent调用epoll就是调用C，jvm通过glibc调用epoll/select/what ever就不是调用C？

讨论问题，大家首先得在一个公理系统内，不然就是鸡同鸭讲。所以说，你首先得给出一个令人信服的边界。不给出边界，不做出明确的定义，直接做各种无意义的类比，我只能说你是来搅浑水的，当然不要怪我说你没节操了。“没节操”这3个字也没有上升到人身攻击的高度，这只是对你这种做法的吐槽而已。

我给出的判定依据很简单，假设你只会java，我只会python，再来一个只会bash的人。大家都不会C，更不懂得怎么写C extension。在这个前提下谁的解决方案好就是谁好，这个判定依据很合理，也具有实际意义。

你不同意，那么你倒是说个更合理的判定依据呢？还是说你只会一味的说这个方法作弊？

就算是你说什么作弊，那jvm不是在某些benchmark中比C还要快嘛，有什么好怕的呢？
或者按照你这种必须完全得pure code的标准，我是不是可以认为jvm通过jit编译成native code，用native code替换pure code实现也是作弊？

最后，我没有说cpython vm比jvm效率高，我说的是overhead低。而overhead高的原因有很多，光举一个动态强类型对比静态类型的说法没有意义，而且这个问题要说清楚太折腾，都可以另开个话题了。
所以，我对你的吐槽，完全是针对你举的bash那个例子开始的。咱先别急岔话题，先把这个问题说说清楚，OK？

@reus 我完全理解，而且我觉得你就是在为了坚持你的观点而坚持，所以才说你这个已经是节操问题了。

你用bash只能通过进程通讯使用C啊，bash以进程间通讯调用C的pure bash代码性能有多差你应该有概念吧？你给出的解决方法是用C完全重写你所需要的应用，然后用bash在最外层调用。那你99%的工作量都在c里面，这个还能算是pure bash代码么？

gevent的例子里面，哪里有C程序？所有我要写的代码都是python代码啊，gevent自身用c实现的关我什么事？python自身还是用c实现的呢，python vm的loop还是在c里面呢？你去关心这些干嘛？按照你的理论那是不是所有python的优势都可以归功于C了啊？

所以最终没啥标准不相同的啊，大家都只以pure code比较。java下只写pure java，python下只写pure python，bash下只写pure bash。允许你调用各自的第三方library也好，第三方module也好，第三方的什么东西都行。都是各自所属的生态链上的东西，凭啥不能调用？

在此前提下，至少在这个gevent例子里，python是最优的，你说python是因为libevent也没错，但也这只是理由之一，难道python的轻量级设计思路，比jvm少了一层封装的设计，导致比java overhead少，难道这些不是真正的原因？否则java为啥不能模仿？为啥不自己基于epoll造个轮子也好，基于jni调用libevent也好，java为啥不这么做？或者说为啥这么做了也没用？

@reus ...我不是说不算啊...我说了你完全可以用bash调用各种各样的c实现，一行c代码不写来解决问题。只要你这样的调用方式你喜欢，并且实现性能足够高就行了，可实际上你做不到啊。连浮点运算都得通过bc来搞，快的起来么？然后你又说那直接全部用C写了bash来调。那你不还是碰C代码了么？这个不是标准相同不相同的问题，这个是有没有节操的问题好不好？

@vicalloy 这个说到点子上了。但是回到我之前的观点，在企业级应用中，IO才是瓶颈，架构设计是否合理才是问题的关机。很少有python性能成为瓶颈的地方。真遇到这种少数场合，那么极端场合当然需要极端的技术来解决，这方面python也有cython这种比java/jni灵活性高的多的方案。

@reus 问题是这些回复我没觉得有什么硬伤啊。你那样全部用C写才是比的纯C程序呢，gevent的核心loop基于C又没啥问题啊，你毕竟写的是python code，一行C代码都没写啊。python作为胶水语言就是这么用的，或者说python就是为了这种使用模式而设计的。同样是在各自语言框架范围内的解决方案，仅仅因为底层实现不同，凭啥不能对比啊？JVM最终好歹也是用C++实现的，我能说java性能高是用C++作了弊的么？

@reus 如果你觉得用bash调用C写程序很爽的话，你当然可以说bash可以甩java九条街了。事实上几乎没有人来为bash写c扩展。bash只能调用可执行文件，以exec来执行C程序。bash本身作为语言的能力狂弱，连浮点计算都要用bc来算，你一个bash脚本里面要是bc用的多了一点，程序慢的跟死机似的。你这个例子完全就不对。

最后，不知道你们怎么扯到速度上的。企业级应用，CPU都是富裕的，瓶颈在于IO。无视IO只考虑程序本身是跑的快10倍还是慢10倍，压根就没意义。