• 别介意~

    我没有别的意思,用什么无所谓,所有语言几乎都能解决同一个问题,就是运行速度(执行效率)、开发效率、平台特征等等比较而已,无论是哪个工具,存在即合理。

    “也许你是看不惯我贴了自己 Blog 的外链吧”,我没看到呀,现在才反应过来。我不介意,不过我看了原文,对比了一下,感觉你是不是把原文的东西改了一些?

  • 嗯,文中说了半天很基础的并行方案,到最后还是叫人家去用 Erlang 了。。。

    其实我是能理解的,因为我尝试过越过 GIL,后来发现这样还不如直接用别的语言来得快。

    这样的文章很灰色,也能加精。。。真的好吗?

    文中说的竞争的情况主要在 IO,然而 IO 是不由 GIL 堵塞的,在我另一个 @luikore 的讨论帖子中有陈述。另外就是,GIL 解决的是线程安全,保证这个时间只有一个线程去处理现场。竞争问题,我的观点是:它只是打乱了 Thread 们的执行规律,按照 priority 优先级执行。也许你对资源还没操作完,就已经下一个 Thread 开始执行了。

    这时候加锁会有帮助,让你把资源锁起来,先做完特定步骤后在让别的资源用,但是这样就堵塞了,因为在你锁住的时候,你把别人堵塞了就有点串行的味道了。

    无论怎么说,Ruby 还是有它挺有用处的地方,在 IO 密集的应用还是有优势的,但是我觉得 IO 密集的程序。。。反正我是碰不到,而且 GIL 本身已经有点减速的效果了,就算应对 IO 密集,也轮不到 Ruby 去处理。

    反正我个人觉得 MRI 是 Ruby 中规中矩的实现语言,其实它的语法糖还是挺好用的,重点是很舒适,特别喜欢。站在这点,你跟我比较它的并行、效率,我觉得牺牲这些去获得更高的使用体验也无所谓。

  • 另外还有一个问题,就是我坚持用 pthread 再注册能不能绕开 GIL ?

  • 谢谢,我看这些在很多网站都找不到资源,也不知道怎么解决,不过你倒是帮我解决了这个问题,再次谢谢~

    其实当时我已经意识到没有 mark 那个变量,然后尝试各种手动删除,但是翻了半天没找到方案。

  • LZ fork 是指 Thread or Process?

    另外,在后端开发的编程观念里,业务逻辑用多线程是没有意义的(除非异步 IO,先返回后存储,或者除非你写服务器)。

    在一般场景中,因为你要 response 客户端,但是你开线程去执行的逻辑可能 request 已经 response 了,而 result 没拿到,结果 response 了没有 result 的结果。

  • 再次回复:

    终于抽时间写了个 test

    require "benchmark"
    
    result = Benchmark.measure("normal") do
      100.times do
        f = File.open("/Users/***/Downloads/***.dmg", "r")
        s = f.read
        f.close
        # p "finish #{s.length}"
      end
    end
    
    p result
    
    result = Benchmark.measure("concurrent") do
      threads = []
      100.times do
        t = Thread.new do
          f = File.open("/Users/***/Downloads/***.dmg", "r")
          # p f
          s = f.read
          f.close
          # p "finish #{s.length}"
        end
        threads << t
      end
      threads.each do |t|
        t.join
      end
    end
    
    p result
    
    while true
    
    end
    

    运行结果:

    #<Benchmark::Tms:0x007fecde927d90 @label="normal", @real=0.2543760000007751, @cstime=0.0, @cutime=0.0, @stime=0.24, @utime=0.010000000000000002, @total=0.25>
    #<Benchmark::Tms:0x007fecde917648 @label="concurrent", @real=0.1437469999982568, @cstime=0.0, @cutime=0.0, @stime=0.31000000000000005, @utime=0.020000000000000004, @total=0.33000000000000007>
    

    证实以下结论:

    IO 是不堵塞的

    没什么太大的好处,但也并不是完全没有用,刚比较了一下,小并发,还是比较快的,但是数据量一大就不行了(因为 Ruby 都是把数据不管二进制还是字符流存在 String,数据大了很卡)。。。

    另外,IO 密集的程序应该是做日志系统吧。。。但是日志系统一般都有逻辑,而不会直接就执行一行 read 和 write,所以还是没有优势。

    不过如果是简单的日志系统,单线程的,那还是比较有价值的。

    适用场景:个人博客(基本不涉及计算,而且偏向静态所以多数都是 IO 操作)、展示型网站、bug 追踪系统、工作流系统。

    GIL 让密集计算串行起来其实让开发者更安心用多线程,其实“并行”还是有的,只是模拟(通过给定每个 Thread 执行时间作业),对于非高需求的开发者,实际上这样可以降低开发难度(满足简单软件开发)。所以也是满足了这门语言适合对 CS(Computer Science)不 Geek 的人群使用。

    另外,一开始是我用 C 多线程来改写了 amber-kit 项目部分的代码,后来发现把 Ruby 的 VM 弄死了(回去再补图)。所以才在 5 楼回复了一下,结果被楼上楼下的各种误会(其实没有人知道我做了什么)。

    在 C 多线程 pthread 下,MRI 或无法回收 pthread 里面执行的堆栈的 VALUE,混编需要注意这点。

    然后跑了 1000 个并发(其实没到 1000,大概在 200 - 400 左右)就挂了,然后报错 segment fault,一堆 ruby gc 相关的错误 trace 就出现了。

    其实我只是想绕开 GIL,但是还是失败了

  • Thank you very much~ That's what I need

  • unicorn 跑 MRI,puma 跑 JVM,因为前者多进程,后者是多线程(我看了源码,是客户端 waiting full 的 Thread_pool),多线程在 MRI 有 GIL,相当于没并行,加上IO会堵塞(除了 IO 会释放),所以(基本)是串行的,那样环境下的 PUMA 等于(不亚于)单进程单线程。 楼上说的代码线程安全,加锁就好,另外,多进程有缺陷:互相之间超难通信,过程复杂,而且传输的东西有时候不全(用 pipe + marshal)

  • 马克,今晚回

  • 以前没有成熟的方案的年代,人们不是推这个就是那个语言,当解决方案已经遍地、市场已经洗牌了之后,人们开始寻求更好的解决方案,然后新的解决方案有新的市场,然后继续洗牌,最后剩下的就那么几家。

    上次我发的关于 TM(TextMate)是不是已经淘汰的相关讨论,其实也就是这样,自从 Jetbrains 以后、机器性能提升了好几遍之后,谁还会因为担心卡啦、慢啦去用 没有任何社区模块支持的 barebone 文本编辑器?

    5年以前还可以说用 Notepad++ 写代码,因为当初人类对编辑器的意识没有那么丰富。

    不是还有一篇帖子嘲讽 如何退出 VIM?

    我觉得前端在某些功能取代后端去完成,是更自然的事情,因为有些功能本来就应该前端完成,只是当年 ECMAScript 没那么强,但是随着 The Art of ECMAScript(这个词汇来自于 TypeScript 的视频)发展,后端有些功能真的就应该客户端来做,比如界面谁来确定的,肯定是客户端。

    从很早以前,本来就应该是前端去确定界面的逻辑、功能,只是上个 Web 2.0 时代 JS 没那么强,人们更喜欢动态用后台提供的数据(HTML形式)去构建界面。

    就简单来说,10年以前我上初中刚开始学网页制作喜欢用document.getElementById(),有且只能通过 ID 筛选,虽然不同浏览器加入了自己的特性,但是在别的浏览器不兼容,就算你开发出一套库也要时间,总之就是生产力还上不去。

    现在随便 querySelector $() 一大堆。。。我就不举例了。。。

    我以前写过一篇文章,很多程序员是怎么来到这个行业的,很多都是为了淘金,淘完了转身就走了。

    所以,如果你是打算淘金的话,建议你不要学习钱景不好确定的 Ruby 和 Rails。

    在上一个年代(世纪),那时候很火的就是汽车维修技术啦、厨艺啦,但是坚持到最后的人有几个?

    千万不要学半路就走人,不然你就不学,因为你没有诚意走完这条路,或者说你只是因为羡慕别人从这条路终点摘个果所以你去摘而已。

    腹黑地讲:

    如果已经深入泥潭的,发现走不回来的,我还是劝你别回来了,因为你还不如继续深陷下去,还能作为肥料养沃泥土,或许你还能成为个准专业人物,不然你要起身的话动作幅度太大,力气也要很大,而且上了岸你还要重走很多本来想走的路。。。而且或许你已经跟不上了。。。

    也许。。。

    这就是所谓“脱坑”的定义了,也难怪他们用一句“进坑容易脱坑难”把它说这么难。。。

    如果你只是看到一些爱装逼的“自称”或者被人“冠以”大神的所谓某某某。。。

    请务必正确选择自己的道路,不要被各种雕虫小技吸引,不要被某些“大哥大姐”拉拢,更不要随便叫别人师傅,除非你真百分百确认、永不后悔地打算一直走下去。

    因为:

    花花世界无奇不有,首先请了解你自己现在该做什么,然后请做你自己的事情,请务正业!(不要别人干什么你又羡慕什么又去干什么,别到时候一事无成一无所得)