Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th September 2011, 15:34   #241  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,170
Quote:
Originally Posted by jpsdr View Post
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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 13th September 2011, 22:16   #242  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Quote:
Originally Posted by SEt View Post
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.
IanB is offline   Reply With Quote
Old 13th September 2011, 23:25   #243  |  Link
SEt
Registered User
 
Join Date: Aug 2007
Posts: 374
In DynamicAssembledCode::Call
Quote:
return ((int (*)(const void* *))entry)(&arg1);
should be
Quote:
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.
SEt is offline   Reply With Quote
Old 14th September 2011, 01:26   #244  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
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.
IanB is offline   Reply With Quote
Old 14th September 2011, 16:47   #245  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 510
Couldn't get the current trunk to build, fix. Didn't know MSVC6 compiled stuff like this .
__________________
[I'm human, no debug | Unofficial x264 Builds]
JEEB is online now   Reply With Quote
Old 15th September 2011, 21:53   #246  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
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?
DarkT is offline   Reply With Quote
Old 15th September 2011, 22:18   #247  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 981
Quote:
Originally Posted by DarkT View Post
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.
TheFluff is offline   Reply With Quote
Old 15th September 2011, 22:21   #248  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
Quote:
Originally Posted by TheFluff View Post
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.
DarkT is offline   Reply With Quote
Old 15th September 2011, 22:22   #249  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,611
Quote:
Originally Posted by TheFluff View Post
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 is offline   Reply With Quote
Old 15th September 2011, 22:27   #250  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,611
Quote:
Originally Posted by DarkT View Post
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.

Quote:
Originally Posted by DarkT View Post
Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses?
Yes.
Groucho2004 is offline   Reply With Quote
Old 15th September 2011, 22:30   #251  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 981
Quote:
Originally Posted by DarkT View Post
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.

Last edited by TheFluff; 15th September 2011 at 22:32.
TheFluff is offline   Reply With Quote
Old 15th September 2011, 22:32   #252  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
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?
DarkT is offline   Reply With Quote
Old 15th September 2011, 22:35   #253  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 981
Quote:
Originally Posted by DarkT View Post
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.

Last edited by TheFluff; 15th September 2011 at 22:52.
TheFluff is offline   Reply With Quote
Old 15th September 2011, 22:38   #254  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
Quote:
Originally Posted by TheFluff View Post
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 .
DarkT is offline   Reply With Quote
Old 15th September 2011, 22:43   #255  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 981
Quote:
Originally Posted by DarkT View Post
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...

Last edited by TheFluff; 15th September 2011 at 22:48.
TheFluff is offline   Reply With Quote
Old 15th September 2011, 22:47   #256  |  Link
SubJunk
Registered User
 
Join Date: Jun 2010
Posts: 441
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
SubJunk is offline   Reply With Quote
Old 15th September 2011, 22:47   #257  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,611
Quote:
Originally Posted by DarkT View Post
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.
Groucho2004 is offline   Reply With Quote
Old 15th September 2011, 22:50   #258  |  Link
SubJunk
Registered User
 
Join Date: Jun 2010
Posts: 441
The trick for MT stability for me was SetMemoryMax. Setting that to between 600-800 fixed crashes for me.
SubJunk is offline   Reply With Quote
Old 15th September 2011, 22:53   #259  |  Link
DarkT
Registered User
 
Join Date: Dec 2006
Posts: 280
Wait, so if you aren't using 2.6 for MT, what are the benefits then of 2.6 over 2.5.8?
DarkT is offline   Reply With Quote
Old 15th September 2011, 22:55   #260  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 981
Quote:
Originally Posted by SubJunk View Post
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.
TheFluff is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.