CUFP 2007 Abstracts
Invited Talk.
The Way it Ought to Work... and Sometimes Does
The default case in Haskell: Counterparty credit risk calculation at ABN AMRO
Nested Data Parallel Programming at Intel
Ct is a deterministic parallel programming model integrating the nested data parallelism ideas of Blelloch and bulk synchronous processing ideas of Valiant. That is, data races are not possible in Ct. Moreover, performance in Ct is relatively predictable. At its inception, Ct was conceived as a simple library implementation behind C++ template magic. However, performance issues quickly forced us to consider some form of compilation. Using template programming was highly undesirable for this purpose as it would have been difficult and overly specific to C++ idiosyncracies. Moreover, once compilation for performance was considered, we began to consider a language semantics that would enable powerful optimizations like calculational fusion, synchronization barrier elimination, and so on. The end result of this deliberation is an API that exposes a value-oriented, purely functional vector processing language. Additional benefits of this approach are numerous, including the important ability to co-exist within legacy threading programming models (because of the data isolation inherent in the model). We will show how the model applies to a wide range of important (at least by cycle count) applications. Ct targets both shipping multi-core architectures from Intel as well as future announced architectures. The corporate reception to this approach as (pleasantly) surprised us. In the desktop and high-performance computing space, where C, C++, Java, and Fortran are the only programming models people talk about, we have made serious inroads into advocating advanced programming language technologies. The desperate need for productive, scalable, and safe programming languages for multi-core architectures has provided an opening for functional, type-safe languages. We will discuss the struggles of multi-core manufacturers (i.e. Intel) and their software vendors that have created this opening.
For Intel, Ct heralds its first serious effort to champion a
technology that borrows functional programming technologies
from the research community. Though it is a compromise that
accommodates the pure in the impure and safe in the unsafe, this is an
important opportunity to demonstrate the power of functional
programming to the unconverted. We plan to share the technology
selectively with partners and collaborators, and will have a fully
functional and parallelizing implementation by year's end. At CUFP,
we will be prepared to discuss our long term plans in detail.
Terrorism Response Training in Scheme
From 1987 to 2002, we used a C++ multimedia engine scripted in 5L, the "Lisp-Like Learning Lab Language." This was Lisp-like in name only; it used a prefix syntax, but didn't even support looping, recursion, or data structures. We needed something better for our next project! We ultimately chose to use Scheme, because (1) it was a well-known, general-purpose programming language, and (2) we could customize it extensively using macros. Migrating to Scheme proved tricky, because we needed to keep releasing products while we were building the new Scheme environment. We began by carefully refactoring our legacy codebase, allowing us to maintain our old and new interpreters in parallel. We then rewrote the front-end in a single, 8-day hacking session. But even once the Scheme environment was ready, few of our employees wanted to use it. In an effort to make Scheme programming more accessible, we invested significant effort in building an IDE. Today, our environment is much more popular--a third of our employees use it on a regular basis, including several professional artists. After migrating to Scheme, we added support for 3D simulations. And Scheme proved its worth almost immediately: We faced several hard technical problems, which we solved by building domain-specific languages using Scheme macros. First, we needed to simulate radiation meters. For this, we used a reactive programming language to implement a Model-View-Controller system. Second, we needed to guide students through the simulation and make teaching points. For this, we relied on a "goal system," which tracks what students need to accomplish and provides hints along the way. In both these cases, Scheme proved to be a significant competitive advantage. Not all problems have clean imperative solutions. A language which supports functional programming, macros, and combinator libraries allows us to do things our competitors can't.
This summer, we'll be releasing our engine as open source, and
starting work on a GUI editor. We welcome users and developers!
Learning with F#
F# plays a crucial role in helping the group process this data efficiently
and develop smart algorithms that extract essential features from the
data and represent the information using the latest statistical techniques
called "factor graphs". Our use of F# in conjunction with SQL Server
2005 is especially interesting: we use novel compilation techniques
to express the primary schema in F# and then use SQL Server as a
data slave.
Productivity Gains with Erlang
The research clearly demonstrates that Erlang is not only a viable, but also a compelling choice when dealing with high availability system. This is due to the fact that it comparatively easy to construct systems that are
But most importantly these systems can be delivered at a much higher
productivity and with more maintainable deployed systems than current
technology. This is attributed to the language features such as
automatic memory and process management and high-level communication.
Furthermore Erlang interoperates at low cost with conventional
technologies, allowing incremental reengineering of large distributed
systems.
An OCaml-based Network Services Platform
This network platform serves as the basis for one of the most critical applications in our business: agent scheduling, and has proven to be easy to maintain and extremely scalable. Using commodity server hardware, we are able to support thousands of persistent SSL connections on a single dual-core Pentium-class server, and handle tens of thousands of transactions per minute. The application and platform are implemented in OCaml. This talk will briefly describe the application domain, discuss the specifics of the monadic I/O library we've built, and describe some of the issues involved. Our hope is that by the time that the conference arrives, the library will be released as open-source software.
Although developed independently, this work is the same vein as (and,
in some ways, validates) Peng Li and Steve Zdancewic's "A
Language-based Approach to Unifying Events and Threads", which is
appearing in the ACM SIGPLAN Conference on Programming Language Design
and Implementation (PLDI) in June 2007.
Using Functional Techniques to Program a Network Processor
Ideas from functional programming, and language design were key to programming this device. For example, 650 lines of Intel C for the IXP together with embedded assembly are required to just update the TTL and checksum fields of an IPv4 header; in our functional language, it is less than 40 lines! The functional semantics and novel compilation technology enables us to demonstrably out-perform hand coded assembly written by experts - a remarkable accomplishment by itself, and even more so in the embedded space. The critical components of the compilation technology is a big part of the puzzle, but are not directly FP related. The language and technology have been a phenomenal success, and easily surpass conventional approaches. The ease of learning, the dramatically lower cost, and superior performance make this the 'right' choice for deploying these devices. However, there are hard lessons learned from using FPL in the real world ...
Impediments to Wide-Spread Adoption of Functional Languages
Functional Programming in Communications Security
In this talk, I will describe some useful insights on how these languages have worked for us in developing security software. We had some successes: we've been able to build and ship fairly large software systems rather quickly and with good confidence in certain aspects of their security. We've also experienced some failures. Using functional programming doesn't protect against bad design. Implementations of functional languages are sometimes slow. The user base of many languages is small, and there aren't a whole lot of programmers on the market who can program well in, for example, Scheme.
Over the past few years, we've also seen some of the social phenomena
related to functional programming; how people feel about it, why they
believe it works/doesn't work, and why they are (not) interested in
doing it.
Cross-Domain DAV Server
October 4th 2007 |
||