Jens Ernst

dblp:51/32 · DBLP profile ↗
← Back
2ranked-venue papers
2as first author
0since 2021 · last 2006
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 1 · 1 first-authorSoftware engineering, systems software and programming languages · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Compilers and program optimization · 50% Runtime systems and virtual machines · 50%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Memory systems · 100%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Runtime systems and virtual machines › interpreter
bytecode interpretation
0.011997
Code Compression · PLDI 1997
Compilers and program optimization › code size reduction
code compression
0.011997
Code Compression · PLDI 1997
Memory systems › memory management › virtual memory
paging
0.011997
Code Compression · PLDI 1997

Methods — techniques the papers use, named apart from their topics

wire representation · 0.0interpretation without decompression · 0.0compressed executable representation · 0.0
YearPublicationVenuePosition
2006 A Distributed, Parallel System for Large-Scale Structure Recognition in Gene Expression Data
Jens Ernst
HPCC1
1997 Code Compression
abstract
Current research in compiler optimization counts mainly CPU time and perhaps the first cache level or two. This view has been important but is becoming myopic, at least from a system-wide viewpoint, as the ratio of network and disk speeds to CPU speeds grows exponentially.For example, we have seen the CPU idle for most of the time during paging, so compressing pages can increase total performance even though the CPU must decompress or interpret the page contents. Another profile shows that many functions are called just once, so reduced paging could pay for their interpretation overhead.This paper describes:• Measurements that show how code compression can save space and total time in some important real-world scenarios.• A compressed executable representation that is roughly the same size as gzipped x86 programs and can be interpreted without decompression. It can also be compiled to high-quality machine code at 2.5 megabytes per second on a 120MHz Pentium processor• A compressed "wire" representation that must be decompressed before execution but is, for example, roughly 21% the size of SPARC code when compressing gcc.
Jens Ernst, William S. Evans, Christopher W. Fraser, Steven Lucco, Todd A. Proebsting
PLDI1