looking at what the VM tests Sage farms out most of those tasks
[integration, differentiation, ODE] to Maxima, which is already
tested. We are currently in the process of implementing symbolic
caculus in Sage itself and will hopefully in the next year move
differentiation, limits and integration and so on away from Maxima
into the Sage core. This is motivated by the need for performance and
the fact that we want to dump any lisp based code from the core of
Sage in the long term.

Two things to watch out for if you start experimenting yourself (I
have /not/ tested these thoroughly, so they might not be repeatable):

1. Each input should be put in a separate input cell. If the
Expand[...] and the x=. are in the same input cell, Mathematica does
not release memory and the system starts swapping ...

2. It appears that if Share[] is executed after Expand[...], but /
before/ x=., then the timing value does not increase.

SzH>  You mean that you are able to run the Mathematica 6
SzH>  kernel continuously, performing random symbolic computations
SzH>  (like integration),

Well, the inputs the VM machine feeds into the MathKernel are not
totally random :)

Some of them are brute-force ones, but a tangible fraction of them
comes from some conditions the VM machine calculates trying to crash
the MathKernel.

(The VM machine, if set to such a task, always crashes Maple,
Mathematica, AXIOM, Maxima, Derive, and MuPAD; the concrete timing
depends on the initial parameters.

As of today, Derive 6.1 is the most stable computer algebra system
of the above-listed.

We observed some specific runs when Derive 6.1 had been operational
for about 3 weeks (!) of continuous calculations the VM machine forced
it to perform.)

SzH>  for 24 hours, without any problems?

Kind of this, in the average.

SzH>  That is better than what I expected.

:)

It was worse in Mathematica 5.2. But we feel that in Mathematica 6
some real improvements are introduced.

SzH>  How much memory does your machine have?

RAM is 4 Gb, and total free HDD size of about 500 Gb.

On Mar 29, 2:48 pm, SzH <szhor...@gmail.com> wrote:



On Mar 29, 9:50 pm, Vladimir Bondarenko <v...@cybertester.com> wrote:

For example, typically, if set to this task, the VM machine
can crash Maple 11 within 1 hour, Mathematica 6 within 1 day,
and Derive within 3 days.

You mean that you are able to run the Mathematica 6 kernel
continuously, performing random symbolic computations (like
integration), for 24 hours, without any problems?  That is better than
what I expected.  How much memory does your machine have?- Hide quoted text -

- Show quoted text -

On Mar 30, 2:38 am, Vladimir Bondarenko <v...@cybertester.com> wrote:





SzH>  You mean that you are able to run the Mathematica 6
SzH>  kernel continuously, performing random symbolic computations
SzH>  (like integration),

Well, the inputs the VM machine feeds into the MathKernel are not
totally random :)

Some of them are brute-force ones, but a tangible fraction of them
comes from some conditions the VM machine calculates trying to crash
the MathKernel.

(The VM machine, if set to such a task, always crashes Maple,
Mathematica, AXIOM, Maxima, Derive, and MuPAD; the concrete timing
depends on the initial parameters.

As of today, Derive 6.1 is the most stable computer algebra system
of the above-listed.

We observed some specific runs when Derive 6.1 had been operational
for about 3 weeks (!) of continuous calculations the VM machine forced
it to perform.)

This is another reason that it is so sad that Texas Instruments
stopped supporting Derive. Have you looked at TI's replacement for
Derive? I am not optimistic, but since they had Derive's source code
maybe they were able to preserve some of Derive's nice features.



SzH>  for 24 hours, without any problems?

Kind of this, in the average.

SzH>  That is better than what I expected.

:)

It was worse in Mathematica 5.2. But we feel that in Mathematica 6
some real improvements are introduced.

SzH>  How much memory does your machine have?

RAM is 4 Gb, and total free HDD size of about 500 Gb.

On Mar 29, 2:48 pm, SzH <szhor...@gmail.com> wrote:

On Mar 29, 9:50 pm, Vladimir Bondarenko <v...@cybertester.com> wrote:

For example, typically, if set to this task, the VM machine
can crash Maple 11 within 1 hour, Mathematica 6 within 1 day,
and Derive within 3 days.

You mean that you are able to run the Mathematica 6 kernel
continuously, performing random symbolic computations (like
integration), for 24 hours, without any problems?  That is better than
what I expected.  How much memory does your machine have?- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Thomas Richard actually provided info regarding Maple 11 behavior in
returning memory.

In[2]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[2]= {61.86, Null}
...
In[8]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[8]= {95.484, Null}

can Maple 11 get into a situation where its memory usage
is so scattered that it runs at "disk speed" even though
the actual data in use is not so voluminous.

And the vast majority of benchmarks do not take long term effects
or even memory consumption into account. The most famous example I can
come up with are Gröbner Basis computations comparing the Buchberger
algorithm with F4 or F5.

If we don't raise questions when people continue to compare CAS on
essentially irrelevant grounds, we are in the position of essentially
allowing others who read this newsgroup from accepting these comments
as valid.

Elephants are interesting and useful. Feathers are interesting
and useful.
Elephants with feathers are a curiosity. Is SAGE an elephant
with feathers?

rjf wrote:
Thomas Richard actually provided info regarding Maple 11 behavior in
returning memory.

We need to clear this up. I assume that if you're running programs
for days or weeks then you will have objects in memory that you need
to keep, so you can't use the restart command. This would not be
true for something like a web-based integrator that simply passes
independent problems to the system, but it would be true for a
complex program that maintains an internal state, like an airline
reservation program. Without restarting the kernel, Maple will
not return memory to the OS and the time for garbage collection
will grow (up to a limit).

It looks like Mathematica does the same thing:

SzH wrote:
In[2]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[2]= {61.86, Null}
...
In[8]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[8]= {95.484, Null}

I would like to say that this is not an entirely unreasonable
design, and that more advanced garbage collection techniques
could possibly reduce the overhead. The difference in time
is largely because the system has more memory allocated, which
means that the garbage collector has to scan more memory each
time a GC occurs. Scanning memory is not free. Computers have
finite memory bandwidth, on the order of a few GB/s. If you are
repeatedly scanning even 200MB, you will notice it. And you will
be hit twice because garbage collection flushes the L2/L3 cache.

Regarding your question:

can Maple 11 get into a situation where its memory usage
is so scattered that it runs at "disk speed" even though
the actual data in use is not so voluminous.

I can think of three situations where this could happen:
1) You have large objects in memory that are not being used.
The garbage collector still has to look at them.
2) You temporarily used a lot of memory. Modern operating systems
swap unused pages to disk, so even with GB allocated (because
memory is not released), the slowdown will be temporary if the
internal memory structures coalesce free space (they do).
You don't scan memory marked as "free".
3) There is a bug in the garbage collector

Also, replying to mabshoff now, I would really like to know what
you meant here:

mabshoff wrote:
And the vast majority of benchmarks do not take long term effects
or even memory consumption into account. The most famous example I can
come up with are Gröbner Basis computations comparing the Buchberger
algorithm with F4 or F5.

SzH wrote:
In[2]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[2]= {61.86, Null}
...
In[8]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[8]= {95.484, Null}

I would like to say that this is not an entirely unreasonable
design, and that more advanced garbage collection techniques
could possibly reduce the overhead. The difference in time
is largely because the system has more memory allocated, which
means that the garbage collector has to scan more memory each
time a GC occurs. Scanning memory is not free. Computers have
finite memory bandwidth, on the order of a few GB/s. If you are
repeatedly scanning even 200MB, you will notice it. And you will
be hit twice because garbage collection flushes the L2/L3 cache.

On Mar 31, 10:14 pm, Roman Pearce <rpear...@gmail.com> wrote:



SzH wrote:
In[2]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[2]= {61.86, Null}
...
In[8]:= Timing[x = Expand[(a + b + c + d + e + f + g)^34];]
Out[8]= {95.484, Null}

I would like to say that this is not an entirely unreasonable
design, and that more advanced garbage collection techniques
could possibly reduce the overhead. The difference in time
is largely because the system has more memory allocated, which
means that the garbage collector has to scan more memory each
time a GC occurs. Scanning memory is not free. Computers have
finite memory bandwidth, on the order of a few GB/s. If you are
repeatedly scanning even 200MB, you will notice it. And you will
be hit twice because garbage collection flushes the L2/L3 cache.

I didn't mean that this was a bug, I just found it a bit surprising.
I must say that (not being a programmer) I have no idea how garbage
collection algorithms work. But this page led me believe that
clearing the value of x (x =.) will restore the Mathematica kernel to
its original state (save for the existence of 'x' as a symbol with no
OwnValues):

http://reference.wolfram.com/mathematica/note/SomeNotesOnInternalImpl...

"Every piece of memory used by Mathematica maintains a count of how
many times it is referenced. Memory is automatically freed when this
count reaches zero."

If it works like this then why would a large amount of memory need to
be scanned explicitly?

Again, I am not a programmer, so sorry if this is a stupid question.
I read about a similar technique in Bruce Eckel's book: "Thinking in C+
+". From what I have learned there, I do not see why doing the same
calculation a second time would be slower than it was the first time.

Also, replying to mabshoff now, I would really like to know what
you meant here:

mabshoff wrote:
And the vast majority of benchmarks do not take long term effects
or even memory consumption into account. The most famous example I can
come up with are Gröbner Basis computations comparing the Buchberger
algorithm with F4 or F5.