Replies: 13 comments 13 replies
-
In WMA:
|
Beta Was this translation helpful? Give feedback.
-
For the first patch, the difference can be seen just by looking at how much time requires to run the full doctest suit. A more narrow test would be something like
|
Beta Was this translation helpful? Give feedback.
-
one more thing: in the first patch, we still are calling the conversion function by default. Do we want to keep that behavior? Otherwise,
should be
|
Beta Was this translation helpful? Give feedback.
-
Also, in the first patch, the assert fails if we pass an expression as a Head. For example, in
|
Beta Was this translation helpful? Give feedback.
-
Here we go with a first cut:
test 1: 'Timing[Fold[F,x,Range[500]];]'
Here are the branches: https://github.com/mmatera/mathics-core/tree/benchmark_patch1 |
Beta Was this translation helpful? Give feedback.
-
Here the same with Pyston 3.8.12 (2.3.4)
|
Beta Was this translation helpful? Give feedback.
-
Here are the comparison of the results (with mathics-bench run in gitpod) for 4.0.0 vs the current master (after merging PR #400): We can say that in some cases, we really gained a lot! |
Beta Was this translation helpful? Give feedback.
-
A few more benchmarks. These are not so good, but tell us that we probably can improve this a lot by adjusting some specific routines (for instance walk_parts) to use the new interface. |
Beta Was this translation helpful? Give feedback.
-
Overall, I think we are on the right track. Because there is a lot that goes up and a bit that goes down, what we give overall effect, and be transparent that some things slow down and in the following releases those will be addressed. I have said before that this just scratches the surface for speedups we can get for expr.evaluate and the rewrite_apply_eval. I was not expecting this by any means to be close to the complete in terms of what we can get. But the benchmarks can guide us as to where to focus on to get the biggest benefit. |
Beta Was this translation helpful? Give feedback.
-
With respect to Part and keeping properties in sync or not having to recompute them. The properties Flat, Order, and "fully evaluated" are often preserved when you simply remove pieces of a list and not change the order of the elements. |
Beta Was this translation helpful? Give feedback.
-
I have been thinking about what's up with the performance now versus when the Expression cache was doing more. I think what's going on here is that when there are list literals, caching was doing the same thing as the fully_evaluated property. However caching has to go throw a slow path once before it can detect if something is fully evaluated to get it into the cache, whereas with the property it doesn't. And that means we avoid work sooner. |
Beta Was this translation helpful? Give feedback.
-
Here are the benchmarks for the test_combinatorica, that I run over Gitpod: (NO_CYTHON=1)
At least for combinatorial, it seems that the current master provides significant improvements regarding the last version (20-30%). |
Beta Was this translation helpful? Give feedback.
-
Benchmarks run in my laptop (the reported values are the best of 3 runs)
Benchmarks run in my laptop (the reported values are the best of 3 runs)
|
Beta Was this translation helpful? Give feedback.
-
I'd like a volunteer to try these patches and see which ones are beneficial and should be applied.
Apply these using
patch -p1 < name-of-patch.diff
I will start with one that isn't so controversial and is a definite win:
There will be an alternate version of this with the commented out checking enabled. I haven't figured out the best way. It could just be something low-tech like manually uncommenting the code. Or a copy of the file with the uncommented parts.
This one I think is a simple change and a win too:
This detects "fixed-point"ednes (or evaluation stopping in lay speak) earlier in the evaluation cycle so and saves an iteration when we have a literal. When not there is an additional test.
Here are two somewhat patches rolled into one change:
I think we discussed this before, but I every time I think of it, it feels wrong: why again is a predefined Symbol not a literal value?
Also, strongly suspect Null should be predefined. If you were to remove or changes this in WMA I imagine havoc would rein.
As for the ability to redefine None inside a block, aside from it being a pretty dangerous and stupid thing to do. Probably the way we would implement this would be inside that block to define that as Symbol and not PredefinedSymbol inside that block. And I am not sure if it would have the "System`" part either, but it could as long as what's in the block is Symbol rather than PredefinedSymbol.
Please try these out and put in PRs for the ones you think should go in.
Beta Was this translation helpful? Give feedback.
All reactions