I had to double check it wasn’t an April fools joke - frankly, how can a optimised windows version run on linux faster than a native linux version that has been custom compiled?
If the blog is accurate, then even people on Linux should use Windows optimised versions! And there I was, thinking Blender runs faster on native Linux…
Can anyone kindly enlighten me?
Koba
P.S> The author of the blog would also like to know how this is possible!
It has to be the optimisations, they should work under wine, but it has the possibility of becoming really unstable. For pure power and speed an optimized build should be made for native linux
Perhaps, the tests didn’t use equivalent optimisation flags. The windows version may have been really aggressively optimised!
However, it is still a striking difference - I thought the use of SSE would be biggest performance boost. Do other flags really make such a huge difference?
Koba
P.S> I just noticed your sig. Know anything about getting Psycle to run nicely under linux?
some thoughts most forget about -
hardware differences cannot always used in the best way from the software.
why the windows blender version in wine runs quicker (even than the selfbuild-compiled one)?
the windows version seems to be compiled to take advantage of different cpu-types dynamically and if you are using one of those cpu-hardware, than you get the boost.
under new wine version (dont know since when they enabled this feature, instead of emulation the lowest level of i386 cpu, thats without … sse2 mmx…) the cpu-capabilities are read and the blender-prog. can use this information
the selfbuild blender version is slower as long you missed some of those special cpu-features (and there are more than even the professionals know, because some are always hidden by the cpu-manufactorer … and if its a intel-cpu, you need to use a closed-software-intel-compiler-suite to use those)
i hope you can know understand what may happen.
last, check the compiler-flags for the built - first there should be always the “-march” option set for the desired cpu, then comes some unroll-settings and the complicated thing is to use special optimized libraries. But this is still not enough till you have your hands on a cpu-optimized compiler-suite (incl. those tricky assembler-libs…)
Well… the optimized windows version I used to write the article is an ‘very’ optimized one by Mike Pan. On his website, he states that this could be “the fastest build to date”.
But the fact which bothers me is that even the standard, generic Windows build from blender.org is much faster than the standard Linux one.
I’ll follow the recommendations and test with this version of the official Intel compiler to see if things go faster on a native Linux one. As soon as possible I’ll return new values. =)
I compiled mine with Scons and used GCC 4.1.2 with these flags:
-pipe -fPIC -funsigned-char -fno-strict-aliasing -march=pentium-m -mmmx -msse -msse2 -mfpmath=sse -O3 -fomit-frame-pointer
These flags were actually the last try of optimization I did, which resulted in faster renders, as I stated on an update in my blog post. For those, I looked over a Gentoo tutorial on optimization and the official GCC documentation to select those. Maybe some useful ones are missing, or maybe I used wrong ones, though.
[edit]
Forgot to say that I don’t have Windows installed on my machine, so I can’t say if the windows binaries run faster than on Linux.
[/edit]
cheers
Official Blender: 00:57:98
Mpan3 Blender: 00:35:64
something else to say? WOW :eek:
P.S: just a question… why do I get diferent rendertimes everytime I hit the render button? I’m not speaking about 1 or 2 seconds, the first time I hit render in my scene I got 00:52:70, then 00:57:98 and the third time 01:00:23, why is this happening? I can understand if I’m running something else but this is not the case, same scene, no changes, no other programs running, just hit render several times and I get very much different render times every time.
Yes, that is true!
Blender, especialy an optimized windows build will run much faster in wine than in linux. There are a few reasons but the one i suspect who contributes the most for this is that “wine” itself processes the windows binary super efficient and much faster.
By any means, if a windows build under wine runs stable, go for it. The proof is in the pudding and arguing about time and compiler this an compiler that doesn’t solve anything. Wine delivers these days
Btw: Wine now runs other 3D apps such as C4D and A:M (latest Animation Master) but i don’t have any benchmarks for those apps other than that they run well enough for production use.
I did some tests a while ago and came up with the same conclusion, the windows version of Blender under Wine renders faster than The Linux 32 bits version of Blender, but the viewport display is slower too.
Anyway, if you have a 64 bits capable computer, you better go for native 64 bits Linux Blender, cause it runs like hell and is almost 30% faster than the windows version when correctly optimized. Not to mention all the memory usage advantages of a 64 bits system.
Sure! When I finally get myself a 64bit dual/quad core I’ll use those builds!
Not all of us have upgraded our CPUs just yet though. And it is a bit vexing that (somehow) windows builders can churn out faster builds than Linux builders.
When it comes to 64 bit, Linux certainly has the advantage.
because this test.blend is nice for some simple performance-checks,
i did some to clarify for myself (what i already thought)
but first to make it clear:
i lose the most time when i do not know how to do some things
or do it the wrong way till i notice how to do it right and simple there are too complex problems to solve without deep inside knowledge (and blender as a 3d application is really complex)
all time-results on the same computer with same OS hardware:
amd-sempron-3000+ (=max. 1800GHz, with small 128kb-Cache), RAM 1GB
running ubuntu-7.04 with 2.6.20-16-generi-kernel 32bit
-time Minute:Seconds---- and blender-version
05:25 blender-2.45 download from blender.org, the i386 version
04:53 blender-2.43 like its got with this older ubuntu-version(build from the ubuntu-maintaners)
03:53 blender-2.45rc svn-version built with -march=k8 for this cpu
03:45 same svn-version but built with sse for math and partly unroll
there are still tweaks for adjust the code-size to fit better into the cpu-cache
and shure there are some tweaks to adjust the position of code-parts.
But, like told, most time-penaltys are made by myself
for example doing a full render, if a part would be enough to check settings
… which reminds my about to read again how to quickly select parts …
test-dr,
well said. This has been on my mind for quite a while now. So many posts about RAM and all kinds of fancy hardware … so little production.
When it comes down to producing artwork with blender what counts is ones ability to “optimize” a scene because if that is not done, then the fastest processor and a giga-ton of memory will not safe the day.
As you put it, knowing how to tweak settings efficiently is more worth than a (small) render farm.
In closing, there are a few linux distros like PCLinusOS which are popular but have no way of running a recent blender build. For those, the windows/wine route is well worth exploring.
Interesting how things can easily go misunderstood.
Let me quote a paragraph on the text I wrote in my blog, which was the starting point of this particular thread (and not the entire wine thing, which you wrote a while ago and inspired me to think and write about it. There is even a link to your original thread on my text for reference):
So, let’s suppose there is nothing else I can do with my Blender scene (everything is optimized, from vertex count to lights and textures) and a hardware upgrade is out of question. How much does some environment adjustments change my render speed?
That was the main question I wanted to answer. If one reads it carefully, s/he will understand that knowing what you are producing is the first and most important thing to do. How to build a well tuned 3D scene without losing quality and without unnecessary things that will only slow down everything: knowing this always comes first.
What I stated is that there are also some environment tweaks that can speed up things when it comes to rendering.
I am currently producing a short animation, and as I don’t own a renderfarm nor even a high-end machine, I’m doing all I know (and I keep learning during the process) to fit my production into my available resources.
I really think that an uber optimized build won’t make any miracles. In fact, if I (or many of you) thought so, I probably wouldn’t start using Blender in the first place. When I started using it (i guess it was version 2.28) it hasn’t all goodies that blows everyones’ minds today. If I believed that a tool is more important than the person behind it, I would go for that one piece of software people always raved about back then.
Most official linux builds have few optimisations; it certainly helps distros support older hardware better. The self-compiled build compares well with the official windows one because I suspect the default windows build has a few more optimisations in by default.
It’s certainly much easier to tweak individual sub-projects’ build settings in VS than to find out all the configure options at the command line in linux, so that might explain why there’s more Windows builds coming out.
Mainly, he’s built with “profile guided optimization” and OpenMP which is why his is so fast. Not sure how easy it is to do that on linux though as I think “profile guided optimization” is a function of VS?
