I've just compiled the ShedSkin 0.9.1 on my Ubuntu 11.10 8 core laptop
and tried the c64 demo with/without ShedSkin - very nice! I get around
3-5fps without and 80-120fps with it.
I'll be updating my course notes, I'll re-run the Mandelbrot code and
report back if anything looks odd (though hopefully there'll still be
a nice story to tell between ShedSkin and PyPy/Cython :-)
Ian.
--
Ian Ozsvald (A.I. researcher)
i...@IanOzsvald.com
http://IanOzsvald.com
http://MorConsulting.com/
http://StrongSteam.com/
http://SocialTiesApp.com/
http://TheScreencastingHandbook.com
http://FivePoundApp.com/
http://twitter.com/IanOzsvald
I also meant to ask - is IK+ playable? I tried hitting various keys but it just played the demo.
Ian
On Mon, Feb 6, 2012 at 3:26 AM, Ian Ozsvald <i...@ianozsvald.com> wrote:
> I also meant to ask - is IK+ playable? I tried hitting various keys but it
> just played the demo.
thanks!! no, I'm afraid not.. not with the current version of the
emulator in shedskin/examples. F1 is used to start the game, but it
results in a garbled screen. I just tried the upstream version, same
result.. :S
thanks again,
mark.
> --
> You received this message because you are subscribed to the Google Groups
> "shedskin-discuss" group.
> To post to this group, send email to shedskin...@googlegroups.com.
> To unsubscribe from this group, send email to
> shedskin-discu...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/shedskin-discuss?hl=en.
Do you have a gut feel whether the emulator might run in PyPy (i.e.
can the GUI component be easily removed)? I'm not thinking of doing it
now but I'm sure someone will ask.
In my rough testing today ShedSkin and Cython were about neck and neck
once all the optimisations were in place, but Cython required a chunk
of work (as before). PyPy is faster than before but still an order of
magnitude slower than the best ShedSkin. I'll report figures when I'm
happy with my code (today was just flexing it to check everything was
install ok).
The ShedSkin-with-complex numbers Mandelbrot was slightly slower than
without-complex-numbers but they're mostly 'the same', unlike when I
taught last year. Nice job.
Ian.
On Tue, Feb 7, 2012 at 3:09 AM, Ian Ozsvald <i...@ianozsvald.com> wrote:
> Darn, oh well, no distractions in the tutorial I guess :-) I showed my
> business partner today (with/without ShedSkin) - he was most
> impressed. This nicely explains the obvious benefit of ShedSkin over
> Cython - no need to annotate a large codebase to get a great speedup.
there are some other nice visual examples. pylot_main.py and
circle_main.py come to mind. one uses multiprocessing and the other
pygame.
> Do you have a gut feel whether the emulator might run in PyPy (i.e.
> can the GUI component be easily removed)? I'm not thinking of doing it
> now but I'm sure someone will ask.
I have no idea, but I actually thought it was one of the main selling
points of pypy that it works for arbitrary code..?
thanks!
mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk
That is the main selling point, and for many people, PyPy will run all
their pure-Python (2.7.1) code with no modification whatsoever. (I
actually fall into this category.) However, there are still some
corner cases where PyPy doesn't behave exactly like CPython. So I
wouldn't say PyPy runs arbitrary Python code, but I do think it's
very, very close.
The more common source of incompatibility when using PyPy is when
there is a dependency on C-implemented modules. This even includes
some of the standard library. In some cases, you only have to
recompile for PyPy instead of CPython and it will work. But in other
cases, you really have to make some significant changes to interface
the C code with PyPy.
John
Raphael
Am I right in saying that ShedSkin's job is to check all the possible
variants of input types to a function (e.g. it could take some int
args, or float args, or double float args) and then it produces
specialised versions of the function that match each possible input
argument combination?
The AST's job then is to build a list of all the combinations (for
each function that calls a function that calls a...etc) of all the
types.
Is that about right?
> Am I right in saying that ShedSkin's job is to check all the possible
> variants of input types to a function (e.g. it could take some int
> args, or float args, or double float args) and then it produces
> specialised versions of the function that match each possible input
> argument combination?
this is true for the type inference part, but not anymore for
generated code. it used to be that shedskin would try to generate C++
(class, function) templates for generic code. but because this
complicated code generation quite a bit, was practically unused in
shedskin/examples, and can often be easily worked around in any case,
I decided to take it out in the end..
fortunately the python builtins and support libs are often sufficient
to build a generic datastructure/algorithm.
In the compiled result are you calling into the Python libs, using the
Python Int objects and the Python's Int multiplication? I had figured
you compiled all the way down to C's int types and operations, so I'd
figured you'd have specialised interfaces on each function for the
various combinations of input types.
Can you give me an outline of what's actually called in the above
example, either in Python or in pure C?
Ian.
I'm sure you know this better than I, but you can look at the .cpp
file created. In the case above, it creates the single function:
double sq(double a) {
return (a*a);
}
and it defines the types double and ss_int for your 2 return values.