[email protected]:~$

  • ruby vs python benchmark

    写这篇的目的是下次在看见有人认为ruby效率比python低时我可以直接贴给他链接.. 鉴于很多人用ruby1.8来benchmark说明ruby效率是多么低下,我使用了ruby和python标准实现的最新稳定版本 ruby -v ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux] python3 --version Python 3.3.2 使用传统的fibonacci来benchmark #ruby require 'benchmark' def fib n if n < 2 1 else fib(n - 1) + fib(n - 2) end end Benchmark.bm{|bm| bm.report{puts fib(35)}} #python import timeit def fib(n): if n < 2: return 1...

  • ruby中的lambda为什么是Proc类

    当然写之前我试着在网上搜了下, 果然没有搜到类似的问题。 lambda为什么不是Function, Method 而是Proc ? 这个问题当然没有标准答案,于是我做了一番推(猜)测 lambda和proc都是Proc类,这样已经可以看出一些端倪,proc既然叫proc当然是Proc类的主角,所以lambda只是Proc的一个附属,因为已经实现了proc,所以就顺手实现了lambda。 proc是用来代表block的(双飞燕中的话是proc更接近block), 如果我们在参数中用&block,我们会得到一个代表block的proc对象, 并且proc和block在各种行为上几乎都是一致的。 再来看下lambda,双飞燕中说lambda更接近method 当然…其实他们的区别是很大的,ruby中method必须bind到一个object上才可以调用,method(消息)必有接收者 而lambda就很异端了,仅仅是一段可执行代码,没有什么可与之对应的(python中的method可以对应为第一个参数为self的lambda) 而与proc的区别仅仅是传参和上下文跳转上更像method,并且在block的压力之下几乎没有任何用处.. “虽然很鸡肋, 但是实现上很简单(把proc稍微改下?) 干脆一起实现了,说不定谁可以用得上” -————————-(我猜测的实现lambda时matz的想法) 于是就同归于Proc类了

  • 突发奇想, 试下celluloid + eventmachine

    前几天benchmark了下ruby中比较有前途的websocket-server(reel和em-websocket),结果是eventmachine完胜.. 而且发现reel有个很严重的问题,打开的文件描述符有一部分不能释放,于是造成打开的文件越来越多 https://groups.google.com/forum/?fromgroups=#!topic/celluloid-ruby/4btMSHIcjj4 mail list中问了下, tony说是我用法不对,但是我按照他说的用了detach还是会有此问题 但是如果使用em-websocket来写server的话难度的确是很大, 多线程环境很容易出问题, 于是我想如果有个能运行在eventmachine thread pool里的轻量级actor库就好了。 于是花时间研究了下如何实现,结果发现同步是个大问题 调用异步的actor没有什么问题,让他在pool里执行便可,但是如果同步的调用,那么当前的线程必须要阻塞住等待结果返回,可能阻塞住pool中很多的thread, 如果引入fiber进行异步的回调,则必须保证当前actor在fiber结束前不能被再次执行 class Player ... def ... @mp = ... @hp = ...#假设是异步计算的代码, 如果在fiber.yield之间有其他任务执行 #可能会造成数据不一致 ... ... end 于是需要引入exclusive之类机制 这样实现的话就偏离了轻量二字,而且更关键的。。这简直就是celluloid啊。。身为ruby程序员当然不能重新发明轮子 于是干脆使用eventmachine + celluloid这种形式,由em-websocket进行异步的io,然后celluloid并行的去执行代码, 而且还有个好处就是因为每个链接分一个线程,所以完全不要担心阻塞em-websocket的线程,在actor中可以尽情使用阻塞io 至于效率就交给传说中JVM上很屌的抢占式线程调度吧 于是这里是‘成品’