Centos 7,System.nanoTime的速度比Windows慢400倍 [英] Centos 7, 400x slower for System.nanoTime than windows

查看:63
本文介绍了Centos 7,System.nanoTime的速度比Windows慢400倍的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经阅读并阅读了有关为何在某些OS上System.nanoTime()速度比其他OS慢的文章,但是我从未见过任何东西可以解释我现在所看到的差异.使用JMH,我正在运行此基准测试. (注意:它也使用System.nanoTime())

I have seen and read posts on why System.nanoTime() is slower on some OSes than others, however I have never seen anything to explain the difference I am seeing now. Using JMH, I am running this benchmark. (Note: it uses System.nanoTime() as well)

@Benchmark
public long systemNanoTime() {
    return System.nanoTime();
}

在Windows 10上,这大约需要25 ns.

On Windows 10, this takes ~25 ns.

在Centos 7,Linux 3.10上,它大约需要10293 ns的时间.

On Centos 7, Linux 3.10 it is measured as taking ~10293 ns.

这是在同一台计算机上,即Intel(R)Core(TM)i7-7820X CPU @ 3.60GHz

This is on the same machine, Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz

是否可以更改JDK获取系统时钟的方式?

Is there an option to change the way the JDK gets the system clock?

基于Todd提供的链接,看来tsc不可用

Based on the link provided by Todd, it appear that tsc is not available

# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm 
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet

表演后

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

延迟有所改善,但仍然很差,延迟为1,816 ns.

The latency improved, but is still poor with a latency of 1,816 ns.

我试图找出TSC时钟源是否可以添加到Centos,但还不能运气.

I have tried to find out if the TSC clock source can be added to Centos, but not luck yet.

进一步挖掘

# dmesg | grep -i tsc
[    0.000000] tsc: Detected 3600.000 MHz processor
[    0.058602] TSC deadline timer enabled
[    0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[    0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[    0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[  125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode

推荐答案

基于@apangin的建议,我在此页面上添加了最新版本的centos替代存储库

Based on @apangin's suggestion I followed this page on adding the alternative repository for centos with the latest version

http://elrepo.org/tiki/tiki-index.php

,然后按照此处的进一步说明

and then followed the further instructions here

https://www.tecmint.com/install -upgrade-kernel-version-in-centos-7/

安装并重新启动后

# $ dmesg | grep -i tsc
[    0.001000] tsc: Detected 3600.000 MHz processor
[    0.001000] [Firmware Bug]: TSC ADJUST: CPU0: -2100392876408 force to 0
[    0.046075] TSC deadline timer enabled
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU1: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU2: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU3: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU4: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU5: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU6: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU7: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU8: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU9: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU10: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU11: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU12: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU13: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU14: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU15: 0
[    1.337843] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6c1bafbc2ab, max_idle_ns: 881591058496 ns
[    2.353636] clocksource: Switched to clocksource tsc

建议内核正在针对固件错误进行调整.

suggesting the kernel is adjusting for a firmware bug.

再次运行测试,使用System.nanoTime()可以得到40 ns的平均延迟,这是260倍的改进.这也意味着使用此方法的基准更加有意义.

Running the test again, I get an average latency of 40 ns using System.nanoTime() which is a 260 fold improvement. It also means that benchmarks using this measure are more meaningful.

这篇关于Centos 7,System.nanoTime的速度比Windows慢400倍的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆