3 ms·

Not only are FPGAs as far from the ideal of "computation as reduction" expressed in the paper as they could possibly be, but they're the hardest machine to fit

by _yosefk 10y ago

Not only are FPGAs as far from the ideal of "computation as reduction" expressed in the paper as they could possibly be, but they're the hardest machine to fit into this sort of a paradigm. The typical CPU will run functional code fairly efficiently if enough work is put into the compiler (to some functional programmers this sounds bad because hardware should make writing functional language compilers easy. People who know about hardware make a different conclusion - that hardware is just fine, as Ken Thompson said, "the PDP-11 is a fine Lisp machine, it's not a language special enough to warrant a specialized machine.") The typical accelerator is a harder target to a general-purpose functional programming language (it's a poor target for a general-purpose imperative language to begin with.) The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. In general, the farther away a commercially significant machine is from the classical von Neumann architecture, the more terrible target it is for functional languages, which never prevented FP aficionados from talking about "the end of Moore's law bringing about the long-awaited demise of the von Neumann machine", a "demise" that largely doesn't happen and where it does, it does not mean what they think it means.

nickpsecurity 10y ago
What about PLA or PAL? Such tech seems closer to functional programming than FPGA's.
catnaroek 10y ago
> to some functional programmers this sounds bad because hardware should make writing functional language compilers easy. People who know about hardware make a different conclusion - that hardware is just fine, as Ken Thompson said, "the PDP-11 is a fine Lisp machine, it's not a language special enough to warrant a specialized machine." Wow, really? C got a lot of things wrong, but the one thing that it got right is its abstract model of the machine. As a functional programmer, rather than specialized hardware, what I want is functional languages designed to target the abstract C machine. (Though maybe I am in a minority.) > The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. Explicit resource management is compatible with functional programming, but it requires a type system capable of undestanding the ephemeral nature of resources, à la Rust.
chillingeffect 10y ago
> The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. That's a great way to put it... but perhaps there's a more suitable FPGA cell for functional programming (than block lookup tables with state)? Maybe something with a local stack, recursion assistance, an iterator? Also, a good deal of the FPGA resource management is focused on optimization... What if the optimization-at-all-costs constraint were relaxed somewhat, or supplanted with meta-information to indicate the completion of a group of cells to allow a message to propagate? With relaxed constraints partial, on-the-fly and self- modifications could become regular features.
- adwn 10y ago
  > Maybe something with a local stack, recursion assistance, an iterator? [...] supplanted with meta-information to indicate the completion of a group of cells to allow a message to propagate? What you're describing sounds a lot more like many CPU cores connected by a network than like an FPGA. The point of an FPGA is that it gives you very precise and flexible control over things like timing and interconnects. Without that, FPGAs are actually pretty slow and you'd better use a CPU. > With relaxed constraints partial, on-the-fly and self- modifications could become regular features. There's a reason why self-modifying software is restricted to niche use cases: it's hard to reason about. Dynamic partial reconfiguration is slowly becoming a thing in FPGA design, but it's typically used to work around resource limitations.
lmm 10y ago
> The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. Huh? The greatest strength of functional languages is to allow you to explicitly manage cross-cutting concerns, no?

by _yosefk 10y ago

nickpsecurity 10y ago

What about PLA or PAL? Such tech seems closer to functional programming than FPGA's.

catnaroek 10y ago

> to some functional programmers this sounds bad because hardware should make writing functional language compilers easy. People who know about hardware make a different conclusion - that hardware is just fine, as Ken Thompson said, "the PDP-11 is a fine Lisp machine, it's not a language special enough to warrant a specialized machine." Wow, really? C got a lot of things wrong, but the one thing that it got right is its abstract model of the machine. As a functional programmer, rather than specialized hardware, what I want is functional languages designed to target the abstract C machine. (Though maybe I am in a minority.) > The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. Explicit resource management is compatible with functional programming, but it requires a type system capable of undestanding the ephemeral nature of resources, à la Rust.

chillingeffect 10y ago

> The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. That's a great way to put it... but perhaps there's a more suitable FPGA cell for functional programming (than block lookup tables with state)? Maybe something with a local stack, recursion assistance, an iterator? Also, a good deal of the FPGA resource management is focused on optimization... What if the optimization-at-all-costs constraint were relaxed somewhat, or supplanted with meta-information to indicate the completion of a group of cells to allow a message to propagate? With relaxed constraints partial, on-the-fly and self- modifications could become regular features.

adwn 10y ago
> Maybe something with a local stack, recursion assistance, an iterator? [...] supplanted with meta-information to indicate the completion of a group of cells to allow a message to propagate? What you're describing sounds a lot more like many CPU cores connected by a network than like an FPGA. The point of an FPGA is that it gives you very precise and flexible control over things like timing and interconnects. Without that, FPGAs are actually pretty slow and you'd better use a CPU. > With relaxed constraints partial, on-the-fly and self- modifications could become regular features. There's a reason why self-modifying software is restricted to niche use cases: it's hard to reason about. Dynamic partial reconfiguration is slowly becoming a thing in FPGA design, but it's typically used to work around resource limitations.

lmm 10y ago

> The FPGA, with its explicit management of every imaginable resource, is the worst target for a general-purpose functional programming language. Huh? The greatest strength of functional languages is to allow you to explicitly manage cross-cutting concerns, no?