Avisynth 2.6 MT

[asarian]

Originally Posted by jpsdr

Some 64bits pluggins can have sometime speed increase of 30%.
I've noticed, on QTMG for example, an increase speed of around 15% under 64bits.

My personnal thought, at the actual stage is :
The way MT is implemented on avisynth seems not to be very stable, so, the best way actualy to have a stable multithreading would be to not use MT version of avisynth, split your work and start several task. For exemple, launching 6 Vdub task on 6 files.
Using not MT version of avisynth keep garanty stability, and running several tasks make all your core work.
I think, it could be more interesting to focus on single threading 64bits port, because good 64bits port can provide good improvement in speed.
I've noticed it with the unfornutaly dead project of the 64 bits version begun by JoshyD.

Perhaps in abundance, but I'd like to reiterate that the advantage of the often hailed speed-improvements of a 64-bit build pales in comparison to the gained memory. Especially for HD material, memory is a constant limiting factor. For instance, when using MCTemporalDenoise, I can't even run 32-bit Avisynth, unless I use a process separation trick to pipe output to x264, using avs2yuv. And even then there are times I have to split up a movie (vertically), in two parts, in order to bypass memory issues. So a good 64-bit version of AviSynth 2.6 would be very welcome.

[IanB]

Originally Posted by SEt

IanB, ... Found the actual crash reason: I was playing with default calling convention and missed unspecified one on dynamically generated code call. I think conventions should be explicitly written where they are important.

Please explain more, I don't understand where you could break this.

[SEt]

In DynamicAssembledCode::Call

return ((int (*)(const void* *))entry)(&arg1);

should be

return ((int (__cdecl*)(const void* *))entry)(&arg1);

There are plenty of other places where convention should be specified - try changing default convention to __fastcall and compile. Good thing compiler throws errors there so it's easy to spot the places.

[IanB]

Ah! You were trying to trick me. Nothing to do with any convert\convert_*.cpp's it was in file core\softwire_helpers.cpp, fair enough.

[JEEB]

Couldn't get the current trunk to build, fix. Didn't know MSVC6 compiled stuff like this .

[DarkT]

What has less head-ache involved, using 2.5.8 mt or 2.6? Like, I want to use up my i7-950 as best as I can, with the current x64 filters, which would be a better choice? 2.6? 2.5.8?

[TheFluff]

Originally Posted by DarkT

What has less head-ache involved, using 2.5.8 mt or 2.6? Like, I want to use up my i7-950 as best as I can, with the current x64 filters, which would be a better choice? 2.6? 2.5.8?

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

[DarkT]

Originally Posted by TheFluff

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

Seems like what I wrote wasn't clear enought(perhaps not only for you) - I will restate: Least headache, while using as much of the CPU power as possible.

I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6. Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses? I do not know. I was hoping somebody would help me with making that decision, instead of gruelly trying it out myself.

[Groucho2004]

Originally Posted by TheFluff

32-bit single-threaded 2.5.8 is by far the best choice if the purpose is to avoid headaches.

I have not had any headaches with the current 2.6 Alpha 3.

[Groucho2004]

Originally Posted by DarkT

I will restate: Least headache, while using as much of the CPU power as possible.
I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6.

That's like choosing between a migraine and a serious hangover.

Originally Posted by DarkT

Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses?

Yes.

[TheFluff]

Originally Posted by DarkT

Seems like what I wrote wasn't clear enought(perhaps not only for you) - I will restate: Least headache, while using as much of the CPU power as possible.

I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6. Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses? I do not know. I was hoping somebody would help me with making that decision, instead of gruelly trying it out myself.

Like Groucho2004 says, the best choice is still to use single-threaded 32-bit 2.5.8. If you want more threads, invoke more script environments.

All options other than the vanilla 2.5.8 (including all the 64-bit variants, all the MT variants and all the Avisynth 2.6 variants) are either:
a) way too unreliable,
b) way too limited, or
c) all of the above
to be useful in a production environment.

[DarkT]

64bit is a no go as well?! Blah. It's not a "production environment" either... mmm, I mean, you make it sound "serious" or something *chuckles*

I just want to encode fast... Shit... That's all... Maybe I should run 2-4 64 bits avisynth?

[TheFluff]

Originally Posted by DarkT

64bit is a no go as well?! Blah. It's not a "production environment" either... mmm, I mean, you make it sound "serious" or something *chuckles*

I just want to encode fast... Shit... That's all... Maybe I should run 2-4 64 bits avisynth?

If there existed a completely single-threaded 64-bit version, that'd at least have the potential to be stable enough for actually getting shit done (that's what I mean by "production environment"). Unfortunately, there is no such version, and using 64-bit also severely limits the amount of available plugins.

Just stick with Ye Olde 32-bit 2.5.8. If it was good enough for your grandfather, it should be good enough for you, and if you have to use so many filters that you run out of memory, the source was probably so bad that it wasn't worth encoding anyway.

Remember this, kids: trying to add multithreading to a huge software project that was written without a single thought of thread-safety in mind is madness and a recipe for an eternity of crashing. If said software project also loads and uses many third-party plugins that ALSO were written without a single thought of thread-safety in mind, you might as well kill yourself and end up in Hell already, because that's probably going to be more pleasant than what you're going to end up with.

[DarkT]

Originally Posted by TheFluff

If there existed a completely single-threaded 64-bit version that'd at least have the potential to be stable enough for actually getting shit done (that's what I mean by "production environment"). Unfortunately, there is no such version, and using 64-bit also severely limits the amount of available plugins.

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems. *sighs* I suppose I'll just have to try it out for myself if nobody else has anything helpful to say PRO one of teh choices... *sighs* ah well... Thanks for hte input thus far guys .

[TheFluff]

Originally Posted by DarkT

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems.

And there are also plenty of people complaining about stuff crashing all the time. It's a multithreaded version of a non-threadsafe application, which in plain English means it may work just fine ten times in a row or crash ten times in a row, depending on factors such as the phase of the moon, your hair color, cosmic radiation levels and whether you sacrificed a goat before using the application or not.

edit: it might work if you only use it in single-thread mode, but honestly, avs-mt is just so buggy that you're not likely to notice much of a difference in stability anyway...

[SubJunk]

For me the most stable versions are SET's 2.6 builds. Every version is stable for me without multithreading, but using multithreading I have found 2.6 to crash less than 2.5.8.
It seems to be different for everyone but that's how it is for me

[Groucho2004]

Originally Posted by DarkT

Dunno - I saw plenty people posting nice gains in speeds using MT ver and no stability problems.

I could never get the MT versions to work properly. Some people have no problems at all.
There are a shitload of variables involved - complexity of the script, which filters are used (even the version of the filter can be crucial), in which order the filters are used, number of threads - should I go on?

All you can do is try for yourself.

[SubJunk]

The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.

[DarkT]

Wait, so if you aren't using 2.6 for MT, what are the benefits then of 2.6 over 2.5.8?

[TheFluff]

Originally Posted by SubJunk

The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.

The operative phrase here being "for me". Since the entire thing is basically thread-unsafe, poking at anything that might change the way your OS schedules threads may also change the application's behavior and crashiness/non-crashiness. This is of course entirely impossible to predict and depends on so many factors (including things such as your OS version and your hardware configuration) that it's essentially meaningless to try to replicate.