10935336

明星成鸟
2020-08-07
306
195
思考时间
9 天 3 小时 10 分钟
48
Mars
本测试一点都不严谨,一点都不专业,随意测试,不代表真实情况。

图片都是全尺寸未压缩的,多图流量警告。
测试过程不是很严谨,也不涉及到技术层面。
手动缩减了帖子内图片显示的大小,点击图片即可查看大图。
意外的花费了很多时间,求点赞求鼓励。


什么是 GraalVM?
GraalVM 是一种高性能 JDK 发行版,旨在加速用 Java 和其他 JVM 语言编写的应用程序的执行,同时支持 JavaScript、Ruby、Python 和许多其他流行语言。
GraalVM 的多语言功能可以在单个应用程序中混合多种编程语言,同时消除调用其他语言的成本成本。
GraalVM 向 HotSpot Java 虚拟机添加了一个用 Java 编写的高级即时 (JIT) 优化编译器。

总之就是很好很强大的一种 JDK,比传统 JDK 多了很多厉害的功能。
其他的几个你应该都挺熟悉的。


测试环境
测试平台
笔记本:Microsoft Surface Book 2 15"
CPU:Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 降压 86.9mv 功耗墙 25W
DGPU:NVIDIA GeForce GTX 1060 6GB
RAM:16GB
屏幕分辨率:3240 x 2160
没有独显直连,需要经过核芯显卡转发,全屏独占模式可以获得较高帧数。
CPU 使用外部散热器辅助散热保证不会过热降频。


测试系统环境
系统版本:Windows 10 专业版 21H1 内部版本 19043.1055
NVIDIA 独立显卡驱动版本:27.21.14.5167
Intel 核芯显卡驱动版本:27.20.100.8682
启动器:MultiMC 5 - 0.6.12 -1530
整合包:Minecraft 1.7.10 - CL-GT New Horizons-V1.1-I[V2.1.0.4](仅运行客户端线程,在第三方服务器上进行测试)
额外模组:OptiFine HD U E7,FastCraft 1.2.5,ScreenSize-1.7.10-1.0.16-48
Java 最大内存分配:8192 MB
Java 最小内存分配:512 MB
Java PermGen:128MB
Java 参数(MultiMC 5 默认添加):"Java 路径" -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_ javaw.exe_ minecraft exe.heapdump -Xms512m -Xmx8192m 省略
由于 Surface 的特殊显卡驱动没有 NVIDIA 控制面板,已在 Windows 设置中的图形设置中的图形性能首选项将各个 java.exe、javaw.exe 以及启动器设置为高性能(独立显卡)



先说结论
此场景下帧数性能,
如果考虑分辨率(越大越好) Azul Zulu JDK > GraalVM CE > AdoptOpenJDK Eclipse OpenJ9
如果不考虑分辨率(越大越好) Oracle Java SE >> Azul Zulu JDK > GraalVM CE > AdoptOpenJDK Eclipse OpenJ9
内存占用方面(越小越好) Azul Zulu JDK > Oracle Java SE> GraalVM CE >> AdoptOpenJDK Eclipse OpenJ9

如果你内存比较吃紧,可以优先考虑 AdoptOpenJDK Eclipse OpenJ9,否则请勿使用,因为会占用更多的 CPU 导致相关性能下降。
如果没有特殊需求,使用 Azul Zulu JDK 或 GraalVM CE 似乎是性能较好的选择。
Oracle Java SE 的表现较为奇怪(会降低分辨率),但降低分辨率对 Minecraft 来说影响不大,在游玩表现上可以接受,若你的 Oracle Java SE 也有此表现,可以酌情使用以提高帧数表现。

粗略测试得到的粗略结论,不是 100% 可靠。
此测试为笔记本平台且无独显直连,高分辨率+中低端显卡的组合,CPU 性能也较为一般,内存较为充裕。
台式机无需考虑显卡直连及奇怪的帧数限制问题,测试结果可能会有很大不同,有时间我将使用台式机再次测试。


去哪里找这几种 JDK?
Azul Zulu JDK:Java Download | Java 8, Java 11, Java 13 - Linux, Windows & macOS
页面最底部,提供各个 Java 版本。

GraalVM CE:Releases · graalvm/graalvm-ce-builds
仅提供 Java 8、Java 11、Java 16。

AdoptOpenJDK Eclipse OpenJ9:AdoptOpenJDK
他们的网站现在有迷之机翻,在选择 JVM 处选择 OpenJ9,仅提供 Java 8、Java 11、Java 16。

Oracle Java SE JDKhttps://www.oracle.com/java/technologies/javase-downloads.html
仅提供 Java 7、Java 8、Java 11、Java 16,下载可能需要登录。
Oracle Java SE JREhttps://www.java.com/zh-CN/download/manual.jsp
仅提供 Java8。



测试过程
1号选手:Graalvm-CE-Java8-21.1.0
GraalVM 的开源社区版,基于 Java 8。

启动时间:7分3秒

场景1:地点1,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 55

2BugjoZl1MmNsXx.png


场景2:地点1,全屏全分辨率,截图分辨率 3240 x 2160
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 55
FizvceXGqCLk6WA.png


场景3:地点1,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数75
5QYvGbDxneOIuc2.png


场景4:地点2,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 52
JXU8j7QiH1ym29D.png


场景5:地点2,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数 65
9B1Wx6vYHJCMANe.png


场景6:地点1,窗口化最大,开启 F3
占用内存似乎比 Oracle Java SE 小那么一点点。
memory: 36% (2630MB) of 7282MB
memory 在 2200MB 和 4400MB 之间快速变换,内存回收似乎很频繁。
Allocated memory: 72% 5279MB
bzU5R2menL1u8Dj.png



2号选手:AdoptOpenJDK JDK-8.0.292.10-OpenJ9
AdoptOpen 的 JDK 加上 Eclipse 的 OpenJ9 JVM。

启动时间:7分51秒

场景1:地点1,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 50

DkZK4P1YaVHxrl3.png


场景2:地点1,全屏全分辨率,截图分辨率 3240 x 2160
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 54
FizvceXGqCLk6WA.png


场景3:地点1,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数 69

aiOH5KRPIphTNtf.png


场景4:地点2,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧
平均帧数 54
JXU8j7QiH1ym29D.png


场景5:地点2,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数 56

DMgXFYTunakQ1Iv.png


场景6:地点1,窗口化最大,开启 F3
占用内存似乎比 Oracle Java SE 小那么一点点。
memory: 36% (2630MB) of 8192MB
memory 在 1900MB 和 2900MB 之间快速变换,内存回收似乎很频繁。
Allocated memory: 44% 3606MB
比其他的 JDK 的内存占用都要小,OpenJ9 确实在内存方面有着特别优化。

p56No3yfEUZh1BQ.png




3号选手:Oracle Java SE jre1.8.0_291
也就是平时用的普通 JRE。

启动时间:7分6秒

场景1:地点1,窗口化最大,截图分辨率 1620 x 1017
???Oracle 的 JDK 似乎有什么特殊优化,解开了奇怪的帧数限制。
但是在没有其他调整的情况下它的分辨率却变低了,也许属于作弊?
不知道是启动器的问题 还是 Oracle Java SE 的问题,期间仅改动过 Java 路径设置。
平均帧数 99

my3GTe9tOpuiHJj.png


场景2:地点1,全屏全分辨率,截图分辨率 3240 x 2160
???Oracle 的 JDK 似乎有什么特殊操作,全屏模式不会调整大小,只会显示一角,无法游戏
平均帧数 80
j9RsZLa5v6zu2Cq.png



场景3:地点1,全屏缩减分辨率,截图分辨率 2560 x 2048
???Oracle 的 JDK 似乎有什么特殊操作,全屏模式不会调整大小,只会显示一角,无法游戏
平均帧数 93

atAqBubwe8MIOQm.png


场景4:地点2,窗口化最大,截图分辨率 1620 x 1017
???Oracle 的 JDK 似乎有什么特殊优化,解开了奇怪的帧数限制。
但是在没有其他调整的情况下它的分辨率却变低了,也许属于作弊?
平均帧数 84

pKEt3vVAbLyo2fY.png


场景5:地点2,全屏缩减分辨率,截图分辨率 2560 x 2048
???Oracle 的 JDK 似乎有什么特殊操作,全屏模式不会调整大小,只会显示一角,无法游戏
平均帧数 88

ojX3U2W6wTeuVsc.png


场景6:地点1,窗口化最大,开启 F3
占用内存似乎比 Oracle Java SE 小那么一点点。
memory: 36% (2298MB) of 7282MB
memory 在 2200MB 和 4400MB 之间低速变换,内存回收似乎不是那么频繁。
Allocated memory: 75% 5527MB
WNnBb2szIGveS6u.png


4号选手:Zulu 8.54.0.21-ca-fx-jre8.0.292
Azul 旗下的 Zulu 社区构建的 OpenJDK。

启动时间:7分11秒

场景1:地点1,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 54

WxAQoiCrXe1LJTn.png


场景2:地点1,全屏全分辨率,截图分辨率 3240 x 2160
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 58

lvULkDcFT8hys9q.png


场景3:地点1,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数77

kuSBU1dhlmv6QFw.png


场景4:地点2,窗口化最大,截图分辨率 3240 x 2035
有明显被垂直同步或者其他什么东西限制住了帧数,无法超过或达到 60 帧。
平均帧数 52

uC8PyRMlfkVpxGs.png


场景5:地点2,全屏缩减分辨率,截图分辨率 2560 x 2048
使用 ScreenSize-1.7.10-1.0.16-48 模组调整了全屏分辨率,似乎解开了奇怪的帧数限制。
平均帧数 69

SRQkXxK4spF9Vg3.png


场景6:地点1,窗口化最大,开启 F3
占用内存似乎比 Oracle Java SE 小那么一点点。
memory: 41% (2985MB) of 7282MB
memory 在 2100MB 和 4700MB 之间快速变换,内存回收似乎很频繁。
Allocated memory: 75% 5503MB

4SO1sozJyKWxQ6k.png
 
最后编辑: