• Re: 丰田混动没法跟本田混动比了吧

    不要光迷信传动,电子系统调教才是好玩不好玩的关键因素。又不是光看直线加速的,拐弯的时候动力分配才是最重要的

    【 在 figo2008 的大作中提到: 】

    : CVT的变速箱吗,是的话混动,虽然能敏捷点,还是不能太急加速,毕竟CVT太弱鸡。

    今天 16:01
  • Re: 丰田混动没法跟本田混动比了吧

    据说最新的混动 nsx 极具驾驶乐趣,比纯油的有意思多了

    【 在 figo2008 的大作中提到: 】

    : 油价低了, 只考虑成本,混动回本更慢了。不过本田混动还有驾驶乐趣的提升。

    今天 15:38
  • Re: 丰田混动没法跟本田混动比了吧

    用发动机撞后备箱有什么好比的,你要是觉得你的车行的话,你可以把你自己的车放那被撞一下试试

    【 在 sor 的大作中提到: 】

    : 奕泽刚撞思域

    今天 15:35
  • Re: 靠!我真是跪了美国人了!不服不行 (转载)

    传染病最重要的是,感染率最高的是医护人员,然后造成更大的影响。比如普通人感染率万分之一,医疗人员感染率百分之十,这个比例一点不夸张

    今天 14:59
  • Re: 帮我算个数学题

    嗯,至少你可以学阿Q精神胜利

    【 在 siegfried415 的大作中提到: 】

    : 随便你,不会再回你了。。。

    昨天 18:46
  • Re: 帮我算个数学题

    但是即使再烂的ssd,4K读写也能达到每秒好几兆的速度,换算成4K的话就是好几千个文件。

    我的观点从来没有变过,那就是日常生活中的操作根本用不到4k 64thd,而你用的例子根本不能反对我的观点

    【 在 siegfried415 的大作中提到: 】

    : 我想反驳的是你的“用小文件的总长度来估算读取代价”的方式,任何人都知道,拷贝一个rar文件可能需要t秒,那么解压缩后拷贝,则需要的时间远远大于t/压缩比,文件越小数量越多速度越慢。

    : 这就像两个人辩论,当一个人说1+1=20,那么这个讨论就完全进行不下去了一样。。。

    昨天 18:10
  • Re: 帮我算个数学题

    就算再慢,几万个文件10秒钟也能读完。你要不要写个代码试试?

    【 在 siegfried415 的大作中提到: 】

    : 我发现你真是一个外行:

    : 编过系统程序的都知道,小文件的读写是非常慢的,因为小文件读写的主要开销是花在系统调用的上下文切换环节上。说句题外话,被面试人如果用小文件的总长度来估计大量小文件操作的总开销,说明你对OS一知半解,肯定通不过我的面试的。。。

    昨天 17:26
  • Re: 帮我算个数学题

    1. 无论怎么说,几十秒内对比完上万个文件的瓶颈都不在iops上,如果文件小的话,比如每个文件4KB,上万个文件才4MB,即使单线程也能搞定

    2. 你告诉我异步文件IO?文件没有异步IO谢谢,无论是select/epoll/ev,都不支持文件,只能用在网络/管道上

    【 在 siegfried415 的大作中提到: 】

    : bc不是stat,而是读两个文件,然后对比,并将有差异的部分写入到文件中。至于你说git不会开几十个线程(并因此推断很多操作都是非并行的),我只是想说你很外行,现在操作系统和系统开发平台(比如twisted等)已经可以很好地做到异步IO了,根本不需要多个操作系统线程就可以产生大量异步IO请求了。

    昨天 17:04
  • Re: 帮我算个数学题

    几万个而已,真要算起来stat一个文件几毫秒的话,一个线程几十秒也能完成。你再想想服务器,一个进程每秒钟能接受上千请求,光写日志就写上万条,然后再乘以几十个进程。这才叫io密集型

    至于 git,你觉得 git 会开几十个线程出来吗,很多操作都是非并行的。

    至于编译,实际上是一个CPU密集型操作,一个进程访问文件的时候也是顺序的,实际的并行程度不会超过CPU核心数,而且大部分时间是耗在计算上而不是io上了

    【 在 siegfried415 的大作中提到: 】

    : 我经常用beyond compare对比两个目录,这两个目录中可能有几万个甚至几十万个文件,bc能做到在几十秒之内完成几十万个文件的比较,你觉得在这种情况下,操作系统会会不会每秒钟发出成千上万的读写指令?然后这些指令为什么就不能在ssd中被分配到不同的队列中来并行的去执行呢?

    : 类似的操作,还有打包,压缩和解压缩,备份与同步,编译内核,git操作等等,都涉及到大量的小文件的读写,你怎么知道这些操作无法利用ssd的并行读写能力呢?

    昨天 15:29
  • Re: 帮我算个数学题

    我没有告诉你说更多的CPU可以进行更多的读写,我只是说4k 64thd对民用场景没有意义,因为根本用不到

    【 在 siegfried415 的大作中提到: 】

    : 大家最希望听到的就是为什么更多的CPU就可以进行更多的并行读写,因为毕竟SSD的读写控制是由SSD的控制器来构成的,而又不是由CPU来进行的。

    昨天 14:42
  • Re: 帮我算个数学题

    服务器场景有更多的CPU核心啊,内核也可以针对性的优化io调度;而且服务器大多数时候做的都是重io轻计算的操作,这也是为什么cpu核心多而频率较低

    【 在 siegfried415 的大作中提到: 】

    : 你始终没说清楚,民用场景和服务器场景究竟有什么不同,导致了一个利用不了,而另一个就能利用上。这种差别是质上的?还是只是量上的?

    昨天 14:25
  • Re: 帮我算个数学题

    我只是说,民用场景4k 64thd没有任何意义。直接的读写ssd,这个场景太少了,再怎么并行读写,接口就一条通道不是么

    【 在 siegfried415 的大作中提到: 】

    : 那你的意思是,应用程序无法通过OS直接利用ssd的并行读写能力了,是吗?那为什么服务器上的应用就可以通过OS来对ssd进行并行读写?

    昨天 14:01
  • Re: 帮我算个数学题

    跳过文件系统直接访问硬件啊,有什么问题么

    【 在 siegfried415 的大作中提到: 】

    : 那按照你的说法,那测试软件上是如何实现4K/64 thread 测试的?

    昨天 13:47
  • Re: 帮我算个数学题

    因为不可能啊,首先操作系统有缓存的,其次p2p软件即使同时开几十个线程去上传下载,也不可能同时挂起在io,再次即使同时打开几十个文件,文件系统驱动也会把请求排队的

    【 在 siegfried415 的大作中提到: 】

    : 你为啥觉得P2P下载的时候不可能达到几十个硬盘IO操作同时进行?

    昨天 12:20
  • Re: 大梁后部被切割的车还能开吗?

    不能,因为你不是保险的投保人和受益人,所以理论上你只能磕责任方。。

    【 在 Dirk 的大作中提到: 】

    : 不靠谱吧?您说的这个办法实际能操作吗?

    昨天 11:52
  • Re: 大梁后部被切割的车还能开吗?

    保监会投诉啊

    【 在 Dirk 的大作中提到: 】

    : 跟谁提这种要求?提了也没用啊,对方保险公司才不会理你。

    昨天 11:35
  • Re: 大梁后部被切割的车还能开吗?

    要求恢复到原样,不然就报废

    【 在 Dirk 的大作中提到: 】

    : 那么以后遇到这种事故有什么好的善后处理方式吗?第一次被追尾那么严重,没有经验,对方投保的保险公司很小,叽叽歪歪,指定了一个4S店维修,就过去定损维修了。维修费2万多让对方保险公司报了,但现在才知道切割大梁影响那么大。

    : 我自己查了查,总结了以下几条,大神给看看靠谱吗?

    : 1.似乎很难找肇事者要折旧费,哪怕是新车。

    : ...................

    昨天 11:25
  • Re: 81192,请返航!

    水木还好,再过几年很多平台主力用户估计都没经历过南海和南联盟那两年了

    【 在 kindlife 的大作中提到: 】

    : 不能忘记你!

    昨天 10:28
  • Re: 苏州那个车祸大家看了吗?

    辩论中的n个逻辑谬论之以偏概全

    【 在 shocker 的大作中提到: 】

    : 说一个不爱听的事情,在国内坐一个同事的车,刚好同车一个tw同事,结果看到前面的车并道转弯都不打灯,tw人说道:“怎么都不打灯”,同事一脸得意回应到:“我也不太打,看看后面没什么车,这有什么好打的呢,又不碍着谁”。如果我是一个新来这个地方的人,那我是不是要入乡随俗呢?

    : btw,这个实际跟同事是不是tw人没关系,不过是说明一个新外来人可能会什么感受罢了。

    昨天 09:54
  • Re: 帮我算个数学题

    你这例子不好,机械硬盘p2p都能达到几十上百兆速度,你觉得是4k 64thd比ssd还好?

    写入是有多级缓存的,读取也会有,实际不可能几十个线程同时访问硬盘,注意是同时,同时挂起在硬盘io操作上才算

    【 在 siegfried415 的大作中提到: 】

    : P2P下载时几十个线程同时读写的情况太容易了。

    昨天 00:24