Hi,
On Thu, Aug 30, 2012 at 10:28 AM, Armin Rigo wrote:
> This is a blocker, and one that the plan towards CFFI should
> completely fix.
A quick but successful attempt can be found in cffi/demo/{api,pyobj}.py.
api.py is a bit of a hack but lets you declare functions with the
decorator @ffi.pyex
Hi Stefan,
On Thu, Aug 30, 2012 at 10:06 AM, Stefan Behnel wrote:
> This may not even be that hard to do, but it's unlikely that I'll give this
> a try myself. The turn-over times of building PyPy for an hour or so on a
> remote machine (RAM!) for most non-trivial changes are just way too long to
Hi Armin,
Armin Rigo, 30.08.2012 09:10:
> On Wed, Aug 29, 2012 at 10:29 PM, Stefan Behnel wrote:
>>> Ok, so where would this have to be done? Is there a way to implement it
>>> generically in that ubiquitous space.wrap() kind of call (whatever that
>>> does internally), or would it have to be done
Hi Stefan,
On Wed, Aug 29, 2012 at 10:29 PM, Stefan Behnel wrote:
>> Ok, so where would this have to be done? Is there a way to implement it
>> generically in that ubiquitous space.wrap() kind of call (whatever that
>> does internally), or would it have to be done explicitly whenever objects
>> p
Stefan Behnel, 23.08.2012 11:16:
> Stefan Behnel, 03.07.2012 19:56:
>> Amaury Forgeot d'Arc, 03.07.2012 18:26:
>>> Maybe we should use a weak dictionary to cache the PyObject structure.
>>> This already exists for objects defined and created from C...
>>
>> That would be really helpful. In particul
Maciej Fijalkowski, 23.08.2012 11:17:
> On Thu, Aug 23, 2012 at 11:11 AM, Stefan Behnel wrote:
>> Maciej Fijalkowski, 05.07.2012 14:50:
>>> On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote:
Maciej Fijalkowski, 05.07.2012 11:01:
> On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wr
Stefan Behnel, 03.07.2012 19:56:
> Amaury Forgeot d'Arc, 03.07.2012 18:26:
>> Maybe we should use a weak dictionary to cache the PyObject structure.
>> This already exists for objects defined and created from C...
>
> That would be really helpful. In particular, it would solve one of the most
> an
On Thu, Aug 23, 2012 at 11:11 AM, Stefan Behnel wrote:
> Maciej Fijalkowski, 05.07.2012 14:50:
>> On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote:
>>> Maciej Fijalkowski, 05.07.2012 11:01:
On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
> 2012/7/5 Stefan Behnel
>> Bac
Maciej Fijalkowski, 05.07.2012 14:50:
> On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote:
>> Maciej Fijalkowski, 05.07.2012 11:01:
>>> On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
2012/7/5 Stefan Behnel
> Back to that question then:
>
>> Is there a way to get rea
2012/7/10 :
> Sounds like something I could do today, but still feels like a square peg /
> round hole kind of solution, since the code to trigger that C stub
> generation would (in cppyy's case) start in RPython to begin with.
> Makes me wish I could generate RPython (after translation, that is).
Hi Stefan,
The question is if a conversion from low-level types to Python types can be
seen and handled by the JIT, but I'd be surprised if it couldn't, since it
generates this kind of code itself anyway.
this is beyond my expertise, but one way of making the wrapping visible, is
to generate t
Hi Amaury,
I don't think it's a good idea to use pointers with a moving GC.
then make it (the moral equivalent of) a PyPyObject**. Like in Smalltalk.
Best regards,
Wim
--
wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net
__
2012/7/10 :
> I'm trying to resist the urge to say that it should be the Python C-API,
> with all PyObject*'s replaced by PyPyObject*'s. :)
I don't think it's a good idea to use pointers with a moving GC.
But I may be wrong. In any case, we need a memory model compatible with C.
--
Amaury Forge
wlavrij...@lbl.gov, 10.07.2012 21:02:
>> Ok, then in the case of a callback, the runtime could simply start with
>> totally stupid code that packs the low-level arguments into Python
>> arguments, attaches the low-level type information to them and then passes
>> them into the function. The JIT sho
Hi Amaury,
On Tue, 10 Jul 2012, Amaury Forgeot d'Arc wrote:
2012/7/10 :
Generating such a C function by the backend then requires a C-API for the
calls to do the wrapping. That PyPy C-API is a long awaited project. :)
Do you have an idea what this API would look like?
Then I can help with the
Hi Stefan,
Ok, then in the case of a callback, the runtime could simply start with
totally stupid code that packs the low-level arguments into Python
arguments, attaches the low-level type information to them and then passes
them into the function. The JIT should then see in its trace what types
wlavrij...@lbl.gov, 10.07.2012 20:37:
> On Tue, 10 Jul 2012, Stefan Behnel wrote:
>> wlavrij...@lbl.gov, 10.07.2012 20:10:
>>> that completely depends on how it is generated, of course, and in the
>>> context
>>> of calls within Python (pypy-c), it makes sense to have the entry point of
>>> the fun
Hi Stefan,
On Tue, 10 Jul 2012, Stefan Behnel wrote:
wlavrij...@lbl.gov, 10.07.2012 20:10:
that completely depends on how it is generated, of course, and in the context
of calls within Python (pypy-c), it makes sense to have the entry point of
the function expect wrapped arguments, and have the
wlavrij...@lbl.gov, 10.07.2012 20:10:
>> There's no reason it would require wrapped arguments.
>
> that completely depends on how it is generated, of course, and in the context
> of calls within Python (pypy-c), it makes sense to have the entry point of
> the function expect wrapped arguments, and
Hi Stefan,
There's no reason it would require wrapped arguments.
that completely depends on how it is generated, of course, and in the context
of calls within Python (pypy-c), it makes sense to have the entry point of
the function expect wrapped arguments, and have the exit point re-wrap.
Th
wlavrij...@lbl.gov, 10.07.2012 19:38:
> On Tue, 10 Jul 2012, Maciej Fijalkowski wrote:
>> Amaury - not true, we can JIT functions from the start. However, they would
>> still accept wrapped arguments. I can think about a simple way to enable
>> jitting from the start without the need though.
>
> i
2012/7/10 :
> Generating such a C function by the backend then requires a C-API for the
> calls
> to do the wrapping. That PyPy C-API is a long awaited project. :)
Do you have an idea what this API would look like?
Then I can help with the implementation :)
--
Amaury Forgeot d'Arc
_
Hi all,
On Tue, 10 Jul 2012, Maciej Fijalkowski wrote:
Amaury - not true, we can JIT functions from the start. However, they would
still accept wrapped arguments. I can think about a simple way to enable
jitting from the start without the need though.
if the JITted function still requires wrap
On Tue, Jul 10, 2012 at 12:45 PM, Amaury Forgeot d'Arc
wrote:
> 2012/7/10 Eleytherios Stamatogiannakis :
> > On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
> >>
> >> provide a prioritized list of what's still missing for you? I'm
> following
> >> a
> >> more or less random walk otherwise, with most
On 10/07/12 13:45, Amaury Forgeot d'Arc wrote:
A callback called from C cannot be jitted, unless it has a loop in Python code.
The loop in the sqlite library does not count. The JIT needs a
complete understanding of all operations in the loop...
-- Amaury Forgeot d'Arc
From what i understand y
2012/7/10 Eleytherios Stamatogiannakis :
> On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
>>
>> provide a prioritized list of what's still missing for you? I'm following
>> a
>> more or less random walk otherwise, with most work going into the CINT
>> backend
>> at the moment.
>
>
> Do jitted callbac
On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
provide a prioritized list of what's still missing for you? I'm following a
more or less random walk otherwise, with most work going into the CINT
backend
at the moment.
Do jitted callbacks work?
My main use case has to do with sqlite UDFs written i
Hi Maciej,
it's in the process. look on ffi-backend branch
looking good!
Any chance of getting a W_CTypeFunc.call() taking args instead of args_w? I'd
like to pull in the function pointer from app-level, so that loading in the
.so's is deferred to run-time, but then do the call from interpret
On Tue, Jul 10, 2012 at 12:17 AM, wrote:
> Hi Maciej,
>
> Or CFFI
>>
>
> did I miss an announcement and has it been added to PyPy? I can't find it
> ...
>
> Thanks,
>
> Wim
>
it's in the process. look on ffi-backend branch
> --
> wlavrij...@lbl.gov--+1 (510) 486 6411--ww
Hi Maciej,
Or CFFI
did I miss an announcement and has it been added to PyPy? I can't find it ...
Thanks,
Wim
--
wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.p
On Tue, Jul 10, 2012 at 12:04 AM, wrote:
> Hi Alex,
>
>
> cppyy is still so unfinished
>>
>
> provide a prioritized list of what's still missing for you? I'm following a
> more or less random walk otherwise, with most work going into the CINT
> backend
> at the moment.
>
>
> and requires rebuil
Hi Alex,
cppyy is still so unfinished
provide a prioritized list of what's still missing for you? I'm following a
more or less random walk otherwise, with most work going into the CINT backend
at the moment.
and requires rebuild of pypy with root libraries and all the other tedious
things, t
Alex Pyattaev, 09.07.2012 20:53:
> And now for something completely different:
> Would not it make dramatically more sense to just finish the cppyy branch and
> get a working extension-making scheme that actually works? I have a project
> now that uses C++ extensions and python quite extensively,
And now for something completely different:
Would not it make dramatically more sense to just finish the cppyy branch and
get a working extension-making scheme that actually works? I have a project
now that uses C++ extensions and python quite extensively, and the only thing
stopping me from mig
Thanks!
i might think bad about those benchmarks representing python workloads,
howecer they are very likely good for cpyext. good job.
On Thursday, July 5, 2012, Stefan Behnel wrote:
> Stefan Behnel, 05.07.2012 14:35:
>> http://cython.org/callgrind-pypy-nbody.png
>
> I've set up a job on our bu
Stefan Behnel, 05.07.2012 14:35:
> http://cython.org/callgrind-pypy-nbody.png
I've set up a job on our build server to run a couple of (simple)
benchmarks comparing Cython's current performance under CPython and PyPy.
Note that these are C-API intensive benchmarks by design (they are compiled
from
On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote:
> Maciej Fijalkowski, 05.07.2012 11:01:
> > On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
> >> 2012/7/5 Stefan Behnel
> >>> Back to that question then:
> >>>
> Is there a way to get readable debugging symbols in a translated
On Thu, Jul 5, 2012 at 2:35 PM, Stefan Behnel wrote:
> Maciej Fijalkowski, 05.07.2012 11:01:
> > On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
> >> 2012/7/5 Stefan Behnel
> >>> Back to that question then:
> >>>
> Is there a way to get readable debugging symbols in a translated
Maciej Fijalkowski, 05.07.2012 11:01:
> On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
>> 2012/7/5 Stefan Behnel
>>> Back to that question then:
>>>
Is there a way to get readable debugging symbols in a translated PyPy
that would tell me what is being executed?
>>
>> I fear
On Thu, Jul 5, 2012 at 10:26 AM, Amaury Forgeot d'Arc wrote:
>
> 2012/7/5 Stefan Behnel
>
>> Back to that question then:
>>
>> > Is there a way to get readable debugging symbols in a translated PyPy
>> that
>> > would tell me what is being executed?
>>
>
> I fear that pypy standard distribution c
2012/7/5 Stefan Behnel
> Back to that question then:
>
> > Is there a way to get readable debugging symbols in a translated PyPy
> that
> > would tell me what is being executed?
>
I fear that pypy standard distribution calls "strip" on the resulting
binary.
You could translate pypy yourself, I'm
Stefan Behnel, 03.07.2012 19:56:
> Amaury Forgeot d'Arc, 03.07.2012 18:26:
>> Then this should work:
>>pypy/bin/py.py --withmod-cpyext -c "import nbody"
>>
>> *very* slowly of course, but I was able to debug pygames this way!
>
> The problem is not so much that it's generally slow but that the
2012/7/4 Stefan Behnel :
> However, it now prints a trace of every C-API function that it calls, e.g.
>
> """
> DONE
> DONE
> DONE
> DONE
> DONE
> DONE
>
> 0x43464f8> DONE
> DONE
> DONE
> DONE
> """
>
> Is there a way to disable that? That level of verbosity could be a bit costl
Stefan Behnel, 03.07.2012 19:56:
> Amaury Forgeot d'Arc, 03.07.2012 18:26:
>> Then this should work:
>>pypy/bin/py.py --withmod-cpyext -c "import nbody"
>>
>> *very* slowly of course, but I was able to debug pygames this way!
>
> The problem is not so much that it's generally slow but that the
Maciej Fijalkowski, 04.07.2012 10:48:
> On Wed, Jul 4, 2012 at 8:27 AM, Stefan Behnel wrote:
>
>> Amaury Forgeot d'Arc, 03.07.2012 18:26:
>>> No optimization of any kind have been done in cpyext (it's difficult
>>> enough to get it right...)
>>> A freelist would be a nice thing, but there would st
On Wed, Jul 4, 2012 at 8:27 AM, Stefan Behnel wrote:
> Amaury Forgeot d'Arc, 03.07.2012 18:26:
> > No optimization of any kind have been done in cpyext (it's difficult
> enough
> > to get it right...)
> > A freelist would be a nice thing, but there would still be the cost of
> > attaching the PyO
Amaury Forgeot d'Arc, 03.07.2012 18:26:
> No optimization of any kind have been done in cpyext (it's difficult enough
> to get it right...)
> A freelist would be a nice thing, but there would still be the cost of
> attaching the PyObject to the pypy w_object.
>
> Maybe we should use a weak diction
Amaury Forgeot d'Arc, 03.07.2012 18:26:
> 2012/7/3 Stefan Behnel
>> BTW, are PyObject structures currently cached in a free-list somewhere?
>> That would be really helpful for the iteration performance.
>
> No optimization of any kind have been done in cpyext (it's difficult enough
> to get it rig
2012/7/3 Stefan Behnel
> > Don't forget that cpyext reference counts are quite different from
> CPython:
> > PySequence_GetItem() needs to *create* a PyObject structure, and the
> > returned object has a refcount of 1.
> > Then Py_DECREF() will really *deallocate* the PyObject structure...
>
> Su
Amaury Forgeot d'Arc, 03.07.2012 14:55:
> 2012/7/3 Stefan Behnel
>> I've been working with one of the modules in the Python benchmark suite,
>> namely nbody, and tried to make it run a little faster when compiled with
>> Cython in PyPy. I managed to get a massive speed-up by avoiding some
>> borrow
Hi,
2012/7/3 Stefan Behnel
> I've been working with one of the modules in the Python benchmark suite,
> namely nbody, and tried to make it run a little faster when compiled with
> Cython in PyPy. I managed to get a massive speed-up by avoiding some
> borrowed references during list iteration and
51 matches
Mail list logo
