I think the CST stage is now slower than before. I assume this is due to the recent change to the Piraha parser. Are we currently using the final, optimized implementation, or is there still debug code that will be disable in time?
-erik
Hello Erik,
I think the CST stage is now slower than before. I assume this is due to the recent change to the Piraha parser. Are we currently using the final, optimized implementation, or is there still debug code that will be disable in time?
I asked the same question and (par for the answer is): it is at parsing it with both methods and then comparing so it must be strictly slower :) This also qualifies for "debug code" I guess.
Yours, Roland
On Thu, Feb 16, 2017 at 04:34:35PM -0600, Roland Haas wrote:
I asked the same question and (par for the answer is): it is at parsing it with both methods and then comparing so it must be strictly slower :) This also qualifies for "debug code" I guess.
The idea is to catch cases where the new parser gets to a different result than the old, especially for thorns we don't have access to. I wouldn't call it 'debugging', since there is nothing to debug at the moement, maybe verification - but that is just a name anyway.
The more interesting question is: how much slower did it get for individual users - and was it piraha or something else? It shouldn't be much more than twice as slow, because otherwise it would mean piraha would be slower than the old method. It would still be better than the old method, and it was never meant as a replacement for efficiency reasons, but it would be interesting to know what the difference is.
Steve (I know you are out of town, but at some point you are going to read this): is there an easy way to temporarily disable one or the other method, so that a speed-test could be made by anyone, on their system, with their thorns?
Frank
On 17 Feb 2017, at 05:04, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, Feb 16, 2017 at 04:34:35PM -0600, Roland Haas wrote:
I asked the same question and (par for the answer is): it is at parsing it with both methods and then comparing so it must be strictly slower :) This also qualifies for "debug code" I guess.
The idea is to catch cases where the new parser gets to a different result than the old, especially for thorns we don't have access to. I wouldn't call it 'debugging', since there is nothing to debug at the moement, maybe verification - but that is just a name anyway.
The more interesting question is: how much slower did it get for individual users - and was it piraha or something else? It shouldn't be much more than twice as slow, because otherwise it would mean piraha would be slower than the old method. It would still be better than the old method, and it was never meant as a replacement for efficiency reasons, but it would be interesting to know what the difference is.
Do we expect Piraha to be faster than the old method?
-- Ian Hinder http://members.aei.mpg.de/ianhin
Hello all,
Do we expect Piraha to be faster than the old method?
I would expect it to be slower. The old method was just applying a couple of regular expressions to each input line with any data structures or other code involved. Piraha first parses using regular expressions for each part then builds a syntax tree and works its way through that tree. So more work I think. However I do not know if it does enough work to make it measurably slower (rather than say 1 ms slower out of 20 s due to being limited by IO latency anyway).
Yours, Roland
I can introduce a flag to disable the training wheels. I'll try and do it when I get back.
--Steve
On 02/16/2017 11:04 PM, Frank Loeffler wrote:
On Thu, Feb 16, 2017 at 04:34:35PM -0600, Roland Haas wrote:
I asked the same question and (par for the answer is): it is at parsing it with both methods and then comparing so it must be strictly slower :) This also qualifies for "debug code" I guess.
The idea is to catch cases where the new parser gets to a different result than the old, especially for thorns we don't have access to. I wouldn't call it 'debugging', since there is nothing to debug at the moement, maybe verification - but that is just a name anyway.
The more interesting question is: how much slower did it get for individual users - and was it piraha or something else? It shouldn't be much more than twice as slow, because otherwise it would mean piraha would be slower than the old method. It would still be better than the old method, and it was never meant as a replacement for efficiency reasons, but it would be interesting to know what the difference is.
Steve (I know you are out of town, but at some point you are going to read this): is there an easy way to temporarily disable one or the other method, so that a speed-test could be made by anyone, on their system, with their thorns?
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Thu, Feb 16, 2017 at 05:22:36PM -0500, Erik Schnetter wrote:
I think the CST stage is now slower than before. I assume this is due to the recent change to the Piraha parser. Are we currently using the final, optimized implementation, or is there still debug code that will be disable in time?
It currently has to be slower, because it is parsed twice and the results is compared. This is intended to be temporary. Can you quantify how much slower?
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Roland Haas -
Roland Haas -
Steven R. Brandt