New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT decoder(empty|takebytes) #926
JIT decoder(empty|takebytes) #926
Conversation
not sure if the impact can be this big, but i'd assume that ensure_decoder would be inlined in the non-jit version, and is a "full" call in this one. |
@timo huh, might that be the same for the other decoder* ops also? They could actually be faster non-jitted? Is there a way to fix that? |
either make a c function that's only meant to be called by the jit that has the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make the cast from char* to integer via uintptr_t
src/jit/graph.c
Outdated
MVMint16 inc = ins->operands[3].reg.orig; | ||
MVMJitCallArg argc[] = { { MVM_JIT_INTERP_VAR, { MVM_JIT_INTERP_TC } }, | ||
{ MVM_JIT_REG_VAL, { decoder } }, | ||
{ MVM_JIT_LITERAL_PTR, { (MVMint64)"decodertakebytes" } } }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pls make this uintptr_t, we have enough unportable stuff going on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copied this from the other decoder*
cases. Should I change them all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please 😄
NQP builds ok and passes
make m-test
and Rakudo builds ok and passesmake m-test m-spectest
.This gets rid of some BAILs I saw when using Compress::Zlib. However, it seemed to actually make it slightly slower (roughly from 6.4s before to 6.6s after when
gzslurp
ing a 975k file). @bdw any idea why?