HiPE

version 1.0

Kostis Sagonas
Uppsala University
Structure of this talk

1. Recent past

2. Present

3. Near future
Part 1: Recent Past
Historical introduction

During the last few years, the following people:

Erik “Happi” Johansson

Mikael Pettersson
Richard Carlsson
Kostis Sagonas

have been having fun developing and maintaining

the HiPE system...
HiPE: High Performance Erlang

A “just-in-time” native code compiler for Erlang

– Allows flexible, user-controlled compilation of

Erlang programs to native machine code

– Fine-grained: Compilation unit is a single function

• HiPE 0.92 released as open-source in March

2000 (see also www.csd.uu.se/projects/hipe)
– Released version was JAM-based (Erlang R4)
– Available only for SPARC machines
HiPE: Technical Details

• Both virtual machine code and native code can

happily co-exist in the runtime system
• HiPE optimizes calls to functions which
execute in the same mode
• Preserves tail-calls
• The generated native code is quite efficient
– HiPE significantly outperforms all other Erlang
implementations
– has similar performance to e.g. Concurrent SML/NJ
Old HiPE Architecture

Code Symbolic
area JAM
JAM JAM
Bytecode Dissassembler
Icode
JAM Other
Emulator Data
RTL
Native
Code HiPE
Loader SPARC

Erlang Run-Time System HiPE Compiler

The HiPE system

 Speedup of HiPE (0.92) over other Erlang
implementations
25

20 HiPE
Etos
Speedup over JAM

JAM
15
BEAM

10

0
fib huff length nrev qsort smith tak decode
Success of HiPE: Let’s take a quick poll...

Who has used HiPE ?

My educated guess: A few…

Who is using HiPE instead of using Erlang/OTP ?

Most probable answer: None!

Part 2: Present
HiPE version 1.0: The current HiPE team

At Uppsala University:
Erik “Happi” Johansson
Mikael Pettersson
Richard Carlsson
Kostis Sagonas
+
Jesper Wilhelmsson

Recent addition from the Erlang/OTP team:

Bjorn Gustavsson
HiPE version 1.0: Main Features of Interest

• HiPE is fully and tightly integrated within

Open Source Erlang/OTP Release 8

• Handles the full Erlang language

• Back-ends for:
– SPARC
– x86-based machines running Linux or Solaris

• Usually very reasonable compilation times

• Acceptable sizes of object code
New HiPE Architecture

Code Symbolic
area BEAM
BEAM BEAM
Bytecode Dissassembler
Icode
BEAM Other
Emulator Data
RTL
Native
Code HiPE
Loader SPARC X86

Erlang Run-Time System HiPE Compiler

A HiPE-enabled Erlang/OTP system

HiPE version 1.0: Installation Guide

1. Get Open Source Erlang/OTP R8

2. If on SPARC or x86, instead of typing:

./configure
./make
type:
./configure --enable-hipe
./make
HiPE: Invoking the compiler (novice user)

• Instead of typing:
1> c(Module, Options).
types:
1> c(Module, [native|
Options]).

• Alternatively, instead of typing:

erlc … File
types:
erlc +native … File
HiPE: Invoking the compiler (seasoned user)

• Instead of typing:
1> c(Module, Options).
types:
1> c(Module,
[native,{hipe,[’O3’,...]}|Options]).

• Learns about the full set of HiPE compiler

options by typing:
1> hipe:help().
HiPE: Invoking the compiler (expert user)

• Selectively and dynamically compiles individual

Erlang functions using:
1> c(M).
…
42> hipe:c({M,F,A},
HiPE_Opts).

• Reports bugs to: hipe-bugs@csd.uu.se

HiPE: Invoking the compiler (HiPE hacker)

Sends bug fixes and compiler improvements to:

hipe@csd.uu.se
HiPE version 1.0: Currently known limitations

• Native code will not be unloaded once loaded

into the system (slight memory leak)

• Tracing and debugging support is non-existent

Hint: Use HiPE once your application is debugged!

• Floating point arithmetic slower than in BEAM

• Exception information often slightly differs between
BEAM and HiPE
• in particular, no tracelist is provided
• Fixed size (i.e., non-resizable) constant pool
HiPE version 1.0: Performance Expectations

8
BEAM
6 HiPE/SPARC
HiPE/x86
4

tak t f
fib g th
qs o r
mi t
h
huf o de
r i n g life to ne
l en s de
c es
HiPE version 1.0: Useful Hints

To get the most out of HiPE:

• Compile all time-critical parts of your Erlang

application into native code
– Separate hot from cold code
(perhaps by placing them into different modules)

• Avoid easily avoidable mode-switches

Part 3: Near Future
HiPE: Current Work

• Optimization of inter-process communication and

efficient memory management for concurrent
processes

• Formal specification of the Core Erlang language

and its full integration within HiPE and Erlang/OTP

• New inliner for the BEAM compiler

• Experimental extensions of the Erlang language

Alternative Memory Architectures for Erlang

• Erlang/OTP has a process-centric view of memory

management:
each process allocates each own memory area

Process 1 Process 2 Process n

stack stack
... stack
Global
ETS

heap heap ... heap

Table

Interprocess communication is quite expensive

Alternative Memory Architectures for Erlang

• We (mainly Jesper Wilhelmsson) have designed and

implemented an Erlang/OTP system where:
– the heap is shared between all processes
– but each process allocates its own stack

Process 1 Process 2 Process n

stack stack
... stack
Global
ETS
Table
Global Heap

Interprocess communication does not involve copying of messages

Unified Heap Architecture: Installation Guide

1. Get Erlang/OTP R8
2. Install by typing:
./configure --enable-unified-
heap
./make
Warnings:
– Highly experimental at this point!
– Does not work with HiPE
Request:
Send us your favourite concurrent Erlang application
Core Erlang:Formal Specification and Use in OSE

• A small and relatively clean subset of Erlang

– Syntactic sugar is removed
– Resembles other “core” FP languages
• An appropriate medium to:
– base the compiler’s front-end (already part of R8)
– apply high-level transformations such as:
• inlining (currently under development)
• deforestation (prototype; results so far inconclusive)
– base work of static analysis or verification
A formal definition of Core Erlang is currently
available as a tech report (Richard Carlsson et al)
Core Erlang Inliner: User’s Manual

• Instead of typing:
1> c(Module, Options).
type:
1> c(Module, [inline|Options]).
Extensions of the Erlang language

• Parameterized Erlang modules

– Design laid out; issue is efficient implementation
– Current work by Richard Carlsson & Mikael Pettersson

• User-defined parametric datatypes (a la ML)

• Structured module system for Erlang