Intel Haskell Research Compiler
github.com
github.com
It's interesting that HRC makes relatively significantly optimized programs (up to 2x), but that GHC's runtime (which HRC is not using) is so well optimized that the performance of HRC programs is roughly on par with those from GHC, despite the programs themselves being more performant.
I find stuff like this to be a testament to the practicality of great design in functional programming language ecosystems: Even the compilers are composable!
[0]: For those unfamiliar with what GHC does/how it's designed, this talk gives a great overview of the Core language that is the optimized IR of GHC: https://www.youtube.com/watch?v=uR_VzYxvbxg
Looks like good research mixed with good, engineering tradeoffs.
> The Intel Labs Haskell Research Compiler uses GHC as a frontend, but provides a new whole-program optimizing backend by compiling the GHC intermediate representation to a relatively generic functional language compilation platform.
and later:
> For certain classes of programs, our platform provides substantial performance benefits over GHC alone, performing 2x faster than GHC with the LLVM backend on selected modern performance-oriented benchmarks; for other classes of programs, the benefits of GHC's tuned virtual machine continue to outweigh the benefits of more aggressive whole program optimization. Overall we achieve parity with GHC with the LLVM backend.
Source: https://www.semanticscholar.org/paper/The-Intel-labs-Haskell...
I can't wait to dig in and finally learn more than I could at after-conference drinks :-)
> FLRC is open sourced as is. We at Intel Labs are no longer actively working on this compiler.
Some number of years ago I worked in Intel's software labs. It really drove home to me the point that software development is a long attention span activity, and chip development is a short attention span activity. Mixing both at the same company is difficult. A chip design has a short shelf life, and zero field upgradability, so to be successful building chips you drive hard to tape out, and then move on to the next iteration as soon as possible. Software, OTOH, is a many-years-long process of incremental improvement and field updates.
Trying to do software development in a company where much of the management are "sand heads" (physical chemists that came up through the chip world) requires dealing with a huge cultural communication gap.
There's a lot of patience for building labs and improving physical infrastructure (which is carried from one activity to the next activity), but much less patience for iterative development of non-physical infrastructure. As an experienced software person told me, "they really want something they can kick" to show the point of making an investment.
If the hardware design is dictated by computer modeling, this can be a point of overlap, in which everyone can agree that patient investment in software is a competitive advantage.
Common Lisp is about the only software I would consider declaring long attention span.
The fixed nature of a chip requires far more attention than something you can push an update to.
"Ship it and fix it later" was pioneered by the software industry. That is the essence of short attention span, unconcern about details.
Maybe we mean different things by that.
The act of actually swapping a chip is easier for the end user than software patching. Open the case, pull this out, put this in its place, done.
Not to mention that it can be reverted. Something wrong? Pop the old one back in. Not always possible with software updates; that has to be designed in.
Less can go wrong. You're not going to half-install a chip, leaving everything corrupt with no way to revert. Unless you damage the old and new.
You can always swap in a good chip from a spare donor device. Doesn't always work that way with software. There may be no easy access to get to the piece you need in the donor device. The device which needs it could be so bricked that you can't run the procedure to put it in.
Overall, I'd say that in the area of aftermarket patching, hardware basically wins.
:)
That's a rather selective and misleading comparison. The Javascript language is over 20 years old.
The uses of Javascript you're presumably referring to are mainly in user interfaces, a deceptively challenging problem which hardware companies are notoriously bad at.
> Common Lisp is about the only software I would consider declaring long attention span.
C is much older than Common Lisp. C++ is about the same age as Common Lisp.
But perhaps you're thinking of Lisp in general, including the predecessors to Common Lisp, in which case you should probably also mention Fortran.
Looking at other widely used programming languages today, Python is over 25 years old, only about 7 years younger than Common Lisp. Java is also more than 20 years old.
All of these languages are still widely used, in many actively used applications that themselves are 20+ years old, in every conceivable application domain.
In short, the distinction you're trying to make isn't at all clear.
"Much older" here denotes five years.
The ANSI C committee was formed in 1983. The Lisp one in 1986; however, by then Common Lisp was already a thing with Guy Steele's book published (1984). That all started around 1982, supposedly. (Wikipedia: "Work on Common Lisp started in 1981 after an initiative by ARPA manager Bob Engelmore to develop a single community standard Lisp dialect.[6] Much of the initial language design was done via electronic mail.[7][8] Guy Lewis Steele, Jr. gave at the 1982 ACM Symposium on LISP and functional programming the first overview of Common Lisp.")
ANSI CL is rooted in some Lisp dialects which precede the entire development of C.
COBOL. Fortran. PL/I. C. C++. Ada. Java, C#, and PHP possibly given enough time. Hopefully, Python is on that list too as it wouldn't be a bad language to get stuck in for a legacy codebase. Far as massively popular ones go, at least.
""Ship it and fix it later" was pioneered by the software industry."
Planned obsolescence was pioneered by the hardware industry. Appliances especially. Software split between that and lock-in. Mainstream hardware is throw-away these days. You're right that hardware sticks around longer than a lot of software on average.
GHC can use this intermediate code (a-la LLVM) to produce executable. The idea is to create an intermediate code which is better optimised for their CPU.
Also, the related paper for this project is quite interesting and insightful: http://www.leafpetersen.com/leaf/publications/hs2013/hrc-pap...
A core design principle of Haskell is that while the whole language has gotten relatively complex thanks to all its language features and extensions, almost everything can be simplified to a really small and elegant core language. This core language is a typed lambda calculus that looks a lot like a subset of Haskell except with a few changes like no type inference and different rules for strictness.
GHC then uses this pared down version of Haskell (appropriately called Core) for the rest of its optimization and compilation. This means that once the first pass is done with type inference, type checking, typeclass resolution and a lot of other high-level transformations, the rest of the compiler doesn't have to worry about them at all. This makes all of GHCs optimizations easier to implement and maintain, and it lets us add features to Haskell without needing to change the backend.
https://www.microsoft.com/en-us/research/publication/the-imp...
Or does the sugar carry no such information?
More importantly, any modern compiler is very far from the producing the most optimal possible programs. Overall performance could be improved pretty much anywhere, and the tradeoffs involved make operating on the "whole" language a far lower priority than pretty much anything else.
Parsing the language isn't a very interesting research problem, and more work than it's worth, so Intel have chosen to instead use GHC's frontend to generate Core code, and then consume Core for their compiler backend.
An excellent overview: http://www.aosabook.org/en/ghc.html