oldk1331 wrote:
>
> > Also, there is tricky balance
> > between speed and code size: for rarely executed code
> > the main cost is reading it from RAM and evicting
> > from cache more useful code. That can negate gains
> > from faster execution.
>
> Well, MAKELIST$Lisp is surely most RAM efficient and
> fastest.
I was probably unclear: code size matters in case of list
comprehension because each use is a separate copy of a template
and there are a lot of uses in the algebra.
Also, on my machine the following version:
new(n, e) ==
res := empty()
for i in 1..n repeat
res := cons(e, res)
res
which produces result in "reverse" order for long lists
has the same speed (within measurement noise) as MAKELIST
version. For short list it may be faster, because
'make-list' probably have few extra instructions to
parse keyword arguments.
Concerning RAM efficient: the version above is probably
of smaller than 'make-list'. Of course 'make-list' is
already contained in Lisp image, but code that we do
not use at all is cheap: there is resonable chance that
it will live only on disc and almost surely will not
get into caches.
> I want to know when it's worth to introduce a
> Lisp function instead of implement it in Spad?
Well some Lisp functions are "primitives", they offer
functionalty which is not available in other way.
Of course we need them. Then there are functions
which we introduce for performance. In particular
Spad compiler will only inline functions which
have single Lisp expression as implementation.
So if some operation should be inlined it has
to be implemented via call to Lisp macro/function.
Now, basically all functions could get some speedup
by providing optimized Lisp implementation. But
if you look at hand-written Lisp code you will
see that most is less optimized than code generated
by Spad compiler. Simply most of code is not
performance critical. So for most code clarity
and correctness are much more important. Now,
for typical Spad programmer Lisp code is an
opaque blob and hence less clear than Spad code.
So write in Spad unless you have strong reason
to use Lisp. That is there is significant
speed gain or using Lisp function say saves
effort to rewrite some substaial piece of code.
Note: speed gain of 10% in rarely used function
is insignifcant. Gain of 10% in freqently
used function is worthwile, but it is not
always clear if gain is real and robust.
That is there may be gain on benchmarks but
no gain (or even loss) in real use.
As an example, in the past two dimensional Spad
arrays were implemented as PrimitiveArray
of PrimitiveArray-s and element accessors
were Spad functions. Replacing Spad code
by Lisp macros gave about 20 times faster
array accessors. Given that array accessors
are frequently used in inner loops this
was a clear gain.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
