Avisynth Release profile settings

[sh0dan]

Just wondering, if there is a meaning with the current Optimization settings in the Release Profile. Especially "Flavor fast code" (and not "favor fast code") and the inline ("Only __inline" - not "any suitable") settings seems like they could be improved.

Has anyone done testing on this, or have an opinion on whether it should be commited as default?


Actually, I have secretly had these settings changed for some time without any problems.

[Richard Berg]

"Flavor fast code" (and not "favor fast code")
:confused:

The inlining option is wrong. Probably won't noticeably affect anything since all the intensive stuff is contained in individual GetFrame functions, but still couldn't hurt to change it.

[sh0dan]

Originally posted by Richard Berg
:confused:


I meant "Flavor small code" (and not "favor fast code") ;)

[sh0dan]

OK - inline breaks temporalsoften - it also seems like the 2.03 is broken there. Damn! I could have sworn I turned them off. Seems like we should move to 2.04 - I'll update and upload ASAP. This will include early compressed audio support.

So much for a stable release :(

[Richard Berg]

Well, damn. I suppose there's a reason for everything...in this case, looks like we have to work around the crappy MS compiler. Fear not, once Everett goes public I'll take care of compiling release builds :cool:

[trbarry]

There appear to be complex rules in VS6 about what may be inlined without crashing, as I found out working on DVD2AVI. Unfortunately those rules appear to have elements relating to eye of newt, wing of bat, and the favor of some obscure god named Murphy. They aren't published anywhere.

But some things just can't be inlined without moving them around in the source code or not inlining whatever is calling them, etc.

If anyone understands all this it would be nice as inlining can make a big difference when small procedures are called often.

- Tom

[Richard Berg]

It's compiler bugginess, plain & simple -- the only thing inlining should ever effect is thread safety, which isn't an issue for us. (Don't anyone dare give me crazy ideas about how clip1=filter1 / clip2=filter2 should spin off separate threads!)

[dividee]

Couldn't an application run two or more scripts in different threads?

[Richard Berg]

Yes, but I believe they'd invoke two separate instances of avisynth.dll. Thread safety is an issue when you're talking about have multiple threads sharing the same resource handles / memory addresses / etc. which we thankfully don't do.

[dividee]

Maybe you're right. I don't know much about this stuff.
But what if an application loads avisynth.dll (or link with avisynth.lib) and use avisynth "manually" by using CreateScriptEnvironment. I once thought of writing a tutorial about that, but never did. It allows the application to create a filter graph an request frames from it without going through avifile. Could be useful for an editor.
That application could create multiple ScriptEnvironment in separate threads. Maybe this is a bit far-fetched ?

[Richard Berg]

It should be possible to do. I'm not an expert on this stuff either, but I don't think there'd be much potential for trouble so long as you don't care about keeping them in sync. Usually threading bugs arise from things like calling delete[] on an object another thread is still using, or (if they require synchronization) getting into an infinite loop where thread 1 is waiting for thread 2 to send a semaphore but thread 2 is waiting on thread 1.

[int 21h]

The inline and __inline keywords are hints to try to inline the function, and the optimizer decides whether inlining should be performed based upon optimization switches (optimizing for size versus speed) and other heuristics.

The __forceinline keyword has been added to override the decision of the optimizer, and inline wherever possible. In some cases, the compiler will not inline because of command-line switches or other reasons. For example, the optimizer will not inline in the following cases:

With /Ob0, which is the default for debug builds.
SEH / EH mismatch in a function call (SEH calls EH or EH calls SEH) means the one called cannot be inlined.
Functions with variable argument lists.
Function recursion. This behavior can be changed (subject to the following restriction) with #pragma(inline_recursion, on) to enabling inlining in recursive cases.
Inline depth exceeds the limit. This is done to handle recursion. The default for this value is 8, and can be controlled with #pragma(inline_depth, <n>) where n < 256 and #pragma inline_recursion(on | off).
Some functions with copy constructed object passed by value when -GX/EHs/EHa is on.
Functions returning an unwindable object by value when -GX/EHs/EHa is on.
Functions with inline assembly when compiling without -Og/Ox/O1/O2.
If the compiler cannot inline a function with __forceinline, it will generate a level 1 warning (4714).

It is important to understand the behavior of your code and the trade-offs between code size and code speed when using this keyword and measure the results, because it could result in larger and slower code.

Note The proper functioning of __forceinline cannot necessarily be verified from the map file, because taking the address of a function or exporting a function will result in an instance of the function being generated (though the function will be inlined where called by name).
An expression that takes the address of a function will force an instance of the function in the OBJ. If a function is called through a function pointer, the instance of the function in the OBJ will be called, although the function will be inlined (subject to the other restrictions) when called by name.
This is by design. Inlining is a compile-time operation and calling a function through a function pointer is a run-time operation. In all but the most trivial examples (for instance, when the compiler can optimize the 'address of a function/call through the pointer' back to the function) calling a function through a function pointer will not inline and is not expected to inline.