7 ms·
Looks like very little attention has been paid to performance in favor of praying that psyco works on the player's system. I'm avoiding work and I've forked the
by swolchok 16y ago
Looks like very little attention has been paid to performance in favor of praying that psyco works on the player's system. I'm avoiding work and I've forked the project, so watch for a series of little perf tweaks. A few specific complaints:
Why are you using accessor methods? If it's because you might want to change them later, you could just use a property if that unlikely event happens. There is a real cost to accessors in Python. They also add a lot of visual noise.
Why did you make an enum class (ActionType)? That adds an extra hash table lookup for not much benefit over
ACT_SPAWN, ACT_MOVE, ACT_EAT, ACT_ATTACK, ACT_LIFT, ACT_DROP = range(6)
EDIT: the performance seems fine the way it is now. I made some changes but they didn't perceptibly change the way the game plays. I am grouchy today because I didn't get enough sleep. Sorry.
- phreeza 16y agoThanks a lot for your comments! Looking forward a lot to your tweeks, performance will definitely need to be optimized in the future. The problem I was trying to adress with the accessors and the whole *View concept is that there are no private members in python, and i was trying to prevent the minds/genomes from "cheating" by reading data they aren't allowed to. If you can think of a better way to do that, I'd love to hear from you.
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- jerf 16y agoLast I knew, the official word is that there is no way to stop Python code from reading any particular value. Python can even crack into the values contained in closures if you know the right incantations. If you are looking to rigidly enforce that only accepted interfaces are being used to read data in the face of a hostile adversary writing the Python, I believe the current state-of-the-art is that it is impossible. If this is a core feature requirement, then as far as I know your only option is to change languages to something where you can rigidly sandbox. Your nearest option in programming space would be Perl and some variant of Safe (that's a CPAN module name). Otherwise, if you can live with a gentleman's agreement, you're fine. This may make the automatic-online-matchup really tricky, though.
- amalcon 16y agoIs this true of all implementations? I know CPython and PyPy have this limitation, but might it be possible to make something work in IronPython, Jython, or some other project I'm as yet unaware of?
- devinj 16y agoPyPy has no such limitation. PyPy has perfect sandboxing.
- jerf 16y agoIs this ready for primetime? The documentation I found on it seems a bit tentative to me, but it may simply have not been updated. It is worth pursuing if so. Combined with standard OS limitation mechanisms, which I would certainly use in addition to this, it might at least be worth a try. I would wait to say PyPy has "perfect" sandboxing until it has been attacked for a while, though. CPython used to have a sandbox module, too. But at least PyPy has been designed with this use case in mind.
- devinj 16y agoPyPy's sandboxing hasn't been as thoroughly analyzed and tested as, say, Javascript's (not by far) or Java's, but the actual construction is simpler and arguably better. The PyPy devs, at least, are fairly convinced of its robustness. Basically they whitelist system calls and all other calls are translated to sandboxed calls during compilation of the sandboxed interpreter, as I recall. This is entirely different from CPython's restricted execution, which was essentially a blacklist of Python calls/attributes-- every attempt at such a system has died a death of a thousand cuts; it really pays to do it from the bottom up like PyPy or E. It might not be ready for prime-time in some very critical systems (like a web browser for example) but it's honestly probably good enough for this, especially in combination with process jailing as you suggest. I might consider trying to patch Cells up to use PyPy's sandbox instead of the non-solution currently implemented (I cried (okay, groaned) when I heard about it-- yeagh), when I have time, and if nobody else does it first. I'm a bit worried anything I write now would get lost or broken in the incoming tide of patches/changes anyway. The main problems with using PyPy's sandboxing is probably with communication to/out of the sandbox, which is apparently problematic. I also anticipate some complaints about relying on PyPy in the first place, which is rather abnormal compared to using CPython-- using and relying on PyPy-specific features is pretty much unheard of.
- ssadler 16y agoWould it work to store all the state in a python C module?
- swolchok 16y agoThe performance is actually not too bad the way it is right now.
- phreeza 16y agoAnd about the enum, valid point. Hangover from C.
- deleted 16y ago[deleted]