Re: 64-bit Support

I just ran a quick comparison with x264. The results are below:

So 32-bit gave an average 15.384fps while 64-bit an average of 16.408fps, which is a 6.241% speed increase with 64-bit.Note that this is with everything else in 32-bit mode; only x264 is 64-bit. Theoretically there would be a larger difference in speed if the program (MeGUI) and other DLLs were 64-bit.

Re: 64-bit Support

did you guys try mvtools2 x64? When I used it I gained a boost of 10% (I measured it with several enconding tests) 10% of cpu saving in a quad core cpu or higher is a big saving.

It its a huge boost already available for everyone with a >1 cores CPU.

In my case I dont have a videocard to use SVP GPU mode and improve performance. Modern videocards are only designed for gamers and its a waste spend big amounts of money if you only need them to watch the desktop

Re: 64-bit Support

travolter

10% is too small. When we're talking about GPU support it's about 100-200% increase. With some minimal algorithm modifications we can get another 40% (wait for SVP 3.0.2 )Getting just a 10% for such a huge headache like porting to 64-bit? Certainly not now

Did you know that AMD processors are losing up to 40% speed in the original MFlow/MFlowFps? And it can be fixed with two lines of code.

Modern videocards are only designed for gamers and its a waste spend big amounts of money if you only need them to watch the desktop

Something like AMD 6450 for $70 could help And three digital outputs is also really helpful at home (configs like monitor+TV+projector (or another TV) isn't so rare now).

Re: 64-bit Support

Re: 64-bit Support

Why not compile the SVP plugin in x64? If you have the tools, just do it. ffdshow x64 exists, and avisynth x64 exists (unofficially, but it's still there). All the pieces are there.

"No inherent benefit to x64" is something I hear often- but there are two issues with that.

1) x64 WILL phase out x86 sooner or later. Eventually, x86 will be completely unsupported, as 16 bit is today. I'm aware this is a few years off, but it would be awesome if developers took a proactive stance on this. You never know when a dev will get distracted by life and abandon a project, or declare it "as good as it's going to get" and stop updating. Supporting x64 asap will allow users in the future to continue using this should SVP cease development.

2) Just because *your* code doesn't benefit from x64, doesn't mean other software won't, and one 32 bit component necessitates ALL related components be 32 bit. Somewhere down the line there's bound to be a part that benefits from x64. Many devs refusing to support x64 never consider this... Case in point: windows media player 32 bit cannot handle libraries larger than 3000 or so items without locking up and often crashing. x64 WMP does not have this problem. QED, SVP not supporting x64 cripples the use of WMP's library features.

Re: 64-bit Support

Re: 64-bit Support

To make it clear for both sides:

link68759, to be honest developer is just lazy to write whole 64 bit code from the beginning and that's it. Although it is understandable as it is a lot of work and nobody pays anything he still do not want to tell it straight. And when you ask him more and more logical questions he becomes angry that you just do not get what hies under "reasons" and that he needs to dream up newer and less compelling arguments.

Chainik, he really do not understand how would 32 bit version of program you use (lie on) be OK while 64 bit is NOT. Or how is that 5-15% increase may be insignificant when sometimes you need just couple more FPS to make it lagless. And therefore he doesn't give up arguing as he believes you are just mistaken about end result... he can't imagine that it is smth behind end result as you didn't write it straight.

@ALL, this is just a difference between mentality of 2 different nations. Mentality barrier I would say, not language one.

P.S. All I wrote doesn't mean to harm someone's feelings. I just made it straight.

Re: 64-bit Support

James DTo be even more clear:- avisynth x64 is not a stable one and will never be- all "hot points" in SVPflow libs're written with SSE2 (=> won't take any improvement from x64)- the hottest one lies in x264's assembler code and that code's identical in both x32 and x64 versions

And when you ask him more and more logical questions he becomes angry that you just do not get what hies under "reasons" and that he needs to dream up newer and less compelling arguments

All I wrote doesn't mean to harm someone's feelingsif you don't want to harm anything consider just don't saying stupid things at least on public

Re: 64-bit Support

Chainik wrote:

travolter10% is too small. When we're talking about GPU support it's about 100-200% increase. With some minimal algorithm modifications we can get another 40% (wait for SVP 3.0.2 )Getting just a 10% for such a huge headache like porting to 64-bit? Certainly not now

My CPU is a 2.0GHz Core 2 Duo T5800 and I am running Windows 7 SP1 64bit. All tests were ran with mostly stock copies of MPC-HC v1.7.6 32bit and 64bit (the only change is I set the "Video Frame" to be "Normal size") and nothing else (this means SVP was not running).

I do not know of how to benchmark the raw FPS numbers, so I am instead posting the CPU utilization as reported by the Windows task manager.

32bit: ~45-65% CPU utilization

64bit: ~25-40% CPU utilization

UPDATE: I just tried the exact same thing on an AMD E-350 (1.6GHz) and the results are even more dramatic:

Re: 64-bit Support

VP9 tests probably have to be taken lightly as they are still in development. Although I don't know the technical details, at this point it probably has more to do with how each implementation has been programmed for now than about being x32 or x64 itself. Perhaps (probably) the developers designed it for x64 first and then ported (patched) it to x32.