Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
speed of compilation
#1
do you think the compilation of speccy games would go faster if the compiler was written in a faster language like java?

btw yacc is available in java
Reply
#2
slenkar Wrote:do you think the compilation of speccy games would go faster if the compiler was written in a faster language like java?

btw yacc is available in java

for me, the compiler is excellent as it is, and the compilation speed is not such a big problem, at least for me
an excellent part of this compiler is mostly because it is coded in Python, a relativelly very easy and clean language to debug, providing a relativelly fast coding - for example, when you need 100 lines of Java for coding a 'hello world' example, on Python you just need 1 line.

and while Python interpreter is all software-libre for sure, Java isn't so clear about it (see those recent issues about Oracle-Sun related to Google and Android...)
Reply
#3
maybe what is missing on the compiler is a feedback from the terminal saying which part of the compiling process is in charge? i think most of the people associates the slowness with a kind of lack of feedback?
Reply
#4
Could zxbasic be compiled with the pypy compiler?

<!-- m --><a class="postlink" href="http://speed.pypy.org/">http://speed.pypy.org/</a><!-- m -->
Reply
#5
Slenkar, yes: I know of PyPy, and I've tried before to use it, but at least 18 month ago (1.5 years) pypy couldn't run ZX Basic.
I'm sure PyPy will eventually be able to run ZX Basic. ;-)

You can try yourself: download the Source Code version of the compiler from the download page (.zip file) and execute it with PyPy. :?:
(I will try myself this weekend, in my little spare time).
Reply
#6
I managed to get it to run,
it has problems with making a new makeoptemps class

you have to replace all gl.optemps.new_t()
with MakeopTemps.new_t()

dont forget to import Makeopttemps into every file that calls new_t

you also have to make new_t a static method

and remove the __new__ method as it is not needed is all methods are static (except new and init)
count has to be a static field just like _singleton

then it will complain about indentation, this is because you used tabs instead of spaces about 3 times in one file, just replace the tabs with spaces and it will work
Reply
#7
Confusedhock: So it run *already* ??????
Thanks!!! :-)

Note: I was asking you just to run pypy zxb.py, nothing else. You didn't need to go so far :!:
I will try your suggestions. Maybe a pypy version can be packed??

Again thanks a lot!!

slenkar Wrote:I managed to get it to run,
it has problems with making a new makeoptemps class

you have to replace all gl.optemps.new_t()
with MakeopTemps.new_t()

dont forget to import Makeopttemps into every file that calls new_t

you also have to make new_t a static method

and remove the __new__ method as it is not needed is all methods are static (except new and init)
count has to be a static field just like _singleton

then it will complain about indentation, this is because you used tabs instead of spaces about 3 times in one file, just replace the tabs with spaces and it will work
Reply
#8
I didn't understand what MakeopTemps is or how is implemented.
Simply, I finally didnt use a singleton (this is a reminiscence of a previous idea). So basically:

1) Removed tabs in zxbtrad.py (this was always intended, anyway)
2) Implementes opcodestems.py as:
Code:
class __Singleton(object):
    pass

singleton = __Singleton()
singleton.table = {}
singleton.count = 0

class OpcodesTemps(object):
    ''' Manages a table of Tn temporal values.
        This should be a SINGLETON container
    '''
    def __init__(self):
        self.data = singleton

    def new_t(self):
        ''' Returns a new t-value name
        '''
        self.data.count += 1
        return 't%i' % (self.data.count - 1)

These are the test benchmarks (compiling the Ocman.bas pacman):

time ./zxb.py ocman.bas -TaB
real 0m43.375s
user 0m37.190s
sys 0m6.188s

time pypy ./zxb.py ocman.bas -TaB
real 1m39.561s
user 1m35.534s
sys 0m3.984s

So pypy makes it worse (I have to make more testing, anyway). This might happen if the overhead introduced by pypy (compiling python into binary) supersedes the execution time.

Now with -O3 optimization:

./zxb.py -O3 ocman.bas -TaB
real 3m26.474s
user 3m18.344s
sys 0m8.105s

pypy ./zxb.py ocman.bas -TaB -O3
real 2m4.628s
user 1m59.691s
sys 0m4.912s

Great!! Using -O3 optimization is about 30-40% faster.
This is because -O3 loops a lot searching possible optimization cases, etc. I think we can investigate this further...
Reply
#9
after that first set of tests I was like oops but after the second i was relieved.

Can pypy make executables for windows and linux? its supposed to translate code to C I think


what do real user and sys mean?
edit-
Quote:'Real' is wall clock time - time from start to finish of the call. This is all elapsed time including time slices used by other processes and time the process spends blocked (for example if it is waiting for I/O to complete).

'User' is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

'Sys' is the amount of CPU time spent in the kernel within the process. This means executing CPU time spent in system calls within the kernel, as opposed to library code, which is still running in user-space. Like 'user', this is only CPU time used by the process.
Reply
#10
I have located where 70% of the time is gone :oops: In the *PREPROCESSOR* :!:
This seems to be another pathological case (Like the one fixed in 1.2.5). I've worked on it a little, and have reduced compile time by 10-20 seconds in the above examples. But this will hard to fix, I'm afraid.


time ./zxb.py ocman.bas -TaB -O3
real 3m6.317s
user 2m57.299s
sys 0m8.853s

time pypy zxb.py scratch/ocman.bas -O3 -TaB
real 1m56.425s
user 1m52.179s
sys 0m4.244s

(compare with the previous test above; notice there's little difference with pypy: it already optimizes!)
Reply
#11
ooh nice optimisations there
Reply
#12
Good news. I got the performance bottleneck fixed! :!:

I was puzzled, because with default optimization I got:

time ./zxb.py ocman.bas -TaB
real 0m43.375s
user 0m37.190s
sys 0m6.188s

./zxb.py -O3 ocman.bas -TaB
real 3m26.474s
user 3m18.344s
sys 0m8.105s

---

And now I got:
time ./zxb.py scratch/ocman.bas
real 0m16.769s
user 0m16.497s
sys 0m0.256s

time ./zxb.py scratch/ocman.bas -O3 -TaB
real 2m55.524s
user 2m53.971s
sys 0m1.516s

I will upload this new version tonight.
Reply
#13
why does the normal version out-perform the pypy version now? Confusedhock:
Reply
#14
slenkar Wrote:why does the normal version out-perform the pypy version now? Confusedhock:

The above was without using PyPy!
With pypy times are now:

time pypy ./zxb.py scratch/ocman.bas -TaB
real 0m41.404s
user 0m40.359s
sys 0m1.048s

time pypy ./zxb.py scratch/ocman.bas -O3 -TaB
real 1m14.543s
user 1m12.613s
sys 0m1.920s

Again, as before: -O3 is where pypy shows its value. If you don't use -O3 then zxb.py is enough.
Reply
#15
Okay, the new version, 1.2.9s888 is available for download.
Please, give it a try :roll:
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)