The Future of the LispM

http://arrdem.com/2014/11/28/the_future_of_the_lispm/

by blue1 • 11 years ago

56 14 11 years ago

white-flame4• 11 years ago

The cache locality of linked list cells is a red herring. Garbage collectors seek to keep chained cons cells consecutive in memory.

Also, does the author not understand that most Common Lisp implementations are already built on assemblers implemented in Lisp, generally with portable intermediate representation DSLs generating native machine code?

bitwize• 11 years ago

The big lesson of performance computing has been this: if you have a garbage collector, you lose! Once you surrender control of how memory gets used to a GC, you WILL take a performance it. If you need to crunch through lots of data items and do it fast, use C++ and std::vector.

white-flame4• 11 years ago

If you have a constrained situation such that the iteration is known over a range of fixed-type consecutive data, any language should be able to generate the exact same optimized assembly as a manual C++ vector iteration.

Also, if it's large and you're bound by compute time rather than memory bandwidth, iterating a single vector will be slower than splitting it up between threads.

Also, if your data to work on is being streamed in, having to make the choices in managing the allocations & uses of std::vector buffers is much less useful than having the system heuristically balance in a more managed environment.

So, no, C++ std::vector isn't a silver bullet except for microbenchmarks, where other languages can (or should be able to) match. And vector iteration has nothing to do with GC.

ajro• 11 years ago

Having GC does not mean that you need to surrender all of control. You just need to know which operations are allocating memory (consing) and which are destructive. In Common Lisp you often have both variants available - like reverse & nreverse.

cemerick• 11 years ago

Which garbage collectors are you talking about, exactly? I presume you have particular Common Lisp implementations in mind, given your second comment. As the author discusses, there are more lisps than Common Lisp, and certainly more varieties of fundamental data structures than cons cells (regardless of the specializations certain implementations have towards optimizing them). The provided link to the Steele talk on optimizing parallel computations over diverse collections is quite relevant.

(Meta: is creating a sock puppet account really necessary to rag on a blog post?)

rdmckenzie• 11 years ago

Author here.

Oh. HN frontpage. That's cool I guess.

Well I have plans for today, so I'm sorry that I won't be sitting here defending my article.

However if you hit me up on twitter at the link at the bottom or email me at my listed email address I'd be more than happy to respond and debate this piece in due time.

Cheers! Reid

Animats• 11 years ago

LISP machines failed for a number of reasons, only some of which are LISP-related.

The Symbolics refrigerator-sized LISP machine was one of the most expensive single-user machines ever built. It was designed as the ultimate hacker toy, with a MIT Space Cadet keyboard.[1] Price/performance wasn't that great. Reliability was poor. Service was awful, because it needed on-site servicing and Symbolics didn't have enough local offices. The original garbage collector could take hours, because the virtual memory and the garbage collector did not play well together. Symbolics as a company was quite arrogant. They had the attitude "We are the one gateway to AI".

Soon, LISP compilers for UNIX workstations were written, and Symbolics lost their exclusivity. Later Symbolics products were better, but unnecessary. Around that time, the expert systems bubble deflated. So did the LISP industry.

(I once did a lot of work in LISP, but mostly on Franz LISP on Sun workstations. I used an early Symbolics refrigerator briefly. Cool, but inefficient.)

[1] http://en.wikipedia.org/wiki/Space-cadet_keyboard#mediaviewe...

FullyFunctional• 11 years ago

Some basic misunderstanding here: "However, as a stack machine architecture, there is no opportunity for the instruction level parallelism exploited by modern architectures as the exact state of the stack which is depended on by every instruction changes with every instruction. This forces all program execution to wait during slow operations like main memory reads, ..."

This is of course nonsense. Even an in-order implementation with non-blocking caches will let execution proceed in parallel with a load until the result is demanded. An actual out-of-order implementation will rename the (implicit) registers and proceed as normal.

The _only_ issue with stack architectures is that they are awkward (but not impossible) for compilers to generate optimized code for.

EDIT: I agree with basic motivation for pushing all the way to hardware (just not for Lisp). That's why I work on https://github.com/tommythorn/Reduceron

The Future of the LispM

Related Stories