PDA

View Full Version : Particle Flow not multithreaded?


pixel9
11-16-2007, 07:42 AM
Hi there...

Since I started off my own small project - it's the first one - I wondered why 3dsmax v9 (x64) only used 25% of CPU power. In other words, just one of my four cores was used to calculate the simulation. What is the reason for this and where are the problems for multithreading, basically if particle interactions matter?

I asked Anselm (aka Psychosilence) and he said that there is progress on that by Orbaz for example; but why not at Autodesk?

Wouldn't it be possible to divide a particle setup like this
http://www.tobyatwork.de/3d-worxx/experiments/particles/lava_fountain/particle_setup.gif
up to multiple CPU with MaxScript or even C++? Maybe, an additional software pipeline!?

Here's my WIP ;)
--> http://forums.cgsociety.org/showthread.php?f=206&t=562174

PsychoSilence
11-16-2007, 08:55 AM
teh freebies are the first to be multi threaded. other operators will follow soon after.

http://www.orbaz.com/forum/viewtopic.php?t=1048&start=0&postdays=0&postorder=asc&highlight=bit

we voted for 64-bit / multithread support and against downwards compatibility which will suffer of cause. just be a lil patient :)

pixel9
11-16-2007, 10:13 AM
Yeah, I already read this at Orbaz' forums, but where might be the problems in using multithreading for particles, except the need of some recoding stuff.

Isn't there a way to bind all cores together into a big one? - Might be a silly question to ask, but I ask it anyway :rolleyes:

OlegB
11-16-2007, 03:49 PM
Isn't there a way to bind all cores together into a big one?
... and then put on top a big red button "Make Art".
Working on that :)

Thanks,
Oleg B.

PsychoSilence
11-16-2007, 04:29 PM
:bounce::bounce::bounce: my render presets ;)

pixel9
11-18-2007, 09:12 AM
... and then put on top a big red button "Make Art".
Working on that :)

Thanks,
Oleg B.

Thanks for your explanation on this. :rolleyes:

OlegB
11-18-2007, 03:27 PM
A couple of recent quotes -

1. From http://blogs.techrepublic.com.com/programming-and-development/?p=374


Parallelism is a black art in code writing. Every piece of code is a special case scenario. Even worse, every hardware combination can alter the decisions you make. Up until recently, the vast majority of programmers could assume that their code would be running on a single CPU machine with more or less the same constant ratios of costs associated with multithreaded operations. Now, that assumption simply cannot be made any longer. A cheap desktop from the local shop with a single core x86 or x64 CPU is going to perform radically different than a system running a Core 2 Duo CPU, which will perform different from a 1U server with dual Xeon DP CPUs.

There really are no hard and fast, immutable laws out there on the performance end. Sure, there are some guidelines. Heck, I did a series on it a while back. Indeed, the overwhelming principle simply is: if the cost of context switching is less than the benefit gained, then multithread. Which is a really obvious statement, and of little help without knowing an awful lot about the runtime environment.

The idea of a compiler which automatically parallelizes code has seductive allure for me. But I know that it is doomed to failure in the current CPU environment. Maybe in five years which CPUs are scale about the same, and you can take a core count to determine the size of your thread pool at run time and use that, you will be fine. But right now, you would need to fork huge portions of your code and switch which chunk you will use at run time, because even the cost of lifting your entire code into one thread can take a heavy toll on your performance on a single core CPU, from my experience.

2. From http://techrepublic.com.com/5208-12845-0.html?forumID=102&threadID=214556&messageID=2193952

Multiple processors are best used by an operating system that is designed to use them. Jobs are assigned to processors based on load and run completely on one processor. The operating system manages how jobs are scheduled, prioritized, and time sliced. The user benefits from the increased computational power of multiple processors with a limited increase in expense.

Most applications do not need or benefit substantially from multithreading. It does not make sense to spend the effort to make them operate in that fashion. To do so increases their complexity tremendously with no appropriate gain for the user. The cost of development, maintenance, and enhancement is increased substantially. And, of course, the user must pay for this.

There are few developers who understand the complexity of multithreading. They should work on operating systems and on sophisticated applications that truely need multithreading, not the typical business or personal applications which are the majority.

Fortunately, the market will control this development. Software companies will not make the investment unless there is a substantial return. I don't think that we will have to worry about a big change in the near future.


As it was mentioned before, Orbaz Technologies is working on making PFlow to be multi-threaded. But again, it's not an easy process (one of the reasons - PFlow uses randomizers, and the randomizer algorithms are sequential), and the ROI (return of investment) is quite questionable. On the relevant note, how much would you willing to pay for a plug-in that makes PFlow multithreaded?

Thanks,
Oleg B.

JohnnyRandom
11-19-2007, 07:12 PM
:bounce::bounce::bounce: my render presets ;)

OMGLMAO!

Is that a box#3 preset you built:D


@oleg,

If autodesk won't pay for it (which in my opinion they should, it is basically maintenance for current features, hell wrap it up as a subscription goodie/release feature for all I care)

I would be willing to pay a reasonable "upgrade" fee, based on the investment I have already made with box 1 & 3 instead of chossing another solution.

PsychoSilence
11-22-2007, 06:45 AM
OMGLMAO!

Is that a box#3 preset you built:D

itīs actually photoshopped :D

Glacierise
11-22-2007, 10:26 AM
@Oleg - with 2008 bringing 8-core cpus, I think a multithreaded plugin will become essential point in making PFlow keep up with the times. I agree that it's a shame that AME does not take care of these things, but if you are to sell it, maybe 300 bucks? A lot of people will see it as a core functionality, and won't be happy to pay extra for it though. And all the 3 boxes, freebies, plus actions, and multithreading to buy and install, it's kinda clumsy :) Again, I guess the stones are in AME's garden.

BrandonD
11-23-2007, 11:27 PM
Multi-core CPUs are the new standard even outside of CG-land. If PFlow isn't multi-threaded, others will be. I've actually been testing a highly threaded app lately and it's downright scary how fast it is when it scales up to an 8 core system with 16gb of RAM.

JohnnyRandom
11-24-2007, 09:59 PM
Brandon you working on the upgrade to pflow j/k:D

moore's law has screeched to a halt:sad:, sure be nice to see all these cores get put to use in something other than rendering.

I was hoping to have a 12+ ghz processor by now!

CGTalk Moderation
11-24-2007, 09:59 PM
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.