On Fri, 2009-01-02 at 11:45 -0500, Eric S. Raymond wrote: > jeremy rosen <[email protected]>: > > 2) interpreted languages are not inherently slower, however I disagree > > with ESR in that machine are getting faster... not for wesnoth. We do > > have a handheld community with pentium-class machines, and we should > > take them into account > > We will lose some performance; Python has run-tine overhead that C++ > does not. However, we will gain it back in other ways: (a) smaller > code working set leading to fewer cache misses,
I'm afraid I don't understand this. You're saying that Python will result in the code that is loaded in memory will be smaller and so there will be fewer cache misses when loading code? I am incredibly doubtful of this: it implies that the Python interpreter and associated libraries are smaller than the Wesnoth engine. Even if it is so, I doubt that cache misses when loading code form a significant part of any kind of Wesnoth performance problems. On the other hand, I think that Python will perform much worse in terms of cache misses when accessing data. Python has to use a lot of hash tables, and they are not very nice to caches. > (b) higher-level > optimizations in Python, including a load-only-on-demand capability > that is already confirmed by loonycyborg to speed up game > initialization a great deal. What do you mean by the load-only-on-demand capability? What exactly is loaded only on demand? > > 5) I'm not very clear on what was implemented and what wasn't, the > > kind of job porting require what parts are impacted, what kind of job > > we're going into... remember I don't know python > > I'm still exploring this myself. It looks like Ivan has taken an > outside-in approach, implementing game_controller and play_controller > and the other high-level logic in the main loop first and leaving the > service classes in C++ to be called from the Python. That is, Python > has taken over the root of the static call tree with most of the > branches still in C++. This is sensible and, in fact, exactly how I > had planned to tackle the job. I tried Ivan's branch, and from what I can see, hardly anything is re-implemented. One can't start a campaign, multiplayer game, or the tutorial. Looking at the code it looks like only very few high level functions are ported. This is also the opposite of how I suggest doing it. I suggest switching over one component at a time, rather than doing a sweeping change, and make sure that Wesnoth works well at each point. David _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
