Just Testing

  • Archive
  • RSS

Seminar by Dave Thomas on “VMs Demystified – A Tour of the Engine Room”

Dave Thomas, who is widely known for his work on virtual machines and the YOW! Australia conference series, will be in Sydney this month. He kindly agreed to talk about VMs at CSE. Anybody with an interest in VM engineering and programming language implementations should mark the date in their calendar!

Time: 29 May 2013 (Wed), 11AM

Location: CSE Seminar room (K17_113), Level 1, CSE Building (K17)

Title: VMs Demystified – A Tour of the Engine Room

Speaker: David Thomas (Bedarra Research Labs and YOW! Developer Conference)

Also showing at: The talk is also presented at ScalaSyd the previous evening, 28 May, 18:30 — details here. 

Abstract

Language virtual machines are an essential part of current and next generation platforms.  Yet many developers have no real idea of what is actually happening when their program is run on a VM or the hardware.  This leads to many false assumptions about speed and space performance.  In this talk you will see under the hood of language virtual machines and gain an understanding of what makes VMs tick as well as differences between the languages they support.

First we explain the essence VM engineering including object representations, stack versus register VMs, RISC versus CISC byte codes; static dispatch to polymorphic inline cache; context management; interpretation versus dynamic translation/tracing versus compilation; garbage collection; and native types and code interfaces. We discuss benchmark speed and space performance versus real application performance.

Armed with the above knowledge we then engage in some of the entertaining educational VM debates. How can a JVM or PHP VM faster than C++? When is the JVM or CLR better? How does the language, or the language library impact the VM? Are strongly typed languages always faster than dynamic languages? How does hosting with CRuby, compare to JRuby or Java? Let’s put the VM in hardware? How do functional language VMs differ from object VMs? How can thousands of processes in Erlang be efficient compared to using native OS threads?

Bio

Dave Thomas is an expert in dynamic languages and has decades of experience building and deploying language VMs for mobile, instrumentation, embedded command and control, and business application on platforms from mainframes to micro devices. He is widely known and respected in the programming language community and this year will be presenting the keynote at the Commercial Users of Functional Programming (CUFP) conference. While CEO of OTI, now IBM OTI Labs, he over saw IBM’s Smalltalk and J9 family of Java enterprise and embedded JVMs, OSGi as well as the initial releases of Eclipse. He lead an IBM OTI research effort into universal virtual machines. After leaving IBM he worked on JVM support for dynamic languages and the use of V8 for embedded applications. For the past 6 years Dave has been working with high performance vector functional virtual machines, DSLs and most recently exploring special purpose HW VMs.

  • 3 weeks ago
  • 1
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Back to Tumblr

With the demise of Posterous (after it was swallowed by Twitter), my blog is back to Tumblr. I have got plans for a more customised set up in the medium term, but currently I don’t have the time to set up blogging software.

As the URL scheme of Posterous and Tumblr is different, this breaks all existing direct links to post. Moreover, many of the old posts include a footer that points back to the defunct Posterous, and comments are also gone. I’m sorry for the mess.

    • #blog
  • 3 weeks ago
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Optimising Purely Functional GPU Programs

We just completed a draft of a new paper, Optimising Purely Functional GPU Programs, that explains two crucial optimisations of Accelerate, our embedded array language for GPU programming in Haskell. These two optimisations are a novel typed form of sharing recovery for embedded languages and a new array fusion method for massively parallel SIMD programs. The paper includes details on eight benchmark programs that support the effectiveness of our optimisations and pit Accelerate against competing frameworks, including CUDA C code.

    • #accelerate
    • #edsl
    • #fusion
    • #gpgpu
    • #haskell
  • 1 month ago
  • 1
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Learn how to program GPUs with Haskell

Simon Marlow recently taught a course on parallel programming in Haskell at the EDF/CEA/INRIA Summer School 2012, “Functional Programming for Parallel and Concurrent Applications”. One of his lectures teaches GPU programming in Haskell with our Accelerate framework. If you like to learn to use Accelerate to program GPUs in Haskell, check out Simon’s slides on the topic as well as the accompanying programming exercises (see Page 14 onwards).

    • #accelerate
    • #gpgpu
    • #haskell
    • #parallelism
  • 9 months ago
  • 8
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Being more clever about vectorising nested data parallelism

Our new draft paper on Vectorisation Avoidance introduces a novel program analysis for nested data parallelism that lets us avoid vectorising purely scalar subcomputations. It includes a set of benchmark kernels that suggest that vectorisation avoidance improves runtimes over merely using array stream fusion.

    • #dph
    • #haskell
    • #parallelism
    • #vectorisation
  • 11 months ago
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Repa 3: more control over array representations with indexed types

We have got a new draft paper on Guiding Parallel Array Fusion with Indexed Types. It describes the design and use of the 3rd generation Repa API, which uses type indices to give the programmer control over the various parallel array representations. The result are clearer programs that the compiler can more easily optimise. The implementation of Repa 3 is ready for use on Hackage in the repa package.

    • #haskell
    • #multicore
    • #parallelism
    • #repa
  • 11 months ago
  • 1
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

GPU-accelerated array computations in Haskell

I just published stable release 0.12 of the embedded array language Accelerate for high-performance GPU computing on Hackage. The release includes example applications, such as a real-time Canny edge detector, a fluid flow simulator, and a quasicrystal animation, as well as example algorithms, such as radixsort, matrix computations, and a Black-Scholes option pricing model.

In the new modularised architecture, the Accelerate release comprises four packages:

  • accelerate (the main package providing the Accelerate language),
  • accelerate-io (conversion operations with other Haskell array libraries, including the data-parallel companion library Repa),
  • accelerate-cuda (backend targetting NVIDIA GPUs via the CUDA SDK), and
  • accelerate-examples (example applications and regression tests).
  • 1 year ago
  • 1
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Using the Glasgow Haskell Compiler (GHC) on OS X Lion with Xcode 4.3

Here is what you need to do if you want to use the Glasgow Haskell Compiler (GHC) on OS X Lion with a clean installation of Xcode 4.3.

Command line tools

You need to install the command line tools from Apple. You may do that in two ways (the second is faster as it is a much smaller download):

  1. Install all of Xcode:
    • Install Xcode from the Mac App Store.
    • Launch Xcode.
    • In the Preferences dialog of Xcode, select the “Downloads” pane and install “Command line tools”.
  2. Install the command line tools only:
    • At the downloads page of Apple Developer, download the latest “Command line tools”.
    • Install them.

In both cases, you need to register as an Apple developer. (This is a free registration.)

Install GHC 7.4.1 (or later)

Older versions of GHC —including GHC 7.0.4, which is part of the Haskell Platform 2011.4.0.0 (December 2011)— won’t work. They complain about not being able to execute ‘/Developer/usr/bin/gcc’.

Download and install GHC 7.4.1 (or a later version) — or install the Haskell Platform once a 2012 release has been made.

Using GHC’s LLVM backend (optional)

If you like to use GHC’s LLVM backend —which is more efficient for array-based and other loop-oriented code— you need to seperately install LLVM. (This is despite the Apple tools being based on LLVM as well.)

  • Install Homebrew (as per the instructions on that webpage).
  • Then, execute the following: ‘brew install llvm’

Compiling GHC from the sources in the Git repositories (GHC developers only)

If you plan to work on GHC itself and you need to compile the develeopment version of GHC straight from the Git repositories, you need to install the GNU auto tools as well (which are no longer distributed by Apple).

  • Install Homebrew (as per the instructions on that webpage) — if you didn’t do that already to install LLVM above.
  • Then, execute the following: ‘brew install autoconf automake’

The GHC Trac has more information on Building and Porting GHC.

    • #ghc
    • #haskell
    • #lion
    • #mac
  • 1 year ago
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

GPU computing in Haskell: version 0.10 of Data.Array.Accelerate

Accelerate is an embedded language for GPU-accelerated array computations in Haskell that targets NVIDIA’s CUDA framework and also has an experimental OpenCL backend (that currently does not support the whole feature set of the language). I just released version 0.10.0.0 of Accelerate. A considerable amount of example code is in the companion package accelerate-examples.

For more information, have a look at Accelerate on GitHub.

    • #accelerate
    • #gpgpu
    • #haskell
  • 1 year ago
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+

Work Efficient Higher-Order Vectorisation

Our new draft paper on Work Efficient Higher-Order Vectorisation introduces a novel representation for nested, irregular parallel arrays that enables the work-efficient SIMD-ification of nested data parallelism — i.e., nested parallelism is transformed into flat parallelism, while maintaining the work complexity of a naive pointer-based representation of nested arrays. This solves a long standing problem that dates back to the original implementation of the language NESL.

    • #dph
    • #haskell
    • #parallelism
    • #vectorisation
  • 1 year ago
  • Permalink
Share

Short URL

TwitterFacebookPinterestGoogle+
Page 1 of 14
← Newer • Older →

About

Avatar

I research and teach programming languages, compilers, and their applications at the University of New South Wales (UNSW), Sydney. My main interest is in functional and parallel programming. Most of my code is in Haskell.

You can find me on App.net (preferred) and Twitter, or on GitHub. Check out my UNSW website.

  • RSS
  • Random
  • Archive
  • Mobile
Effector Theme by Pixel Union