Questions about wrapper partial function

[ShanZeHu]

Dear developer, Hello, I am a software engineering student named Mixky now very interested in your open source project and is engaged in this part of wrapper related research, is currently exploring the impact of wrapper on the overall performance of box64, I wrote a few common test library functions from X86 to ARM architecture, I want to wrapper in I want to test the program runtime with the wrapper function enabled or disabled respectively, because the translation function needs to be enabled without the wrapper native library. I have encountered some errors in the process, so I would like to ask you if this part of the wrapper function is provided with parameters that can be turned off or enabled separately, or how I can go about solving this problemo(╥﹏╥)o

[ShanZeHu]

[ptitSeb]

Some libs cannot be "unwrapped" for now. Mainly "libc" and "pthread", they have to be used wrapped because some of the system function that they used internaly if emulated are not supported (the FS/GS tls segment handling).
So, a program that is staticaly linked with libc might not work because of that.

You want to compare performances with and without wrapping the libs right?

(and thank you for your interest in box64 project :) )

[ShanZeHu]

Yes, I was trying to compare the performance of the wrapper with and without the wrapper. I am currently making it possible to run only using the mock library by commenting all GO functions in src/library_list.h, and this is generating some errors. I'm not sure if I'm doing it right, so I'd like to ask you for your comparative work on the performance of the wrapper. My current research direction is to output a paper on optimizing the wrapper for the Box64 project, and I'd also like to ask you what clear directions I can take for optimization or how to go about it.
and thank you for your help :)

[ptitSeb]

You can simply use BOX64_EMULATED_LIBS=XXX;YYY to use emulated libs for XXX and YYY for example, it will be simpler.
But again, emulating libc and libm will not work.
Now, commenting the GO(XXX) in library_list.h will work, but you have to be sure that the x86_64 lib are available to box64. Also starting with glibc 2.35 (iirc), all libc, pthread, libm... are now fused in libc. So it might be usefull to use older version of glibc for this test.

[ShanZeHu]

Okay, I'll go ahead and try to follow this approach, I still have a lot of things I don't understand clearly enough, I'll try to familiarize myself with the whole project first, thanks for your help and answers

[ShanZeHu]

Dear ptiseb, after your guidance I was able to solve my problem, by debugging my test program I found that the IncRefCount function in the /librarian/library.c file was the key to the problem, then today I checked the original posting and found that it had been updated here, I synchronized it and found that my test program worked, the conclusion was that some small libraries such as libz, libpng with or without wrapper boost, the performance is about 7~10 times difference, thank you very much for your guidance and suggestions!

[ptitSeb]

It makes sense. libz or libpng will have tight loop of cpu intensive code to encode/decode, and sometime using hand optimized assembly code. This is were the wrapping will be the more efficiant!

[ShanZeHu]

Can you give me some advice on this :)

[ptitSeb]

advice on what "this?

[ShanZeHu]

This refers to: for those library functions that use wrapper and have performance degradation due to jmp_buf processing (e.g. libjpeg, freetype, etc. that we mentioned before), I wonder if it is possible to optimize them for this part of jmpbuf processing, so as to solve this efficiency degradation

[ShanZeHu]

Is it possible to solve the problem that the use of wrapper leads to less efficient operation of certain library functions? If this problem is solvable, I would like to solve it, and then I would like to ask you to give me some possible directions to explore

[ShanZeHu]

Sorry, my previous statement may not have been clear :(

[ptitSeb]

Oh that. Well, I'm not sure. Wrapped should be more efficient in most cases. I'm not sure the constant wrapping/unwrapping of the structure really kills the performances, but I haven't mesured.
For correct image, the jmpbuf should not be use, so you can hack the source to remove the jmpbuf stuff and see if it's faster like that. Creating a jmpbuf should be quite fast, but the "sig" part of it might make it slower. Also, it's recreated every call iirc, so that also could be optimised (if the jmpbuf is the culprit)

[ShanZeHu]

I am most grateful for your detailed and insightful responses to my queries. They have significantly enhanced my understanding of wrapper function optimisation and the handling of the jmpbuf structure. I will certainly heed your suggestions for further experimentation and performance tuning in my project.

Once again, thank you for your generous assistance and for sharing your expertise！

[ShanZeHu]

Dear ptiseb，I have encountered a problem that I'm having trouble solving by myself and I was hoping you could assist me. I noticed that within the 'wrapped' directory, there are multiple library files of the same name but with different suffixes. In the **_private.h files, I found numerous GO function definitions, while the corresponding **.c files only seem to implement the wrapping of functions defined in GOM. If I wanted to add my own function wrappings, what criteria should I use to decide between using GO or GOM? Are there specific types of functions that need to be wrapped with GOM perhaps due to dynamically generated data that needs to be processed during runtime?

[ptitSeb]

No, the difference between GO and GOW is just the type of symbol. Use nm -D or something like that on the lib to see if the symbol is Weak or not.

[ShanZeHu]

Thank you for your clarification! This distinction between GO and GOW makes more sense to me now.

[ShanZeHu]

Previously, I've learned to utilize the nm -D command in order to distinguish between the use of GO and GOW. Currently, my understanding is that GOM should be applied for those functions involving callbacks and more complex arguments, with these functions typically prefixed by 'my_'. However, I'm uncertain about how to make this determination accurately for a given function. Should I refer to the original function definition to decide whether to use GOM or GO? Or is there a strategy to quickly judge if GO isn't functioning properly and hence needs to be switched to GOM? I'd appreciate any guidance on this.

[ptitSeb]

You need to use the original function definition for that, there is no other way.

[ShanZeHu]

Okay, I understand, thanks