[Openmcl-devel] Lisp Comparison

[David McClain]

++1

- DM


> On Apr 18, 2017, at 18:45, Ron Garret <ron at flownet.com> wrote:
> 
> Nowadays I always use abstract associative maps so I can swap out the implementation without having to change any code (even at run time!  This is Lisp after all :-)
> 
> My code is part of ergolib:
> 
> https://github.com/rongarret/ergolib
> 
> Ironically, I forgot to document the abstract associative map (a.k.a. dictionary) code, but here’s a quick primer:
> 
> (defvar *d* (make-dictionary &optional (implementation-type ‘hash-table))
> 
> or
> 
> (defvar *d* (-> key value key value …))  ; So (->) is shorthand for (make-dictionary)
> 
> (ref d key)
> 
> (setf (ref d key) value)
> 
> (change-implementation *d* implementation-type)
> 
> Existing implementation types: hash-table (synonym for eql-hash-table), weak-hash-table, eq-hash-table, equal-hash-table, equalp-hash-table, plist, alist, dlist.  (A DList is an associative map where the keys and values are stored as two separate lists, allowing the keys structure to be shared across many dictionaries with the same keys.)
> 
> It’s easy to add your own implementation types (e.g. binary trees).
> 
> REF works on pretty much anything that can be dereferences, not just dictionaries.  It subsumes gethash, get, assoc, nth, elt, slot-value, and probably a few other things that I can’t remember offhand.
> 
> rg
> 
> On Apr 18, 2017, at 5:33 PM, David McClain <dbm at refined-audiometrics.com> wrote:
> 
>> … years ago, at Raytheon, I wrote a quick missile data analysis and reduction code in Lispworks. It ran just great, until the techs in the lab threw a ton of data against it. The huge slowdown (very much like you are seeing), was found to be my use of linear lists and ELT. Change that to an array, or a hash table, and vroom!! But I got called down to the lab after my quick little routine hit the 4 hour mark. No kidding.
>> 
>> - DM
>> 
>> 
>>> On Apr 18, 2017, at 17:31, David McClain <dbm at refined-audiometrics.com> wrote:
>>> 
>>> Wow! sounds like a code review is really a good idea. Need to learn what *not* to do in the future…
>>> 
>>> - DM
>>> 
>>>> On Apr 18, 2017, at 17:28, Ron Garret <ron at flownet.com> wrote:
>>>> 
>>>> That would have been my first thought too, but CCL doesn’t have an interpreter.  It always compiles everything.
>>>> 
>>>> On Apr 18, 2017, at 5:25 PM, David McClain <dbm at refined-audiometrics.com> wrote:
>>>> 
>>>>> Wow, sorry about the confusion here… That really does sound like plain interpreted code versus natively compiled code. A good bytecode compiler / closure “interpreter” will give 5:1. But I have seen 100:1 in simple minded interpreters vs native code. Looks like something is really off here.
>>>>> 
>>>>> Definitely, a profile is called for. I truly doubt that the underlying Lisp implementation is at fault. 
>>>>> 
>>>>> - DM
>>>>> 
>>>>> 
>>>>>> On Apr 18, 2017, at 16:54, Pierpaolo Bernardi <olopierpa at gmail.com> wrote:
>>>>>> 
>>>>>> On Wed, Apr 19, 2017 at 1:34 AM, David McClain
>>>>>> <dbm at refined-audiometrics.com> wrote:
>>>>>> 
>>>>>>> Still, if running something like this produces results on a laptop, does it really matter whether it happens in 7 sec or 30 sec? Is this the kind of code that would be placed into continuous service and production? Or just something to give you some answers to chew on?
>>>>>> 
>>>>>> It's 8 seconds vs 24 minutes, 180 times slower. It certainly does matter.
>>>>>> 
>>>>>> (I have never observed such a big difference between sbcl and cll,
>>>>>> thought. Something very unusual must be going on)
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Openmcl-devel mailing list
>>>>> Openmcl-devel at clozure.com
>>>>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 
>