pragmatic smalltalk

Traditional Smalltalk Playing Well With Others Performance Etoile

EtoilePragmatic Smalltalk

David Chisnall

August 25, 2011

http://gnustep.org

http://etoileos.com

http://clang.llvm.org


Smalltalk is Awesome!

• Pure object-oriented system

• Clean, simple syntax

• Automatic persistence and many other great features


...but no one cares

• TIOBE ranks Smalltalk somewhere in the #51-100 range.

• In the same range as Io, Dylan, Eiffel, Inform...

• Behind Haskell (#34), Go (#24), Logo (#21)

• A long way behind Smalltalk-derivatives Ruby (#12),Objective-C (#6), and Java (#1)


Why?

• What do other languages have that Smalltalk doesn’t?

• Large commercial backer, writing huge amounts of librarycode (e.g. Java)

• Easy interoperability with other languages


Language Report Cards

Smalltalk:

Very bright student. Excels in most subjects. Doesn’tplay well with others.

Python:

Very friendly student. Always actively participates ingroup activities. May have undiagnosed learningdifficulties.


Heresy

• Smalltalk is not always the best tool for the job

• Try writing a video CODEC in Smalltalk

• It’s possible, but you’re fighting the language every step of theway


Smalltalk is a High-level Language

• High-level abstractions

• Good for most tasks

• Bad when you need close access to the hardware (e.g. SIMD)


Objective-C: C in Smalltalk Objects

• Created by Brad Cox and Tom Love in 1986 to package Clibraries in Smalltalk-like classes

• Smalltalk object model

• C code in methods, message passing between objects

• Rich set of standard class libraries


The Compiler and the Runtime

• The compiler generates calls to functions in the runtime library

• All Smalltalk-like features are implemented by runtime calls

• Calls to C libraries have the same cost as calling them from C

• Can incrementally deploy Objective-C code with C/C++libraries


Pragmatic Smalltalk

• Dialect of Smalltalk used by Etoile

• Implements Smalltalk-80 language, but not the standardlibraries

• Compiles to native code (JIT or static compiler)

• Emits code ABI-compatible with Objective-C


Compiler Architecture

LanguageKit

Smalltalk Parser

EScript Parser

Interpreter

LLVM Optimiser JIT

Clang (Objective-C)

LLVM Optimiser

LLVM Linker / Optimiser Native Linker

Executable


Execution Architecture

Kernel

libc

C/C++ Libraries

X11

libobjc

GNUstep Foundation

GNUstep AppKit

ObjC Frameworks

GNUstep AppKit

ObjC ApplicationsSmalltalk Applications

SmalltalkSupport

LanguageKitRuntime


LanguageKit

• AST for representing Smalltalk-like languages

• Interpreter for directly executing the AST

• LLVM-based code generation back end for compiling

• Written in Objective-C


Compiling Smalltalk: The Hard Bits

• Small integers

• Blocks

• Non-local returns

• Memory management


Small Objects

• Objects hidden in pointers (e.g. small integers)

• Very common operations implemented as (hand optimised) Cfunctions

• Inlined during compilation

• Objective-C runtime modified to allow sending messages tosmall objects

• Totally interoperable with Objective-C: small integers are justNSSmallInt instances, can be used anywhere NSNumber isexpected

• Very fast: almost the same speed as C integer arithmetic -Fibonacci benchmark ran the same speed as GCC 4.2.1


Blocks

• Objective-C now supports blocks

• LanguageKit uses the same ABI

• Smalltalk and Objective-C blocks can be used interchangeably.


Non-Local Returns

• Returns from blocks

• Ugly feature, should never have been allowed in the language

• Implemented using same mechanism as exceptions (DWARFstack unwinding)


Memory Management

• Objective-C can use tracing GC or reference counting

• LanguageKit supports GC or automatic reference counting(ARC)

• Optimisation passes remove redundant retain / releaseoperations in ARC mode.


Objective-C[++] is our Foreign Function Interface

• Objective-C and Smalltalk classes are the same

• Categories can be written in either language

• Methods written in Smalltalk and Objective-C areindistinguishable

• Calling C++ from Objective-C++ is trivial


Sending Messages to C

Writing a method just to call a C function is cumbersome (andslow!)�"Smalltalk code:"

C sqrt: 42.

C fdim: {60. 12}.

C NSLocation: l InRange: r. � �Generates exactly the same code as:�// C code

sqrt (42);

fdim(60, 12);

NSLocationInRange(l, r); � �No bridging code, no custom wrappers, just native function calls inthe compiled code.


Smalltalk in the Terminal

$./br "viewSpace: (Shapeways ringBlopperPath:

(env objectForKey:’BLOPPER’)

order: 1

ringSize: 10

thickness: 3.0

height: 15.0)"


In Shell Scripts

$ cat foo.st

#!/Local/Tools/edlc -f

NSObject subclass: SmalltalkTool [

run [ | info |

info := NSProcessInfo processInfo.

ETTranscript show: ’Hello, world?’ ; cr;

show: ’sqrt(2): ’; show: (C sqrt: 2) ; cr;

show: ’Arguments: ’ ; show: (info arguments); cr.

]

]

$ ./foo.st This is a shell script

Hello, world?

sqrt(2): 1.414214

Arguments: ("/Local/Tools/edlc", "-f", "./foo.st", This,

is, a, shell, script)


Compiled Shell Scripts

$ edlc -c -f foo.st

$ llc foo.bc

$ clang -fobjc-nonfragile-abi run.m foo.s

-lEtoileFoundation -lLanguageKitRuntime

$ ./a.out this is the same shell script

Hello, world?

sqrt(2): 1.414214

Arguments: ("./a.out", this, is, the, same, shell,

script)

$ edlc -i -f foo.st In the interpreter

Hello, world?

sqrt(2): 1.414214

Arguments: (edlc, "-i", "-f", "foo.st", In, the,

interpreter)


Or in the GUI...


What Makes Things Slow?

• Small integer arithmetic

• Boxing

• Dynamic message lookup

• Memory management operations


Small Objects Support in Libobjc

• Allows Smalltalk SmallInts to be returned to ObjC code (noboxing required)

• Removes the need for LanguageKit to add conditionals aroundevery message send

• Approximately 40% reduction in code size

• Smaller code means better instruction cache usage


Lookup Caching

• New lookup function returns a pointer to a structure

• Structure contains a version

• Version incremented if the method is replaced

• Safe automatic caching now possible

• Optimisation pass caches all lookups in loops and to classes

• Optimisations shared between Objective-C and Smalltalk

Author's Note

Comment

Idea shamelessly stolen from Self, although the implementation differs - it's much easier to do in a VM. The biggest win for this is in a loop optimisation pass, where we can do a single lookup and cache the result on the stack. Polymorphic inline caching is rarely worthwhile - the cost of 2-3 cache checks is more than the cost of a real method lookup.


Speculative Inlining

• C can insert copies of functions where they are used

• Objective-C message sends may map to different methods

• But we can guess one...

• ...inline it...

• ...and wrap it in a test to see if we guessed right

Author's Note

Comment

Inlining is a big performance win for C (and for C++). Saving the call overhead is nice, but it also allows a lot of extra optimisations, like constant propagation and common subexpression elimination, to reduce code that is in multiple functions. With Objective-C, we can't inline methods, because we can't know exactly which method will actually be called for a given messages send. It turns out, however, that we can quite often guess correctly (with profiling, it's easy to guess correctly most times) and can then do speculative inlining. We bracket the inlined call with a test that checks if we've really done the correct thing.


A Microbenchmark

• Simple message sends in a loop.

• Target: using C function calls takes 3 seconds

• Infinitely fast lookup function would therefore take 6 seconds

Optimisation Time (s)

None 10Standard LLVM Opts 8

Auto-Caching 4.6Auto-Caching + LLVM Opts 3.5

Auto-Caching + Speculative Inlining 2

Are we ‘fast enough’ yet?

Author's Note

Comment

Performance is so close to C that it's not clear whether it's worth optimising more. We can probably do better, but we're well past 'fast enough' for most things at this point. Most of the time, it's actually not worth bothering with these extra optimisations - code that doesn't do them is more than fast enough already. Even without these, it's rare to see a CPU-bound Objective-C application - most of the time I/O or the user's brain is the bottleneck.


Don’t Trust Microbenchmarks(Including the last slide!)

• Algorithmic improvements make much a more noticeabledifference to performance

• Loose coupling makes specialisation easier.

• Case study: Integrating with libicu

• The problem: libicu uses its own (very efficient) unicodestring representation

Author's Note

Comment

A great algorithm in interpreted Ruby will beat a stupid algorithm in C, with inline assembly microoptimisations, and an optimising C compiler. As a simple example, the linear-scan Fibonacci algorithm running in LanguageKit's interpreter mode is faster than the statically compiled recursive version in C after very small values of n. Having a language that encourages good algorithms is a much bigger win than having a language that encourages microoptimisation, in most cases (not for things like video decoding, image processing, and so on).


ICU Strings in C++

• std::string is the standard string class

• Non-virtual methods for speed

• Not flexible enough: everyone implements their own (e.g.llvm::StringRef, qt::QString, etc.)

• Using libicu strings involves O(n) operations, copyingcharacters between representations

• This problem happens at every library boundary

Author's Note

Comment

It seems to be a rite of passage that every single C++ project of a certain size implements its own string class. At boundaries between libraries, you typically have to convert from one to another, and the typical way of doing this is to export one as an array of unicode characters then import it. Doing this to use a libicu regular expression on a text document can involve copying hundreds of KB of data (often twice) for each search. This single operation costs more than you save with any number of microoptimisations.


ICU Strings in Objective-C

• NSString is the standard string class

• Abstract superclass, (hidden) concrete subclasses

• Very flexible, used everywhere.

• Using libicu strings involves an O(1) operation, wrapping thelibicu string type in an NSString subclass.

• Objective-C wrapper can be used in Pragmatic Smalltalkdirectly

Result: The ‘slower’ language encourages O(1) algorithms wherethe ‘faster’ language encourages O(n) algorithms.

Author's Note

Comment

Because Objective-C code uses an abstract string class, it's trivial to plug in new implementations. In the same case, we are allocating a couple of tiny objects (a few words long) - we can pass the NSString to libicu by wrapping it as an ICU UText ADT, and then wrap the returned UText as an NSString. We've finished the regex search before C++ has even finished providing the data to the library. Additionally, the NSString implementation uses a single method to get a range of characters, so you typically only have a single message send to get 32-64 characters, which can be much faster than a lot of C++ string classes...


Object Planes

• GNUstep runtime takes the sender as argument to lookupfunction

• Object Planes are now possible with the Objective-C runtime

• Messages intercepted when travelling between groups ofobjects

• Implicit concurrency, access control, automatic serialisation...

Author's Note

Comment

Object planes group objects into arbitrary groups. Message sends between objects in the same plane behave as they do currently. Message sends between objects in different planes are intercepted and can be modified. For example, we can serialise every message entering a plane for logging, we can add each message to a queue for implicit concurrency. We can restrict access, so we can run less-trusted code in one plane and restrict which objects it can talk to. The GNUstep Objective-C runtime has experimental support for object planes, but it's not enabled by default.


Building on Pragmatic Smalltalk

• Etoile aims to build a modern desktop environment

• Lots of frameworks

• User-visible code coming Real Soon Now


EtoileFoundation

• Higher order messaging

• Traits

• Futures

• Prototypes


EtoileUI

• High-level UI abstraction

• Introspective UI


CoreObject

• Automatic persistence and versioning

• Stores objects, not files

• Handles diff and merge on object graphs


EtoileBehavior

• Bundle, automatically loaded by all GNUstep applications

• Loads LanguageKit bundles - Smalltalk code injected into allrunning apps


Questions?

Gratuitous book plug!

pragmatic smalltalk

Technology

smalltalk objects

performance etoile smalltalk

abi smalltalk

smalltalk classes

smalltalk doesnt

traditional smalltalkplaying

objectivec code

objectivec blocks