Either I reply to your post or to Re: Use perl type without perl.
The latter would have made more sense I think.
But, reading the OP, nowhere is it indicated that he want to use the perl interpreter at all. Indeed, this " I mean don't invoke perl interpreter or struct." could be construed as saying he doesn't want to.
I took the OP to mean that he would like to use some of the perl data types in a completely non-Perl piece of code. Just (say) as a convenient source of an efficient hash implementation. And to that end, it ought to possible to use them without perl contexts coming into it at all.
The fact that it isn't possible is symptomatic of one (of many) of the anachronisms in the way the perl sources are laid out.
(Guessing) 80% or more of perl internal functions that receive and pass-through a perl context handle, make no use of it.
And (again guessing) other than to pass it on to perl internal functions they call, 90%+ of user XS functions make no use of the context handle they get passed.
Only those function that need the perl context should ever need be aware of it. They can retrieve it from TLS on-demand.
But apparently, TLS is so inefficiently implemented under pthreads, it is cheaper to tie up a register in every function, than to have the the 10% than need access to fetch it on demand.
I was completely baffled by your reference to GObject at first, but now I'm guessing that you are suggesting that if the OP wants a ready source of a hash implementation, GLib comes with one he might find more convenient than perl's? That could be more clearly stated.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply] |
Passing my_perl on the stack/register is alot faster than the GLR and SLR and TlsGetValue calls. If it was worth it, any C compiler would put my_perl back on the C stack if it wasn't being used for a long stretch of code but since every time PL_* written, plus more PL_*s hidden in various object-like macros, is a dereferencing of my_perl. Its basically impossible.
And (again guessing) other than to pass it on to perl internal functions they call, 90%+ of user XS functions make no use of the context handle they get passed.
Nope. Every XS function starts with this, but most of these values except for sp and ax are tossed very soon by the C compile because of liveness analysis. ix is added by ParseXS only for ALIAS: xsubs.
SV **sp = (my_perl->Istack_sp);
I32 ax = (*(my_perl->Imarkstack_ptr)--);
register SV **mark = (my_perl->Istack_base) + ax++;
I32 items = (I32) (sp - mark);
I32 ix = ((XPVCV *) ((void *) ((cv)->sv_any)))->xcv_start_u.xcv_xs
+ubany.any_i32;
I took the OP to mean that he would like to use some of the perl data types in a completely non-Perl piece of code. Just as a convenient source of am efficient hash implementation. And to that end, it ought to possible to use them without perl contexts coming into it at all.
The fact that it isn't possible is symptomatic of one (of many) of the anachronisms in the way the perl sources are laid out.
How would you handle DESTROYers, cache invalidators, fixed bucket mem allocators and shared string table/shared HEKs (and maybe things that i dont know of) all which could be called when get/set/rmv a hash slice. It sounds like the OP wants to separate C parts out of Perl and use them without an interp. The other monks made responses that I read as "thats perfect, 1 catch, no threads", when that is not true. Unless I'm wrong about the implementation of a no threads perl, where upon loading the DLL, from DllMain the interp will always initialize itself and perlembed stuff isn't necessary then. From what I read a while ago, in a no threads perl, the perl interp struct (my_perl) is allocated in .data/RW global data section in the DLL. Through the export table you get my_perl everywhere in your code since its an extern C global.
I was completely baffled by your reference to GObject at first, but now I'm guessing that you are suggesting that if the OP wants a ready source of a hash implementation, GLib comes with one he might find more convenient than perl's? That could be more clearly stated.
GObject and Perl's GC systems have many similarities. Someone might say "I use Glib only for reference counting/other things Perl provides, that sucks, GLib is fat, let me try the faster/better/super/less bloated Perl GC system without Perl in my pure C app". I am saying that would be a bad choice. Glib and Perl both have their places. They are not interchangeable. I could have written that and replace the word GObject with COM and compared COM to Perl. Perl is not a standard library for pure C apps. It is not NSPR or GLib. | [reply]
[d/l] |
Passing my_perl on the stack/register is alot faster than the GLR and SLR and TlsGetValue calls.
Ignoring that I don't know what "GLR and SLR" are -- and you do not bother to explain them -- I'd be interested to see proof of that "much faster". Faster I have no doubts, but much faster?
See "TlsGetValue was implemented with speed as the primary goal."
And I counter that assertion with: speed isn't everything.
Burdening every function, and every programmer, with the need to accommodate a 'pass-through variable' and relying upon the optimiser to make it disappear when not required -- all to save what effectively becomes something like mov rax, GS:[8*rcx+0x2c] -- is short-sighted in the extreme.
And wrapping it over in a bunch of "trick" macros make the programmer burden -- via cognitive disconnection -- even worse.
I took the OP to mean...
How would you handle ...
I wouldn't. Just because I took the OP to mean that; doesn't mean that I think that it is a good idea, or even possible.
I only attempted to answer -- at perhaps a superficial level -- the OPs question: "I'm curious why non-threaded perl can do what thread perl can't do.". Naught more.
Which is why I think your post would have been better directed at the alternative you suggested.
GObject and Perl's GC systems have many similarities. ... I am saying that would be a bad choice.
Then why mention it? No one else did.
Aren't you just as guilty of misdirection by bringing it up and leaving it hanging as the guy that suggested: "you'll be fine so long as you don't use threads"? Which seems to be the focus of your posts.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply]
[d/l] |
