On Jul 27, 2017, at 2:07 AM, Pierre-Marie de Rodat <dero...@adacore.com> wrote: > On 07/27/2017 09:52 AM, Richard Biener wrote: >>> I'm fine with the direction if a reviewer wants to go in that >>> direction. I wish python didn't have a built-in speed penalty, >>> that's the only downside I don't like about it. Aside from that, >>> even switching all of the testsuite to be python based isn't a >>> terrible idea. >> But is it worse than TCL?
python is likely 2x faster than tcl, if you have one instance per testsuite run. The problem is, for the work required, it's cheaper to do the work once to cut over to a new language. I'd rather switch to some other language that can come closer to the speed of compiled C code, yet in the scripting family. I don't have a pointer to a better solution than python at this time. I'd not be opposed to switching to python, it should be faster, just as safe, a bit easier for new people to code in, and more people who know it and use it. I think python is funner to code in than tcl. Cutting the entire testsuite over at once, might well be more than any one person can contribute, but, we could cut over subtrees, as people donate time; if people want to go in that direction. This can't be a 1 person decision, but rather a consensus building type decision. What do others think? > Good point. Actually for Python there are ways to make it faster. If we can > somehow manage to have a limited set of Python interpreter instances (instead > of one per test), we could use pypy, which is very good I heard to make long > running instances fast. Yes. One instance would help ensure the performance is good. I don't have a firm grasp of startup time to know just how critical it is. Also, I don't have a good grasp on memory pressures that python would create, say, compared to how we use tcl.
