微基准案例研究和经验教训

SPLASH Workshops Pub Date : 2011-10-23 DOI:10.1145/2095050.2095100

J. Gil, K. Lenz, Yuval Shimron

{"title":"微基准案例研究和经验教训","authors":"J. Gil, K. Lenz, Yuval Shimron","doi":"10.1145/2095050.2095100","DOIUrl":null,"url":null,"abstract":"The extra abstraction layer posed by the virtual machine, the JIT compilation cycles and the asynchronous garbage collection are the main reasons that make the benchmarking of Java code a delicate task. The primary weapon in battling these is replication: \"billions and billions of runs\", is phrase sometimes used by practitioners. This paper describes a case study, which consumed hundreds of hours of CPU time, and tries to characterize the inconsistencies in the results we encountered.","PeriodicalId":143880,"journal":{"name":"SPLASH Workshops","volume":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2011-10-23","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"19","resultStr":"{\"title\":\"A microbenchmark case study and lessons learned\",\"authors\":\"J. Gil, K. Lenz, Yuval Shimron\",\"doi\":\"10.1145/2095050.2095100\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"The extra abstraction layer posed by the virtual machine, the JIT compilation cycles and the asynchronous garbage collection are the main reasons that make the benchmarking of Java code a delicate task. The primary weapon in battling these is replication: \\\"billions and billions of runs\\\", is phrase sometimes used by practitioners. This paper describes a case study, which consumed hundreds of hours of CPU time, and tries to characterize the inconsistencies in the results we encountered.\",\"PeriodicalId\":143880,\"journal\":{\"name\":\"SPLASH Workshops\",\"volume\":null,\"pages\":null},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2011-10-23\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"19\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"SPLASH Workshops\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/2095050.2095100\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"SPLASH Workshops","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2095050.2095100","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}

引用次数: 19

摘要

虚拟机带来的额外抽象层、JIT编译周期和异步垃圾收集是使Java代码基准测试成为一项微妙任务的主要原因。对抗这些问题的主要武器是复制:“数十亿和数十亿的运行”，这是从业者有时使用的短语。本文描述了一个案例研究，它消耗了数百小时的CPU时间，并试图描述我们遇到的结果中的不一致。

本文章由计算机程序翻译，如有差异，请以英文原文为准。

查看原文本刊更多论文

A microbenchmark case study and lessons learned

The extra abstraction layer posed by the virtual machine, the JIT compilation cycles and the asynchronous garbage collection are the main reasons that make the benchmarking of Java code a delicate task. The primary weapon in battling these is replication: "billions and billions of runs", is phrase sometimes used by practitioners. This paper describes a case study, which consumed hundreds of hours of CPU time, and tries to characterize the inconsistencies in the results we encountered.

求助全文

通过发布文献求助，成功后即可免费获取论文全文。去求助

来源期刊

SPLASH Workshops

自引率

0.00%

发文量