Title: HiPE%20version%201.0
1HiPEversion 1.0
- Kostis Sagonas
- Uppsala University
2Structure of this talk
- 1. Recent past
-
- 2. Present
- 3. Near future
3Part 1 Recent Past
4Historical 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...
5HiPE 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
6HiPE 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
7Old HiPE Architecture
SymbolicJAM
Code area
JAM Bytecode
JAMDissassembler
Icode
OtherData
JAMEmulator
RTL
NativeCode
HiPELoader
SPARC
Erlang Run-Time System
HiPE Compiler
The HiPE system
8Speedup of HiPE (0.92) over other Erlang
implementations
9Success of HiPE Lets 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!
10Part 2 Present
11HiPE 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
12HiPE 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
13New HiPE Architecture
SymbolicBEAM
Code area
BEAM Bytecode
BEAMDissassembler
Icode
OtherData
BEAMEmulator
RTL
NativeCode
HiPELoader
SPARC
X86
Erlang Run-Time System
HiPE Compiler
A HiPE-enabled Erlang/OTP system
14HiPE 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
15HiPE Invoking the compiler (novice user)
- Instead of typing
- 1gt c(Module, Options).
- types
- 1gt c(Module,
nativeOptions). - Alternatively, instead of typing
- erlc File
- types
- erlc native File
16HiPE Invoking the compiler (seasoned user)
- Instead of typing
- 1gt c(Module, Options).
- types
- 1gt c(Module, native,hipe,O3
,...Options). - Learns about the full set of HiPE compiler
options by typing - 1gt hipehelp().
17HiPE Invoking the compiler (expert user)
- Selectively and dynamically compiles individual
Erlang functions using - 1gt c(M).
-
- 42gt hipec(M,F,A,
HiPE_Opts). - Reports bugs to hipe-bugs_at_csd.uu.se
18HiPE Invoking the compiler (HiPE hacker)
- Sends bug fixes and compiler improvements to
hipe_at_csd.uu.se
19HiPE 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
20HiPE version 1.0 Performance Expectations
21HiPE 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
22Part 3 Near Future
23HiPE 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
24Alternative Memory Architectures for Erlang
- Erlang/OTP has a process-centric view of memory
management - each process allocates each own memory area
Interprocess communication is quite expensive
25Alternative 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
26Unified 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
27Core ErlangFormal 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 compilers 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)
28Core Erlang Inliner Users Manual
- Instead of typing
- 1gt c(Module, Options).
- type
- 1gt c(Module,
inlineOptions).
29Extensions 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