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
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.
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?
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.
TL;DR Is Haskell independently lazy about the values of a tuple? For a tuple (a,b), if a is always used but b is sometimes used can Haskell be lazy about b?
I am currently completeing an assignment where we are writing an interpreter for another programming language. One of the challenges is to add a debug option from the command line and have our program print debug output for the execution of the program. My implentation of this involves starting with an empty string which is passed through to every function to either add something to the debug string, pass it onto any called function to add something to it and then return whatever is passed back or the same debug string. At the end of the evaluation i have a tuple:
and if the debug flag was set then I putStrLn the debugString and otherwise I just putStrLn $ show results. I know this may be difficult to understand but my question is: If the debug flag is not set and I never call putStrLn debugString, will Haskell still evaluate the debug string (essentially a heap of string concatenations) or will it's laziness mean it never bothers. My uncertainty relates to the fact that it is a tuple and can Haskell be independently lazy about elements of a tuple?
Happy to clairfy if you leave questions in the comments.submitted by someGuyOnAComputer
[link] [31 comments]