Hi again,
for more details, look at 77dce024e344. It takes the original
approach of not touching operations using opaque pointers at all into
one that allows getfield_gc(p,...) with p opaque in the short_preamble
in some specific cases.
On Tue, Oct 14, 2014 at 9:55 AM, Hakan Ardo wrote:
> On Tue
On 14 October 2014 18:46, Armin Rigo wrote:
> The alternative would be to have a "vector_3f_add()" that takes 4 xmm
> registers, combine them into two, add them, and re-split the result.
...or, as Maciej says, have only the ability to operate on memory
data. But even ignoring the alignment mess,
Hi Alex,
On 14 October 2014 18:42, Alex Gaynor wrote:
> I'm talking about an explicit "vector_3f_add()" primitive, would be pretty
> straightforward to do the mapping. IIRC it took us less than a day to add
> READ_TIMESTAMP instruction.
I agree with Maciej on this point. The problem with "vecto
I think that part can be resurrected from some branch, I added it at
some point. The problem is that you need aligned data access and the
responsibility is on the user of this primitive
On Tue, Oct 14, 2014 at 6:42 PM, Alex Gaynor wrote:
> I'm talking about an explicit "vector_3f_add()" primitive
I'm talking about an explicit "vector_3f_add()" primitive, would be pretty
straightforward to do the mapping. IIRC it took us less than a day to add
READ_TIMESTAMP instruction.
Alex
On Tue, Oct 14, 2014 at 9:41 AM, Maciej Fijalkowski
wrote:
> i would say a bit more than that :-)
>
> On Tue, Oct
i would say a bit more than that :-)
On Tue, Oct 14, 2014 at 4:15 PM, Alex Gaynor wrote:
> There aren't any primitives for this right now, no. I'd say it would be
> medium level of difficult to add support to the JIT for this, probably a day
> of work for someone who knew the codebase, a few days
There aren't any primitives for this right now, no. I'd say it would be
medium level of difficult to add support to the JIT for this, probably a
day of work for someone who knew the codebase, a few days for someone
learning it.
On Tue, Oct 14, 2014 at 7:05 AM, Timothy Baldridge
wrote:
> I've rea
I've read a few older articles about SIMD support in PyPy, what is the
status of this? If I wanted to add something like a Vector3 type to my
language (like mono did here
http://tirania.org/blog/archive/2008/Nov-03.html) and wanted to take
advantage of SSE are there primitives for this?
Thanks,
T
On Tue, Oct 14, 2014 at 9:26 AM, Armin Rigo wrote:
>
> I'm not sure: the logic in optimizeopt/heap.py seems to be "if it's an
> opaque pointer, and if we don't know its class, then don't move it".
> According to this logic, operations on RPython instances (like
> GUARD_CLASS) can still be moved to
Hi Hakan,
On 13 October 2014 18:59, Hakan Ardo wrote:
> Are we certain opaque pointers always refer to GC-objects?
Yes.
> Right, but mark_opaque_ptr prevents this case as well by not moving
> operations using opaque pointers into the short preamble. So I guess
> we are currently fine?
I'm not
10 matches
Mail list logo
