4 ms·

> If you have a circuit that implements an algorithm, it can beat a program that implements the algorithm for a machine that lacks such a circuit. This is clear

> If you have a circuit that implements an algorithm, it can beat a program that implements the algorithm for a machine that lacks such a circuit. This is clear. You can't have all the algorithms implemented in hardware. How well would your CPU work for any algorithm unknown in advance? Would it beat a generic RISC CPU in some generic task, a video codec, for example? >The Lisp machine processors are far simpler than anything Intel, ARM, or MIPS have been putting out Do you have any benchmarks comparing Lisp processors to ARMs and MIPS in day-to-day tasks like compression algorithms, codecs, 3d rendering? > It's my understanding there were implementations of hardware, or at least descriptions thereof, explaining how such a bound could easily be cached and compared in tandem with other operations Do you have any resources on that? Would it work for complex convolutions (e.g. arrays of arrays of complex nums convoluted with arbitrary kernels)? In my statically typed programming language I know the matrix sizes in advance and could easily omit the runtime checks. Letting the CPU do so, I'm not sure if it would be as efficient as in compile time. >Why not? It's not unreasonable to expect the machine to have canonical and supported representations for commonly used forms of data and operations on such. Lists are not the main data structure anywhere beyond Lisp. And lists are frequently used in Lisp because of how Lisp is inexpressive in terms of data structures. Even in functional languages like ML or Haskell we use other data structures a lot: tuples, maps, hash tables, arrays, some ad-hoc inductive data structures. All of these are more effective when are not implemented in terms of lists. Architecture supporting at least tuples (arbitrary cons cells) would be bloated beyond any reason already. At least if you want them be as effective as cons cells on lisp machines.

verisimilitudes 7y ago
>You can't have all the algorithms implemented in hardware. How well would your CPU work for any algorithm unknown in advance? That depends. There are, clearly, however, some algorithms that are common enough to warrant inclusion in hardware. I feel you're not arguing in good faith if you believe basic arithmetic is warranted, but something extremely common, such as support for arbitrary-length arithmetic or exception systems aren't. >Do you have any benchmarks comparing Lisp processors to ARMs and MIPS in day-to-day tasks like compression algorithms, codecs, 3d rendering? No. >Do you have any resources on that? I dislike Wikipedia, but here: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine >Would it work for complex convolutions (e.g. arrays of arrays of complex nums convoluted with arbitrary kernels)? If the hardware supported it. If not, you'd likely build it out of the hardware support for simpler arrays. Having arrays of arrays is an easy solution, since then each axis could be checked in turn. >Letting the CPU do so, I'm not sure if it would be as efficient as in compile time. Again, it's not just about efficiency, but safety. This is an entire class of error prevented in hardware. That's useful.

verisimilitudes 7y ago

>You can't have all the algorithms implemented in hardware. How well would your CPU work for any algorithm unknown in advance? That depends. There are, clearly, however, some algorithms that are common enough to warrant inclusion in hardware. I feel you're not arguing in good faith if you believe basic arithmetic is warranted, but something extremely common, such as support for arbitrary-length arithmetic or exception systems aren't. >Do you have any benchmarks comparing Lisp processors to ARMs and MIPS in day-to-day tasks like compression algorithms, codecs, 3d rendering? No. >Do you have any resources on that? I dislike Wikipedia, but here: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine >Would it work for complex convolutions (e.g. arrays of arrays of complex nums convoluted with arbitrary kernels)? If the hardware supported it. If not, you'd likely build it out of the hardware support for simpler arrays. Having arrays of arrays is an easy solution, since then each axis could be checked in turn. >Letting the CPU do so, I'm not sure if it would be as efficient as in compile time. Again, it's not just about efficiency, but safety. This is an entire class of error prevented in hardware. That's useful.