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
> 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 want to know
oldk1331 wrote:
> > BTW2: If you are worried that [...] is slower than
> > MAKELIST you should rather work on increasing speed
> > of list comprehesion (that is []). Current
> > version constructs list in reverse order and then
> > destructively reverses the result.
>
> It is possible to
> BTW: 'new' for lists exists mainly because of generic
> interface. However normally after 'new' aggregate
> is modified. In case of lists in almost all cases it
> will be more efficient to create list in incremental way
> using desired values instead of modification.
You do have a point, I
>
> I tested with "a := new(2*10^7,2)$List INT;", and before
> each call, I do a ")lisp (SB-EXT:GC)" to avoid GC during
> benchmarking.
>
> MAKELIST takes 0.29~0.33s, the loop takes 0.34~0.39s.
IMO it is not worth calling Lisp functions for rather small
gain.
BTW: 'new' for lists exists mainly
I tested with "a := new(2*10^7,2)$List INT;", and before
each call, I do a ")lisp (SB-EXT:GC)" to avoid GC during
benchmarking.
MAKELIST takes 0.29~0.33s, the loop takes 0.34~0.39s.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system"
oldk1331 wrote:
>
> > What is gain from this compared to:
> >
> > new(n, e) == [e for i in 1..n]
>
> It doesn't compile:
Right, we need:
new(n, e) == [e for i in 1..n]@List(S) pretend %
--
Waldek Hebisch
--
You received this message because you
> What is gain from this compared to:
>
> new(n, e) == [e for i in 1..n]
It doesn't compile:
compiling exported new : (NonNegativeInteger,S) -> $
** comp fails at level 1 with expression: **
error in function new
((COLLECT (STEP |i| 1 1 |n|) |e|))
** level 1 **
$x:=
oldk1331 wrote:
>
> new$List calls Lisp function directly, instead of repeatedly
> calling "concat".
>
> This change and the previous map! change probably
> should go into IndexedList, but I really think we should
> remove IndexedList :
>
> 1. It's not used anywhere beside List. (And probably
>
new$List calls Lisp function directly, instead of repeatedly
calling "concat".
This change and the previous map! change probably
should go into IndexedList, but I really think we should
remove IndexedList :
1. It's not used anywhere beside List. (And probably
nobody uses it.)
2. Unlike arrays,
10 matches
Mail list logo
