- 主题:刚知道现在Java的gc已经在1ms以内了
啥时候java/c#之类可以用于三维仿真，三维游戏呢
【 在 GoGoRoger 的大作中提到: 】
: 大部分在50us，感觉学cpp没啥意义了。。。。
--
FROM 1.88.112.*
这样说，就相当于承认c++更加小众化了
内存有限，cpu资源有限，又要求快速计算。
【 在 oldwatch 的大作中提到: 】
: Java没有值对象很多场合还是相当受限的
: class的metadata开销，特定场景下完全不可接受
:
--
FROM 1.88.112.*
java项目中，在关键的热点，内存效率发生瓶颈的地方，通过ffi调用native code精准管理内存布局，似乎也是可行的解决这个问题的方法？
【 在 ilovecpp 的大作中提到: 】
: 对于内存容量或内存带宽为瓶颈的代码来说，内存效率=性能。
--
FROM 120.245.130.*
没看懂你说的逻辑。stw降低到0.1ms以下，不正好可以极大提高p99指标吗？
理论上，制造垃圾的线程有N个，回收垃圾的线程也配置N个，无论如何应该可以快速回收了。就是说，cpu最多浪费50%左右吧
【 在 lambdai 的大作中提到: 】
: 问题是计算能力容易堆，p99难堆
: 可能你堆了10倍的硬件，综合cpu利用率只有别人的1/8，才获得了一样的p99。
: 以上数字属于胡编
: ...................
--
FROM 120.245.130.*
可能有些优化技术，需要的是能精准控制内存布局的native code。 仅仅转变为native code如果内存布局不对也是不管用的
【 在 poikilotherm 的大作中提到: 】
: 热点代码jit就会编译成native code
--
FROM 120.245.130.*
现在golang的性能比java有明显的优势吗？
或者，用golang而不用java，有什么明确的足够硬的理由呢？
【 在 hany2017 的大作中提到: 】
: 原先的场景也是用golang替代 cpp， 轮不到java。
--
FROM 120.245.130.*
具体细节我不清楚。我说一下我的理解吧。
stw之所以大于零而不能等于零，应该是gc每次循环，都需要设置一个启动状态。这个状态是通过stw创建的。gc单次循环完成则停止。下次gc循环还需要启动stw的过程。gc单次循环的工作量是有限的，不会无限制的进行下去。
【 在 lambdai 的大作中提到: 】
: 我觉得你这个模型完全没能解释stw。如果业务逻辑占用一半的cpu核，回收线程永远不用业务逻辑的核，那是不是永远没有stw？实际上stw还是存在。所以p99就不能说double了核数就能维持不变。
: 和没有gc的cpp相比，双倍cpu的java很可能是avg比cpp好但是p99比cpp差
: :
: ...................
--
FROM 120.245.130.*