@wizardforcel

请问你学过编译原理吗？ mul(add(sub(1, 2), 3), 4) 对机器有利？ 有相同的优势？

麻烦你好好读读《 Compilers: Principles, Techniques, and Tools 》先搞清楚怎么抽象和解析语法树， OK ？

mul(add(sub(1, 2), 3), 4) 对机器有利？ 你在讲相声呢。

@GeekGao

怎么举报这个傻 B

@wizardforcel

恰恰相反， Lisp 的价值就是可读。 Lisp 的语法就是语法树，(* (+ (- 1 2) 3) 4) 。这种语法对机器非常有利，机器可以更容易的生成“人工智能”代码。但是，根据摩尔定律，硬件的性能提升每年才一倍，要达到这种分析和生成，还要等到猴年马月。

@GeekGao

你写过 Spark 吗？ 我写过。你用过 PySpark 吗？ 我用过。

别给我再贴你没用过没写过的东西。你就是个 bullshit 。

@GeekGao

真是逗比，你知道 python 在 spark 是什么角色吗？

等一下，你知道 spark 怎么架设么？ 别拿你不懂的东西瞎 bb

@hanfeng3015

Chez Scheme 编译器，借助了 C 的中间码。但是当你做系统调用的时候，比如磁盘 IO ，特别是 seek 的时候，你就能感觉到速度的差别。

@hanfeng3015

错误，听说过 Lisp 机吗？ Lisp 机败给了 C 机器，原因就是速度。

我拿 JavaScript 和 C 来比较。以 64 位 CPU 和 64 位操作系统来讲，在 JavaScript 中所有整数、浮点数都是按照 64 位存储的。也就是说，你存储一个数组 [1, 2, 3]，至少占用 64 * 3 位。在 C 中不是，整数有 8 位、 16 位、 32 位、 64 位，你存储一个数组 [1int8, 2int8, 3int8] 只占用 8 * 3 位，存储 [1int32, 2int32, 3int32] 只占用 32 * 3 位。

懂我的意思吗？当你计算的时候， JavaScript 需要 CPU 扫描 64 * 3 个比特，而 C 呢？

其他更多了，比如数组。 JavaScript 数组是可变长度的。什么意思？ 你存储 a = [1, 2]，然后 a.push(3)。发生了什么？ JavaScript 的解释器先在堆上分配一块大内存（尽可能多，绝对不是 64 * 2 ），然后把 3 放进去。这块内存填满怎么办？ 按照 2 的倍数分配一块新内存，把数据复制过来，把 3 放进去，然后释放旧的内存。

你做了 2 次分配， 1 次释放，而且占用内存还特别大。

C 呢？你存储 a = [1, 2]， a 就不能再变了，它始终分配 32 * 2 个内存。想要堆？使用 malloc() 分配指定的单元内存，然而，它的长度是固定的！这就是效率的秘密。

性能和编写方便，是完全对立的。

@dzhou121

我现在让你写个 web servie ，进行日志分析任务。要求提供分布式存储、观看任务状态的消息队列、实时客户端回馈。你给我用 python 设计设计来。

请问，我该用哪些 python 库可以实现。我的要求高了，我这是一个认真的项目，你给我的库必须是工程级别，经过认真测试应用的，而不是某个菜鸟凭着兴趣爱好摸索的一些实验品。我要求满足：至少每秒处理五千次读请求数、每秒处理一千次写请求数。（这个要求不高吧，顶多算分布式环境入门级别）

==========================================================

看看当今流行语言的 Benchmark ： https://github.com/kostya/benchmarks

Python 就是个垫底的货，写写单机的东西就行了，干干运维就行了，千万别把自己写的 python 程序当回事。

@dzhou121

所以说嘛，用 Python 你就写写运维脚本就行了，别扯其他的，因为你没有这些设施。

@GeekGao

呵呵，你的智商很感人！

@GeekGao

有道理就讲出来，没道理就别 BB 。说一堆无用的废话 P 话，只能显得你很 LOW 。

@GeekGao

源代码就在 Github ，自己好好看明白了。

> IO 阻塞与否跟编程语言没多大关系的， OS 、各类服务 driver 不支持的话，众多编程语言一起哭吧

这句话暴露了你有多无知。对于你这么无知，我现在给你普及一下，好好学着点，就你这水平，也有脸装：

1. 早期服务器市场，只有多进程 fork exec 。

2. 随着 CPU 技术发展，多线程的许多弊端被解决。多进程 fork 在 Linux 上开销很少，但是对于服务器，多线程开销仍然具备更大优势。 so ，多线程服务器出现，典型代表 Apache tomcat 。

3. Unix 系统开发者提出了 NON_BLOCKING 和循环检测技术，开启非阻塞 IO 技术。但是循环检测是非常低效的，需要每隔一段时间就要占用 CPU 进行检查，哪怕这次什么 IO 都没有。

4. Unix 提出 select 内核检查技术，这是替代 3 的过滤检查技术。 select 首先存储所有需要检查的文件描述符，然后提供一个睡眠，把 CPU 资源返还内核。当有多个 IO 时，内核记录各文件描述符，修改 select 存储的文件描述符， 然后唤醒 select 进程，由进程继续处理。然而， select 仍然存在一个严重问题：唤醒后， select 必须按个检查所有存储的文件描述符，有的可能根本没有 IO ，但是也会进行检查，这就造成 CPU 浪费。两个字：低效。

5. Linux 2.4.3 提出 epoll 内核事件通知技术，这是与 select 完全不一样的轮训技术（之间还出现过 poll 技术）。 epoll 分为边缘通知和水平通知（术语自己查）。首先，与 select 一样，存储所有需要检查的文件描述符，然后提供一个睡眠，把 CPU 资源返还内核。当有 IO 时，内核记录所有有 IO 的文件描述符，并且作为一个返回值返回给 epoll 进程，唤醒 epoll 进程。然后，进程挨个处理所有返回的 IO 文件描述符。差别就在这里： select 检查所有存储的文件描述符，其中有的根本没有 IO ；但是 epoll 不是， epoll 是内核返回所有有 IO 存储过的文件描述符，它们都是有 IO 要求，不存在 CPU 浪费。两个字：高效。

6. FreeBSD 随后跟进，引入了 kqueue 技术，其原理同 epoll 有相似之处。

总结： 当前服务器市场，以 epoll 、 kqueue 为主流，性能最好，并发、吞吐量最高。 服务器主要以单进程 epoll/kqueue （比如 redis ）、多进程 epoll/kqueue （比如 nginx ）、多线程 epoll/kqueue （比如 netty 库） 为主。对于分布式服务器，如果你不用 epoll/kqueue ，就直接关门倒闭吧。

另外一个领域：关系数据库，由于以磁盘 IO 和锁同步数据安全为主，大多采用多线程同步 IO 。

前面说错了，“ master 会和 slave 同步锁状态”。

就我的理解，他这是使用多数投票的方式。假设有 5 台 redis ，每台限定取锁时间 30ms 。每个请求取锁的时候，挨个访问 5 台 redis ，至少 3 台能获得锁，则认为取锁成功。取锁总时间超过 30ms * 3 也被认为是失败。拥有锁的时间假设是 1 s ，那么实际可拥有锁的时间 = 1s - 取锁花费的时间。

主要改变内容，都是 master 故障转移和锁在 slave 同步。

集群也没有什么大的改变，仅仅是为了故障转移，锁还是单点逻辑。 master 会和 slave 同步 锁状态而已。

@jjx

你的进程、线程都被 mysql 、 mongodb 阻塞了，还接入更多请求。我问问，你拿什么接入？

@calease

你这水平，根本进不了我的开发组。

@GeekGao

还 IO 多路复用，你知道什么是 IO 多路复用。好好把基础了解再喷：

Unix/Linux select IO: http://123.57.217.180:5555/docs/GNU%20C%20Library/IO%20LL%20Waiting%20for%20Input%20or%20Output.md

Unix/Linux epoll IO:
http://123.57.217.180:5555/docs/Posix%20Library/advance%20io.md