• 原始的 issue 下通过开放地址法写了几个 candidate,针对这几个 candidate 的 benchmark 实在是非常玄妙。

  • 这个程序能上传视频吗? at 2017年3月10日

    我最近打算写一下,感觉直接对接 CDN 的话不是太麻烦

  • 花了半个月捡垃圾 at 2017年2月14日

    #8楼 @ywjno X5690 真的发热惊人。。。TDP 比 AMD fx-8350 还大。。。

  • 花了半个月捡垃圾 at 2017年2月14日

    #4楼 @ywjno MC560 的话改装难度小好多,不过 CPU 是单路的。

  • 花了半个月捡垃圾 at 2017年2月14日

    #5楼 @cxh116 北桥还好,只有 40°C 左右,我北桥芯片上就带一个铝制的散热片可能解决了很大问题。还有就是机箱风道设计得好的话整机温度还是很稳定的。就是这 CPU 待机 45°C,满载也不过 55°C

  • 花了半个月捡垃圾 at 2017年2月14日

    #1楼 @huacnlee 这 5000 里有块全新的 GTX 970 就占了近 2000,还插了块 SSD。主要是这俩是我房间里翻出来的,没有单独买,否则压缩一下预算还是可以的。只是这核心数和这内存大小用来跑很多纯并行运算真的很爽(逃

  • midori 百日记 at 2017年1月17日

    #28楼 @luikore mruby 下的线程栈还挺小,但生态太糟糕

  • midori 百日记 at 2017年1月16日

    #25楼 @gihnius 很多稳定性问题主要是 eventmachine 本身导致的,而不是异步。我也打算在下一个大版本中把基于 eventmachine 的绑定改成基于 nio4r 的绑定。rust 线程比 gorouting 快很多,但是 rust 上基于的 tokio-rust 的网络通讯会比线程更快。扯到 IO 的时候,只有在完全解决阻塞的情况下,问题才会落在内存、网络、磁盘上,一旦出现线程阻塞,那性能必定是非常糟糕的。异步的做法就是用来解决阻塞问题的,但是异步的做法代码很难看,这才是这几年很多语言设计都在极力克服的问题。高性能的 Web 服务器,从 Apache 到 nginx 没有一个不是在使用 I/O 多路复用技术来解决问题,甚至连使用哪种复用技术都经过了几代的改变,更不要说单纯同步靠创建线程来解决 I/O 导致的线程阻塞,运行效率实在是太低下。

    IO 密集型还是用线程。

    这种表述实在是难以苟同,你基本找不到单机 10k 并发以上的应用是通过纯线程来解决的,因为单纯靠创建新线程,*NIX 线程创建的性能代价是极大的。

  • midori 百日记 at 2017年1月14日

    #23楼 @mizuhashi 在多线程下不会阻塞是指,他们在多个线程连接数据库的时候互不阻塞,但对于当前线程就出于阻塞状态了,我在实现 pg 的 adapter 的时候就发现了这一问题。主要是大家没有共享同一个 event loop

  • 有点奇怪,既然是 Let's encrypt 的证书,为什么不直接申请呢?在又拍云上申请 Let's encrypt 证书有什么区别?