|
|
“六年以来,我一直坚持使用 Windows 开发最适合在 Linux 上运行的应用程序,因为我习惯了使用 Windows,而习惯很难打破——以前我并不是十分清楚我为之付出的代价,但数据表明,是时候做出改变了!”2 {/ B8 n5 ^+ w% |/ E, s$ n0 r2 {
作者 | Sam Saffron5 n$ y9 U8 x4 X6 y
译者 | 弯月2 M- p3 \( T4 X
责编 | 郭芮/ v9 f( i, E- [& F! _3 B% s4 \
出品 | CSDN(ID:CSDNnews)
5 I" N2 z# E. p% x( l" {9 N% L$ ^以下为译文:4 [( x; z1 R1 D0 W2 J% c7 X1 z- R
最近,我的这篇推文颇受欢迎:
v3 G/ h7 ?$ l! o6 w0 h0 ^- t 9 p4 o6 O: c: W5 L7 w( f
我们测试了一下在各种开发机器上运行Discourse的Ruby测试所需的时间,我用亮色标出了我的结果,难以置信这么多年来我坚持使用Windows付出了如此大的代价。+ H$ d6 E4 {& h' d
这篇推文引起了很多人的强烈反应。有人说:“Sam,你个呆瓜,这算哪门子的测试基准?”,也有人说:“这个故事说明MacOS运行Ruby的性能很差。”,也有人只是说了一句:“天啊,不会吧。”
2 \. F& c+ A; G _) o s我想表明的主要观点是:我为“坚持使用Windows”付出了惨重代价。当然,这中间隐藏的其他一些点也值得讨论。0 P& `! T5 S- [1 K( k5 M
: k9 {) k% v8 A为什么你坚持在Windows的虚拟机中运行Linux?
) h9 |) x! `) |7 Y7 s以前我并不知道我会随时为使用虚拟机付出代价,我的电脑上从来没有配置过双启动,所以我没有适当的参考。/ w- \: i* ~) O& W6 Y# g
我非常坚信,许多Ruby / Rust / Go / Elixir / Scala,甚至是一些Node开发人员,他们都使用了WSL,或者在虚拟机上运行Linux,或者在Windows上使用Linux Docker做开发,他们肯定也不清楚其中的代价。 D3 O3 \7 b. s
以我的机器为例,WSL会导致日常运行速度下降25%,而使用基于VM的虚拟系统会导致速度降低38%。5 x5 k- b& d+ c6 X" [( g
我并不是唯一一个遭受这种损失的人,我们团队中的其他人也经历了相同的速度下降,而且外面有很多人也有类似的经历。2 y# y" o* }: T' ~. k1 h
在内心深处,我一直天真地希望我所看到的性能下降很小。如果你搜索一下Google,也会得到相同的答案。用不用虚拟机并不重要,只会造成5-10%的性能差异。也许我只是忽略了一些关键的BIOS设置,也许我需要直接挂载卷,而不是在专用的NVMe Samsung 960 pro上使用vmdk,也许我可以通过一些其他的手段来实现1-5%。也许Hyper-V更好,但我不确定。我所知道的是,我并不是唯一一个这样想的人。! U; q! l. K n1 x
我无法使用WSL,因为根据WSL团队的文档,Ruby中的大量小文件和大量stats调用的性能非常差。有多差呢?作为比较的基准,在WSL上运行rails c控制台(不使用bootsnap)至少需要30秒。同样的操作在Linux上(不使用bootsnap)只需要4-5秒。即使采用了一切规避手段,如此糟糕的IO性能也很显眼。实际上,我宁愿使用速度减慢38%的虚拟机,因为至少一切都是始终如一的,不像WSL那样各方面的性能非常不均衡。在开发过程中,快速启动控制台或Web服务器至关重要。短时间内Fuse也不太可能实现,所以也没办法通过挂载块设备的方式来规避这个问题。
* Q7 J- Y6 Y& @ i) q J5 b所以,我只能坚持使用虚拟机,这样我不需要反复重启电脑,所以我以为代价不会太高。
% {" s) O5 R% R( J: D我喜欢Windows 10的字体渲染,我喜欢HiDPI支持,我喜欢在Windows上使用Lightroom,我还要在Windows上玩Rocksmith。我喜欢它提供的开箱即用的体验,只需要最低限度的定制。我喜欢在启动Skype时不会由于LD_PRELOAD jemalloc而产生段错误。我感觉Windows 10是最好的窗口管理器(对于我的使用而言),远远超过我的Macbook Pro上运行的MacOS。
" A9 a) _/ t' G9 G: q3 _% C双启动是个折中方案,有些东西最好在Windows上运行。我认为我以性能的代价换来了使用一个“熟悉”的OS时获得的便利性,这也算物有所值。. @; V6 W' U; D I+ ^
我感觉如果我不得不启动Linux,就需要处理各种各样的驱动和稳定性问题,而不是拥有开箱即用的一套工具。" C. ~4 D5 P+ q
我喜欢安于现状,我这个人生平最不喜欢改变。
7 r6 y% w) R: P, U* m5 l
5 T* X1 j' Q2 m' }2019年是Linux桌面系统年吗?
7 ?1 c. m( ~& R' I. _4 j+ l这个笑话的起因是:每年都会有一群人开玩笑说今年会是Linux桌面系统年,年年如此。刚开始时总有人说:“最近Linux的发展形势大好,今年是不是可以作为Linux桌面系统年了?”然后就会有一堆欢乐的嘲讽,还有哈哈……别再犯傻了……今年不会是Linux桌面系统年等等。
; B- c+ `4 o" C0 E. f2 V久而久之,这种笑话就传播开了……* N8 X5 [! j0 r( }+ Z, ` d# ]
一般来讲,这些笑话都没有恶意,而且不久就会平息。但是,这个笑话有个巨大的副作用,甚至会对开发人员产生重大影响——不使用Linux作为桌面系统的开发人员会对Linux产生恐惧心理,即便他们的产品在Linux(而不是MacOS或Windows)上运行,他们也会惧怕Linux。
% |2 T% p. F* ^+ j8 X' Z) r而我个人也曾被驱动、字体渲染、HiDPI支持、多显示器支持等东西吓怕了,所以从来没有尝试过Linux。& W; x3 _: v k, ~1 M
实际上,我的害怕并不是没有道理,运行Linux很麻烦。在努力了4~8小时之后,我还是想放弃,因为Linux上的Firefox仍然有一个严重的问题——默认情况下不支持硬件加速,所以翻页非常卡。这个简单的问题就足以让我放弃Linux。如果网页无法平滑滚动,那我就不会使用Linux。幸运的是,这个问题只需要在about:config中修改一个值即可。
; t) j6 [. [9 [1 u8 ~$ i7 ]NVIDIA在Linux上的情况也不妙。Linux桌面系统的未来是Wayland。而我想要尝试的窗口管理器sway只有在使用开源社区提供的nouveau驱动时才能正常工作。就连让NVIDIA正常工作都需要启用硬件组合还要修改X11配置。
# z: w" F1 F1 l5 T6 B O' u9 c我不认为Linux今年能够席卷全球。它没有那么重要。但如果你渴望最佳的性价比,想要在开发Discourse或任何Ruby on Rails应用时获得最佳的性能,那么就不要使用虚拟机,在笔记本上安装Linux桌面系统才是你的最佳选择。
8 A4 H2 D% G G% ]' ]此外,还有一个重要的问题:我在切换到Linux时选择了一条比较困难的途径——我距离从源码安装Linux只有两步之遥。' Q! C9 Q! T! n1 p' x9 J$ S, @
$ G; ^3 f$ O) C; y8 s1 X
与我有类似经历的同事从Windows/Mac切换到Linux,并坚持使用Ubuntu和Linux Mint,他们说切换的过程非常顺畅。
- Y2 W, w) q" _0 @: e3 ?7 D+ I! r. m% l
/ p/ ^2 Y; I- z4 t7 {你尝试过在Windows上运行Ruby吗?
( I7 s& j$ o2 P x+ G几天前这个问题引发了许多讨论。
; G4 i5 ~3 K' w5 T& q6 t
( G. q/ `- Q- H8 Q, ?0 L这个人想说明,如果Ruby能够在原生Windows上顺畅地运行,那么就可以大幅增加Ruby的接受程度,并且可以防止人们转向其他框架。因为安装一个全新的OS是很高的门槛,只是说“安装Linux”并不能解决问题。
; q- ], F$ u# {% @3 @& d: _9 H- j3 h而现实是,在Windows上运行MRI Ruby有两个重大的根本性问题: m ?+ d; Z. W) W
& n' x* Y; Y' A& K: @3 y- Windows上的NTFS文件系统性能十分不适合目前的Ruby设计。我们喜欢Ruby的一大堆小文件,我们喜欢大量的stats调用。0 ]6 n7 N6 [1 v$ k2 d
- 将各种依赖包移植到原生Windows(并维护它们)需要巨大的工作量,因为Discourse的许多依赖根本不支持Windows。gem完全无法安装。根本性的问题是,你必须要付出额外的工作在gem中编写C语言扩展,才能在Windows上运行。而在绝大多数情况下,在MacOS或者Linux上运行根本不需要任何额外的工作。
' b5 d- y& c0 W 第二个问题很容易解决,但考虑到WSL提供的兼容性远远超过了Windows本身,如果文件系统问题能有合理的解决方案(这个问题至关重要,而且Windows下这个问题必然存在),那么可能就不需要大费周折了。Discourse在WSL上运行得很好(只要你不跑unicorn),但在Windows原生的Ruby下完全不能运行。苹果的代价与Windows WSL的代价类似(除了文件系统性能问题之外)。
5 T& u o& s1 U" s* O# |我认为,只要WSL能再优化一些,就足以媲美目前的Mac了。
- s( M* ^2 i7 q6 O
6 i0 k) w7 d( u- X苹果的性能代价
' Z/ G% f5 b5 V) h F从上述性能测试图中不难看出,苹果的性能代价也很严重。
# a* }3 `8 D; X" j仔细观察一下UserBenchmark: Intel Core i7-8559U vs i7-8750H。我们以为8559U的单核性能远超8750H,但是,这台装了Linux的8750H笔记本只用了9分13秒,远胜Macbook Pro的15分16秒。从中可以看出MacOS的性能很差。而且并不仅仅是我一个人有这种看法:# B4 I+ w2 y& I

4 j( t# m3 H. F, d0 a9 | C
/ H* W C$ N% f5 i+ _似乎人们坚持认为原生的MacOS体验正是在Mac上开发Ruby on Rails时需要付出的代价。, E3 K. c8 |, E9 K# _$ U# p ^4 t
我知道DHH非常喜欢iMac Pro并极其推荐。; {9 [2 R$ R/ `! i4 v* a

# O2 s' r! t/ Q6 W没错,它的硬件非常优秀,屏幕非常漂亮,机器本身也非常好。窗口管理器也很不错,也没有驱动问题。但很不幸的是,在MacOS上进行Ruby on Rails开发依然需要付出不可忽视的代价。+ g6 h$ q) f5 o3 }; b; K( s
我认为Ruby社区应该调查一下这个问题,记录该问题的各个方面,看看能不能有所改进,让Darwin的性能接近Linux的性能。这个问题是源自文件系统?操作系统?Ruby使用的llvm编译器?还是MacOS的安全特性?是否跟Spectre+Meltdown有关(这个问题在Linux上已经打过补丁了)?目前来看原因依然不明朗。
+ X3 q: p6 M6 C# |0 @因此,如果你在Mac上双启动安装Windows,然后安装WSL,通过Mac+Windows+WSL的方式在运行 Discourse测试套件时获得更好的性能,我完全不会感到意外。而且我敢打赌你肯定会这么做。
$ o8 Z$ P, i! B3 k: T0 G! f" `. I所以,如果遇到有人说:“还有一个办法,安装黑苹果就好了”。你可以告诉他们,这样做不仅在每一次MacOS系统更新时你都需要冒险,而且也同样要付出与Windows类似的代价。' M# j7 y# p' t9 f' X4 A5 J
: m( G$ y4 J0 O- ^) p4 b: F, f并行测试怎么样?/ X! ~4 ~9 `2 s0 w/ {
Rails 6马上就要发布了,这是Rails首次拥有官方支持的并行测试。我在Linux系统上运行Discourse的测试时,整个过程用了8分钟,期间CPU的使用率不足10%,IO也没有达到饱和。
& A4 `& l, q. y" d所以,当我得知在Windows机器的虚拟机中,即使性能下降了38%,并行运行也能在两分钟内跑完测试时,我感到十分震惊。
# s6 H+ m, [; J4 H# g- H5 q, x所以,前面大费周折,却放着这么明显的问题视而不见,这不是很奇怪吗?& l; J n* Y$ b/ g* e7 Q9 W7 ]: s
我完全同意,Rails的并行测试非常出色,相信很多开发人员都会非常高兴。) Z8 v/ q8 Z! H. k
此外,对测试套件进行性能评测,同时干掉速度过慢的测试用例也十分重要。
$ z/ d/ H y5 p$ u我们将在开发环境中采用并行测试。
# c) O( r' s" X但这不是重点。我面临的问题在于,一直以来我的机器的运行速度都被钳制,所以就算测试的运行速度非常快,放到我的机器上依然无法发挥到极致。
9 u7 d2 c" n; J; y3 v! p
( f% _5 w0 L' ~( s7 _7 ]今后的选择, I4 j' v7 P1 ]+ T
目前,我对家里的Arch Linux很满意。现在不仅程序运行速度加快了,而且由于我使用的窗口管理器远胜mac或Windows,我的工作效率也有所提高。当然代价还是有的,以前使用Windows时不需要考虑的很多问题,如今都需要解决,但是回报也十分丰厚。
4 P- Q: s' t. L! S0 q' ~4 f长期以来我一直在使用i3wm,但从来没能下决心在两个窗口管理器中做出抉择。如今i3是我唯一的选择,我从中也获得了丰厚的回报。我的计划是每隔几个月就尝试不同的平铺式窗口管理器,直到找到最适合我的那个。
6 n& z. S1 J* Z8 C9 q6年以来,我一直在坚持使用Windows开发最适合在Linux上运行的应用程序,因为我习惯了使用Windows,习惯很难打破。以前我并不是十分清楚我为之付出的代价,而且我觉得许多开发人员也跟我一样。" {2 A* P2 r+ K! b, ~
我只有一条建议,那就是……不要害怕尝试。Linux的桌面系统越做越好了,在硬盘上划一个分区出来做成双启动也十分容易。如果你和我一样在两个世界之间举棋不定,特别是如果你使用的是台式机而不是笔记本,那么还是建议你尝试一下。
/ k, q i3 b) I欢迎留言分享你的评测结果和经验。希望看到更多在同一台机器上比较MacOS和Linux的评测结果,以及Windows+WSL/虚拟机和Linux的评测结果。* S+ x' H b6 M5 D0 n! @& t
原文:https://samsaffron.com/archive/2019/03/31/why-i-stuck-with-windows-for-6-years-while-developing-discourse5 b( Q# p7 K6 b* W/ r
本文为CSDN翻译,转载请注明来源出处。
- o0 X3 q: J( m3 r7 P8 k& H【End】* D) N0 }: H, m l
" }* u+ _ }2 j7 H" |: S6 x7 {
热 文 推 荐
2 |1 k8 W5 V% U1 H% ]$ l2 f% r( u& s6 Z! V. Q' _0 S5 Z
戳他↓↓↓, U, H; A3 @# i% @) r9 I

( _4 G0 B2 I* T$ v1 d1 M; b0 s B" Y& _ p; Q% e
System.out.println("点个在看吧!");
0 v R) ^- B8 |0 R8 W9 V: K! L4 d5 Cconsole.log("点个在看吧!"); G* K* o3 C$ [
print("点个在看吧!");2 W5 c+ ~! F$ E9 X& V) s# J( O" b$ u. a
printf("点个在看吧!\n");: L: S" J- A, |/ P. x4 P5 y
cout |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
×
|