首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
宝塔
V2EX  ›  mind3x  ›  全部回复第 1 页 / 共 34 页
回复总数  664
1  2  3  4  5  6  7  8  9  10 ... 34  
21 小时 46 分钟前
回复了 coloz 创建的主题 程序员 今天去面试,面试官问为啥 android 用久了比 IOS 卡
Pixel 1/2/3(全 XL)在手,每次升级后都比旧版本流畅。
要说卡,只有微信卡。
21 小时 48 分钟前
回复了 alalida 创建的主题 程序员 裸辞刷题准备出国是否可行
Leetcode medium 刷下来没什么问题的话,只要英语口语能应付面试,我可以内推荷兰 Uber,在阿姆斯特丹。公司给办签证给搬家费。裸辞没什么必要,不管去哪里都应该先拿到 offer 再说。
@uhian 最后一关是破坏火箭(或导弹)
29 天前
回复了 LZYPPP 创建的主题 程序员 怎么在迷茫的青春里找到光
过几年等头发掉光 就不迷茫了
大家好,我是鱼
既然是只处理第一个 string,没看懂外面一圈 for 是拿来干嘛的
刷 LeetCode
读 SICP
125 天前
回复了 c00h00g 创建的主题 程序员 求推荐 dell 4k 显示器,程序员
U2718Q
136 天前
回复了 littlewing 创建的主题 Linux NVMe SSD Linux 下速度非常慢
Sorry 没看到说也测过多线程
136 天前
回复了 littlewing 创建的主题 Linux NVMe SSD Linux 下速度非常慢
你一个 thread 跑成这样够好了啊亲
@mzdblsw8 三本被砍掉以后,现在的二本很多是以前的三本甚至专科
148 天前
回复了 miaoxia 创建的主题 程序员 Cmake 编译 Android 动态库依赖什么工具?
编译器是 NDK 自带的,现在应该只有 clang。gcc 我记得是前两年 NDK 就 deprecated 掉了。
149 天前
回复了 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 万次,区别也只有千分之一。
151 天前
回复了 sparga 创建的主题 硬件 树莓派 4 发布啦
@wolfie tom's hardware 的评测显示,浏览器内视频全屏播放性能很糟糕,估计是驱动问题
151 天前
回复了 sparga 创建的主题 硬件 树莓派 4 发布啦
4 x A72,TF 卡 IO 提高接近一倍,真 USB 3 和千兆网卡,4GB 内存…… shut up and take my money
@shikimoon 广义的 contention 就是两个或者更多线程竞争同一个资源。对 synchronized 这样的临界区来说,就是有一个以上的线程都试图进入同一个 synchronized 修饰的 block。
@zazalu 说歉意言重了,大家都是参加讨论互相学习,我不是搞高并发的专家,也很业余的。而且我觉得你总结得比我好多了。

另外我举例子的那个网页,之前我没有细看他的代码和结论,需要道歉的是我 XD
其实他本身的方法和结论有很大的问题。像 RWLock,本来就是为多读少写的情况下提高读吞吐量而存在,他的 benchmark 反而显示多读少写的情况下 RWLock 最慢,是因为他统计的是读写线程全部完成以后的最大耗时,而不是读 /写各自的吞吐量。在多读少写的情况下,写线程会因为大量读锁而等待,所以按他的测量方式反而会大幅拖慢总运行时间。
@arrow2015 不不,十多年前做 J2ME VM 的
前 JVM 开发者,建议谨慎应用你的结论 :)

简单说 synchronized 并不一定就是悲观锁,JVM 会先尝试基于 CAS 的瘦锁,发现有 contention 再升级为重量级的悲观锁。

实际用哪种锁,取决于你并发的规模和读 /写比例。多数情况下,因为 synchronized 的自适应性,其实综合表现更好。不然为什么 Java 8 的 concurrenthashmap 仍然用 synchronized 来锁 slot。

你可以看下 https://blog.overops.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/,你的 CAS 实现大致对应里面的 StampedLock 版本。然后他里面的 optimistic 版本是 fail fast 的,其实没有比较意义。

另外要做 Java 的 microbenchmark,必须要考虑 JIT 的介入,还是得用 JMH,自己写个大循环加 current time millis 远远不够。
@bengcaca v2 还是有靠谱的回答的👍
1  2  3  4  5  6  7  8  9  10 ... 34  
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   876 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 151ms · UTC 21:11 · PVG 05:11 · LAX 13:11 · JFK 16:11
♥ Do have faith in what you're doing.