Why so slow?

[sharmajai]

First of all I would like to say I love cobra specially as it has the pythonic feeling and the static typing good parts and I think since most of the source on http://shootout.alioth.debian.org/ is open source, we need volunteers to write the code for various benchmarks to give the language visibility. I could have done that, but didn't partly due to shortage and partly due to the demotivation by the performance. See below.

I ported the nbody program in python to cobra. But I have to say that either I don't know what I am doing or otherwise I am totally disappointed by cobra's performance. It does not perform even as well as python. I believe the real motivation for Cobra is it's speed over python, there are excellent other factors like no null values, but this is the predominant one.

The cobra program took 150 times (55sec to pythons .3 sec for n=10000) the time taken by the python code, now that is demotivating, I just have one dynamic clause in there, to simplify things, but I still expected it to be close to python at least.

Please tell me what I am doing wrong.

I am attaching both the sources.

Thanks and Regards,
Jai Sharma

[Charles]

Thanks for your interest in Cobra and your report here. I haven't thoroughly analyzed your code yet, but here are some initial thoughts:

-- Cobra does, in fact, have overall better performance than Python and often by quite a bit. See the recent discussion Cobra vs Python - speed.

-- Although platform is not the issue here, it's generally useful if you include your op sys name and version, mono or .net version, cobra version and python version in reports such as these.

-- Cobra programs run fastest when all extra run-time checks are turned off. We have a -turbo option for this, so for example, "cobra -c -turbo myprog.cobra" produces the fastest executable.

-- Although Cobra can compile and run in one shot, the two should be separated for benchmark purposes, as you would for say, Java or C#.

-- Cobra runs fastest with static types as opposed to dynamic. For example, "List<of number>()" is better than "[]" because "[]" is a list of dynamically typed elements. This applies to the previously attached code. Likewise, it would be good if "def combinations" could return something like "List<of number>" or "List<of List<of number>>" instead of "dynamic" if possible.

-- I sometimes find it useful to port from a C# version so I can see all the types. Or sometimes I look at both the Python and C#.

-- Cobra uses C# as its back-end, so assuming you respect the above points, you will get the same performance as C# on any benchmarks you see.

-- A profiler can be useful for determining bottlenecks. On .NET I use ANTS which is commercial, although a trial demo is available. I haven't explored profiling too much on the Mono/Mac/Linux side of things even though I often develop there.

-- A specific tip: Although slicing is convenient, it can be expensive because it creates another list. For example, in "def combination" you could drop the "ls" list creation and change the inner loop to "for yIndex in x+1 : l.count" and then change "y" to "l[yIndex]".

-- I don't currently get the same output from the Cobra code as I do the Python which is somewhat discouraging. I would like to know the two programs are semantically identical before working on the performance more.

-- I'm glad you brought this up because it points out that we need a wiki page to document some of these points. I will kick one off which we can grow over time.

-- If you would like to post another version of your code, I'll have another look.

[torial]

FWIW, if you are interested in profiling, there is a free option (limited to 10 dll projects) available at: http://www.eqatec.com/Profiler/Pricing.aspx

I've used it with some success, but haven't compared it to the more expensive ones.