Skip to content
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

Generate multiple functions with one instance of CodeGenerator #5

Closed
torshie opened this issue Dec 12, 2012 · 5 comments
Closed

Generate multiple functions with one instance of CodeGenerator #5

torshie opened this issue Dec 12, 2012 · 5 comments
Assignees

Comments

@torshie
Copy link

torshie commented Dec 12, 2012

Any chance I would generate more than one functions with just one instance of CodeGenerator ?

I need to generate many functions on the fly, but I found the constructor of CodeGenerator has very significant overhead, and is unsuitable to be called repeated.

@ghost ghost assigned herumi Jan 6, 2013
@herumi
Copy link
Owner

herumi commented Jan 6, 2013

I'm sorry for slow response, I nothiced this issue today.

At first, assign large maxSize to the constructor of CodeGenerator.
I write the following code to avoid many instance of CodeGenerator.
Does this way solve your problem?

void *func1;
void *func2;
void *func3;
...

CodeGenerator()
{
#if 1
    func1 = getCurr();
    genFunc1();

    align(16);
    func2 = getCurr();
    genFunc2();

    align(16);
    func3 = getCurr();
    genFunc3();
#else
    // when using AutoGrow
    const size_t func1Offset = getSize(); // always 0
    genFunc1();

    align(16);
    genFunc2();
    const size_t func2Offset = getSize();

    align(16);
    genFunc3();
    const size_t func3Offset = getSize();
    ...
    func1 = getCode() + func1Offset;
    func2 = getCode() + func2Offset;
    func3 = getCode() + func3Offset;
#endif
}

@torshie
Copy link
Author

torshie commented Jan 7, 2013

I avoided creating instances of CodeGenerator on the fly, just create some during program initialization, long initialization time isn't a problem in my case. The solution above might help, but not exactly what I want. Here is my problem:
I'm implementing something like a mini-SQL interpreter. Instead of interpreting everything, I want to use a JIT compiler/assembler to compile some SQL queries into machine code. So I need to generate and destroy unlimited number of functions. A light-weight JIT compiler/assembler is very important to my program.
If the solution above is used, I probably would generate and destroy functions in batches, for example, after generating 1k functions, destroy them all, then create another CodeGenerator instance. But cache problems might come into my way (just my guess, not sure): data cache miss, stale instruction cache etc.
Currently most queries are interpreted by my program, only very little functionality is implemented in JIT.

@herumi
Copy link
Owner

herumi commented Jan 7, 2013

Though I can't guess the cost of penalty of instruction cache miss, I try to add reset() method to CodeGenerator to reuse the instance at develop branch.
458a6e0
If this runs well, then I'll merge it into master branch.

@torshie
Copy link
Author

torshie commented Jan 8, 2013

It's not just about performance.

On ARM CPUs, self-modifying applications have to invalidate instruction cache deliberately. I'm not sure about Intel/AMD CPUs. When multi-core systems, multi-threaded applications, old CPU architectures and all other things come together, things may get nasty.

@herumi
Copy link
Owner

herumi commented Jan 8, 2013

Of couse, it is bad to modify the region of code where CPU is running.
But Intel Processor supports Self-modifying code, so I think the problem is only about performance. I think we can get benefit if the generated functions are called many many times.

Intel optimization manual 3.6.9.1 Self-modifying code.

Self-modifying code (SMC) that ran correctly on Pentium III processors and prior
implementations will run correctly on subsequent implementations.

@herumi herumi closed this as completed Mar 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants