mind3x 最近的时间轴更新 mind3x 最近的时间轴更新 |
mind3xV2EX 第 67506 号会员，加入于 2014-07-09 23:44:18 +08:00 |
| 介绍一个 Rust 版的高性能 lock free concurrent hashmap 分享创造 • mind3x • 180 天前 • 最后回复来自 mind3x | 2 |
| 迅极云是不是跑路了？ 全球工单系统 • mind3x • 2017-09-20 23:14:23 PM • 最后回复来自 tianwm | 2 |
| 目测用 GRE 直接导致 IP 被 block 宽带症候群 • mind3x • 2018-02-01 13:26:39 PM • 最后回复来自 redsonic | 14 |
| 连公司用的 CN2 都被中国电不信 QJ 了 宽带症候群 • mind3x • 2016-12-10 08:11:21 AM • 最后回复来自 akw2312 | 8 |
| Nexus 6P 更新 7.1beta Android • mind3x • 2016-10-20 14:37:48 PM • 最后回复来自 mind3x | 2 |
| 集思广益： Zite 的替代选择？ 问与答 • mind3x • 2015-11-25 18:12:51 PM • 最后回复来自 mind3x | 2 |
| 这两天 CN2 连 QuadraNet 有点不正常啊 VPS • mind3x • 2015-11-04 14:50:24 PM |
| 你们以为 CN2 就没事了？
2 宽带症候群 • mind3x • 2015-08-15 12:30:14 PM • 最后回复来自 marsteel
|
18 |
| 似乎 LET 被墙了 VPS • mind3x • 2015-08-11 14:29:09 PM • 最后回复来自 yylzcom | 4 |
| 我美西的几台 VPS 走 IPv4 都连不上 Google 了， IPv6 正常 VPS • mind3x • 2015-07-30 14:57:00 PM |
mind3x 最近回复了
17 天前 回复了 drperry 创建的主题 › 程序员 › 马上开学大二，川大 CS 在读，想问问各位前辈，将来想去 BAT、微软等大厂的话，该怎么提升自己 |
刷 LeetCode
读 SICP
读 SICP
57 天前 回复了 c00h00g 创建的主题 › 程序员 › 求推荐 dell 4k 显示器，程序员 |
U2718Q
68 天前 回复了 littlewing 创建的主题 › Linux › NVMe SSD Linux 下速度非常慢 |
Sorry 没看到说也测过多线程
68 天前 回复了 littlewing 创建的主题 › Linux › NVMe SSD Linux 下速度非常慢 |
你一个 thread 跑成这样够好了啊亲
78 天前 回复了 mzdblsw8 创建的主题 › 问与答 › 当年高考没考好。偏科严重。只上了一个专科。30 岁了。想回去重新高考。可行吗？ |
@mzdblsw8 三本被砍掉以后，现在的二本很多是以前的三本甚至专科
80 天前 回复了 miaoxia 创建的主题 › 程序员 › Cmake 编译 Android 动态库依赖什么工具？ |
编译器是 NDK 自带的，现在应该只有 clang。gcc 我记得是前两年 NDK 就 deprecated 掉了。
81 天前 回复了 hackingwu 创建的主题 › 程序员 › 反射性能差这么多，有办法提高吗？ |
2.6GHz 主频的 7 代 i5，MIPS(每秒执行百万条指令数)大约是 53K。
0 循环到 max int，循环次数是 2,147,483,647，假设每个循环只执行三条指令，大约是 6K 个百万条指令。
也就是说，一个什么也不做的从 0 到 max int 的循环，在 7 代 i5 上，大约应该花 0.1 秒这么个量级的时间。我们就放宽一点，给它再快个 10 倍，大约应该花 10ms 这个量级的时间。今天应该还没有一款 CPU 的单核 IPC 能达到 10 倍 i5 的水平。
你猜猜看你的第二个循环为啥 1ms 就跑完了？
因为 JIT 在跑了前面的几百或者几千次循环以后开始介入编译，发现你的 test()很小，应该内联进循环，然后就内联了。内联以后一看原来整个循环也啥也没做，就把循环也优化掉了。
而第一个循环，反射是实打实没法优化掉的。
这个故事告诉我们，microbenchmark 通常没什么鸟用。如果一定要做 microbenchmark，请至少正确使用 JMH，在代码里通过 JMH 的 API 强制添加副作用，避免不希望的优化发生。
另外，即使反射比普通调用真的慢一千倍，实际到你的产品里很可能也只有不到 1%的差距。打个比方，如果你的方法本身要花 1 秒，反射花 1 毫秒，直接调用花 1 微秒，把你的方法调用 1 万次，区别也只有千分之一。
0 循环到 max int，循环次数是 2,147,483,647，假设每个循环只执行三条指令，大约是 6K 个百万条指令。
也就是说，一个什么也不做的从 0 到 max int 的循环，在 7 代 i5 上，大约应该花 0.1 秒这么个量级的时间。我们就放宽一点，给它再快个 10 倍，大约应该花 10ms 这个量级的时间。今天应该还没有一款 CPU 的单核 IPC 能达到 10 倍 i5 的水平。
你猜猜看你的第二个循环为啥 1ms 就跑完了？
因为 JIT 在跑了前面的几百或者几千次循环以后开始介入编译，发现你的 test()很小，应该内联进循环，然后就内联了。内联以后一看原来整个循环也啥也没做，就把循环也优化掉了。
而第一个循环，反射是实打实没法优化掉的。
这个故事告诉我们，microbenchmark 通常没什么鸟用。如果一定要做 microbenchmark，请至少正确使用 JMH，在代码里通过 JMH 的 API 强制添加副作用，避免不希望的优化发生。
另外，即使反射比普通调用真的慢一千倍，实际到你的产品里很可能也只有不到 1%的差距。打个比方，如果你的方法本身要花 1 秒，反射花 1 毫秒，直接调用花 1 微秒，把你的方法调用 1 万次，区别也只有千分之一。
@wolfie tom's hardware 的评测显示，浏览器内视频全屏播放性能很糟糕，估计是驱动问题
4 x A72，TF 卡 IO 提高接近一倍，真 USB 3 和千兆网卡，4GB 内存…… shut up and take my money
83 天前 回复了 zazalu 创建的主题 › Java › 一个比较悲观锁和 CAS 乐观锁性能的简单实例引发的问题 |
@shikimoon 广义的 contention 就是两个或者更多线程竞争同一个资源。对 synchronized 这样的临界区来说，就是有一个以上的线程都试图进入同一个 synchronized 修饰的 block。
Select Language