PDA

View Full Version : Maxscript vs SDK speed test


reForm
01-11-2009, 11:44 PM
I'm trying the SDK for the first time and thought I'd try a very simple function speed test. For those interested, here are the results:

Please correct this code if its not a fair test.

Maxscript:

gc()
t1 = timeStamp()
test = 0.0
for i = 1 to 5000000 do --however many iterations
(
test += 0.2*0.3
)
format "maxscript\nresult:%\ntime:% ms\n" test (timeStamp() - t1)
t1 = timeStamp()
test = fpbasics.products 0.2 0.3
format "plugin\nresult:%\ntime:% ms\n" test (timeStamp() - t1)


The fpbasics.products function is a slightly tweaked version of the fpbasics sample provided with the SDK. The main function is as follows.


float FP_Basic::products(float x, float y)
{
float i,k;
k = 0;
for (int i = 0; i < 5000000; i++)
{
k += x * y;
}
return k;
}


Listener output :

OK
maxscript
result:309050.0
time:6297 ms
OK
84581920
309050.0
plugin
result:309050.0
time:47 ms
OK

RobGalanakis
01-12-2009, 12:21 AM
It'd also be nice to see a C# version, how would that compare?

reForm
01-12-2009, 12:26 AM
I'm not sure how to set that up. The max sdk samples and wizard are c++ as far as I can tell.

ZeBoxx2
01-12-2009, 12:39 AM
moreover it'd be more interesting if x and y varied in each loop - don't often have the need for 5,000,000 times the exact same mult :)

reForm
01-12-2009, 11:14 AM
Heh, true, but my code is adding the multiplication to the variable on each iteration, so there is definately math occuring each loop.

When I get a chance, I'm going to do some extensive speed comparisons and I'll post them up here. I'm curious to see just how slow passing large arrays to a plugin actually is.

reForm
01-12-2009, 12:09 PM
Ok. I adjusted the plugin so that the multiplications are different for each iteration.

Maxscript :


k=0.0
x=0.2
y=0.3
t1= timestamp()
for i = 1 to 10000000 do (
k+=(x+i)*(y-i)
)
format "Maxscript:Result:% Time:%ms\n" k (timestamp() - t1)

t1= timestamp()
fpbasics.products x y
format "sdk:Result:% Time:%ms\n" k (timestamp() - t1)




C++:

float FP_Basic::products(float x, float y)
{
int i;
float k;
k = 0;

for (int i = 0; i < 10000000; i++)
{
k += (x+i) * (y-i);
}

return k;

}



Listener

Maxscript:Result:-3.36984e+020 Time:12328ms
OK
43304234
-3.33543e+020
sdk:Result:-3.36984e+020 Time:31ms
OK


So.... SDK is only 397 times faster for a simple looped function....

I assume there's no flaw in my code that skews the result in favour of the SDK? My last attempt at a benchmarking test was embarrasingly flawed!

ypuech
01-12-2009, 12:29 PM
C++ is faster than MAXScript and C# for sure.
But it's faster to develop in MAXScript than in C++... So you have to choose depending on the complexity and use of your tool.
The best choice for me is to have a core interface in C++ for the hard computing tasks and a script to call this core and build the UI (it's a pain designing UI in MFC or Win32).

reForm
01-12-2009, 12:39 PM
Yep, that's what I'm intending to do. I have a script that I've optimised as much as is possible, but I need it to run faster so I'm hoping to transfer some functions into c++.
I knew C++ would be faster but it's nice to see quite how much faster it is! :)

Light
01-12-2009, 07:22 PM
As long as the for loop logic is included in C# (like Patrick did for C++), C# would hands down outperform both. Even considering the cold startup overhead on the CLR and the potential overhead of calling a C# method from Max would likely be bigger than that of C++.




Light

reForm
01-12-2009, 07:57 PM
Interesting. What makes c# faster than c++? (please excuse my ignorance of the subject!)

Given that all the SDK samples and howto files are in C++ and the wizard is c++ I'm in no position to try to make a c# equivilent of the speed test I'm afraid! Is it even possible to compile a c# program as a .gup?

Are you an Oilers fan?

RobGalanakis
01-12-2009, 08:07 PM
Not needed, which is why C# is so attractive for Max now. You can just work with any classes you create from within MXS. For example, I DLed a DLL from Codeproject to work with zip files, all I have to do it call:

zip = (dotNetClass "Ionic.Utils.Zip.ZipFile").Read(dotnetobject "system.string" zipfilename)

etc. There may be better ways to use simple functions (like your for loop) rather than as members of a static class or on an object.

Could someone with good C# skills try out this test (I'd like to see you back up your claim, Light)?

Also, reForm, as far as optimization goes- I have found that MXS's biggest slowdown is getting and setting properties (as described here (http://tech-artists.org/wiki/Performance_Tests_(MAXScript)), which I think you've read). Be sure you need to go into C++. We wrote an entire Vertlet sim in MXS, and the math part of it was an almost negligible performance (rendering, and getting/setting properties (which we eventually moved into global array accesses and get/set properties just once, which is must faster) probably 80% of the processing time, the math maybe 5-10%).

Light
01-12-2009, 08:26 PM
Not a hockey fan actually. So Oilers kinda freak me out (:

I have written this code for you:

using System;
using System.Collections.Generic;
using System.Text;

namespace LinearAlgebra
{
public static class Arithmetic
{
public static double Multiply ( double a, double b )
{
double result = 0;

for ( int i = 0; i < 10000000; ++i )
{
result += (a + i) * (b - i);
}

return result;
}
}
}

Just create a class library and compile it in Release mode. Then use this Maxscript code to load:

DotNet.LoadAssembly @"C:\<assemblyName.dll>"

and replace the method call with this:

result = (DotNetClass "LinearAlgebra.Arithmetic").Multiply

You can only compile as a .dll. If you can't compile, then I can send you the dll I compiled.

Basically certain things are well optimized in the CLR (http://en.wikipedia.org/wiki/Common_Language_Runtime). There are some guidelines as to what might be faster but for others you just judge it by experience, looking at the IL code (http://en.wikipedia.org/wiki/Common_Intermediate_Language).

I just tried it on my and got results between 15-31ms, which is mostly the cold startup overhead of the CLR.

A more accurate timing for C# would actually do some computation before the timing just to isolate the operation.




Light

reForm
01-12-2009, 08:28 PM
Interesting stuff!

My script definately needs to leave maxscript. At the moment, its not a realtime operation, but I would like to maybe introduce realtime manipulation later once I've got my head into c++ (alot) more! :)

As it stands, the script has some bottlenecks. I'm arraying multiple objects onto multiple faces with deformations calculated based on the distribution object face shapes. The slowest part of the script is a loop where I cycle through each vertex, and then calculate the total of the averaged weights of that vertice in relation to its deformation control points. Its a simple bit of math, but the depth of the loop and number of iterations kills maxscript(speed-wise). I assume this is the kind of operation that is ideal for translating into c++ or c#?

Besides this, I may think about making my script into a proper modifier at some point as it would be a more logical form for the tool to take.

Having said all this, I must look into the c# option. You say I don't need to create a .gup ... if so how would I distribute a plugin written in c#? Install into the windows system32 folder? Apologies if I'm missing your point entirely :)

reForm
01-12-2009, 08:30 PM
I have written this code for you:


Nice one Light! I'll check that out and perhaps write a more taxing bit of code for testing purposes.

Thanks for sharing!

Light
01-12-2009, 08:44 PM
The resultant dll can be anywhere but preferably inside a folder under Max. I put them into <maxroot>/stdplugs/managed.

So you only have to distribute the dll itself.

But the problem with Max's .NET integration is, it doesn't provide a managed wrapper for Max SDK, which means you can't write Max related stuff using C#, IronPython, VB .NET, etc.

However you can work around it by using COM, or wait for someone to release a managed wrapper for Max. :p




Light

reForm
01-12-2009, 08:48 PM
Ah... so if I wanted to work on a mesh directly, I would have to do it in c++...

Have you any experience of sending massive arrays to c# functions? I could probably get away without using any max core operations if I can pass a massive array of vertex positions to and from my function.
Failing that, I'll have to look at reading vertex positions in c and populating my arrays directly in my compiled plugin. fun fun fun.

Light
01-12-2009, 08:59 PM
Yes, sending massive collections from Max into C# is VERY slow. One tool we wrote here using C# and Maxscript, is instantaneous on the C# side but takes several seconds to minutes for Maxscript to send the data and get it back.

There is also the issue of killing Max when you send it all in one shot if there are millions of elements. For that you have to send in pieces (say 10000 each time).

In that case you still shouldn't destroy the generic nature of the C# plugin IMO.

So for that I do it like this:

1. Generic code in C#
2. Max interface code in C# (that contains the specific workarounds)
3. Maxscript code

By doing that, you get the benefit of being able to use the generic managed plugin anywhere you want, say in Maya, XSI, etc.




Light

reForm
01-13-2009, 12:00 AM
Well, here are the results. Same routine as you put in the c# code for the maxscript and c+(plugin) tests.

maxscript : 16516ms
c++ : 141ms
c# : 47ms

nice :)

Gravey
01-13-2009, 12:20 AM
something else you may want to consider checking out is the IntervalArray maxscript plugin example. I remember speed testing the results compared to using maxscript's collect function and maxscript came out ahead, probably due to the collect function being so awesome. At the very least it's something to keep in mind.

reForm
01-13-2009, 10:33 AM
something else you may want to consider checking out is the IntervalArray maxscript plugin example. I remember speed testing the results compared to using maxscript's collect function and maxscript came out ahead, probably due to the collect function being so awesome. At the very least it's something to keep in mind.

Funny you should mention that, I was looking at that example last night. When I get a chance I'll do some comparisons.

duke
10-10-2009, 09:04 AM
Sorry to raise this from the dead, but has anyone tried the MaxDotNet thing from Ephere? How does it compare speed wise?

CGTalk Moderation
10-10-2009, 09:04 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.