R20 (multithread?) - what does it meant for users?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
  01 January 2018
R20 (multithread?) - what does it meant for users?

So, I was wondering, being multithreaded.. what does it meant?

- will mofracture be faster? currently is a little slow if you add detailing
- will xparticles be also faster and support more particles before slowing down?
- what about cloth dynamics?
-does it meant new features or a speed improvement of current features?

thanks in advance.
__________________
demo videos
Close, open-relationship: C4D / Zbrush
Hate / love: Maya / Houdini
Former gf: XSI
 
  01 January 2018
There is no R20 yet, so it means nothing.
 
  01 January 2018
As noted above we don't know much about R20 yet. We know that they intend to continue adding improvements to Pro Render for example (because they said they do), but otherwise speculating is pointless.

That said, it sounds like you want to understand the concept of multi-threading... so...

What's important to understand is that creative applications like this are not wholly multi-threaded. When a developer says their app "is multi-threaded" what they mean 95% of the time is that selected features  have been written (or re-written) to take advantage of modern processors, which have many cores. Iif you think of one processor core as "one brain," certain features lend themselves  to being processed not by one core / brain at a time, but by multiple cores. Other features don't benefit at all; multi-threading them would be a total waste of MAXON's time. That's why it is usually incorrect to say "application x is multi-threaded." But for those features that can benefit, they could use 2, 4, 8 cores (or more)... and thus process their results 2, 4, 8x (or more) quicker, to keep it simple.

But even if we knew that MAXON intended to add multi-threaded functionality to R20 (we don't), there wouldn't be much point in talking about it unless they told us in advance WHICH features were receiving that treatment (they won't, most likely). Also, when developers do this sort of thing as part of a plan to improve the app long-term, typically only 2-3 features at a time are re-written to take advantage of multi-threading. So don't get your hopes up. We'll just have to wait and see if it happens, and to which features. And if they're doing this kind of improvement, it will likely be several years before they are finished.

Last edited by Blinny : 01 January 2018 at 05:33 PM.
 
  01 January 2018
Multithreading means that instead of 1 CPU core doing everything, 4, 8, 12, 16 or more cores work together on the same task. Everything that is multithreaded thus runs much faster than before.

For example, you could have 8 complex, rigged, animated 3D characters in a scene, and using 8 CPU cores - one to calculate the deformations for each character - the whole thing would preview very smoothly in the OpenGL viewport.

Any task that is multithreaded, from cloth to particles, would calculate much much faster.

 
 
  01 January 2018
Originally Posted by luisRiera: - will xparticles be also faster and support more particles before slowing down?

X-Particles and other plugins have their own threading. R20 won't impact one way or another. I don't think.
__________________
C4D R19 Studio, MODO 902, VRAY, Octane, Cycles. PC/Mac.
 
  01 January 2018
It depends, X-Particles uses C4D framework so if some part wasn't but change  to be multi threaded then it impacts X particles. I remember  Cebas complaining of 3Ds Max Particle Flow not being multithreaded and influence it had in Thinking Particles.
 
  01 January 2018
There is a lot of half true information being thrown around on Multithreading.
Multithreading means that a task can be handled by more than one thread. This does not imply or necessitate the use of multiple cores or multiple CPUs.
Multithreading does only make sense if it can be done efficiently. Practically every task can be multithreaded, but the efficiency can often be worse compared to single threading.
What most people don't know is that there are always dependencies between the multiple threads a task is split into. These can be very loose, common initial data, or super tight, high dependence on results from other threads. With high dependencies the efficiency of multithreading goes down fast, to the point where the gain is negative.
Cinema 4D uses multithreading throughout the application, but to very different degrees. In the render engines it can be used at maxium efficiency, actualy so good that CPU developers use Cinebench to evaluate the efficiency of their multi core CPUs. Over time, due to increased experience or better algorithms or tools available, basically all parts of Cinema 4D become more efficient and faster. Wherever possible tasks are multithreaded or otherwise sped up, sometimes hampered due to the need to stay compatible.
What the new core does is building a more modern foundation for all functions inside of Cinema 4D. The knowledge we gained from over 20 years of development was put into creating a faster and more flexible foundation for the future. A good portion of this knowledge concerns threading and the efficient use of it, that does not mean that in the future everything can and will make use of multithreading, as i pointed out above.

tldr: there is no magic multithreading potion
__________________
- www.bonkers.de -
The views expressed on this post are my personal opinions and do not represent the views of my employer.
 
  01 January 2018
Im sorry for the confusion about multithreading.. If I may ask.. how can Maxon improve speed in certain areas? or, what does a new core engine means? I thought everything was being "multithreaded", my mistake for lack of knowledge.

edit.. just noticed you already responded.. Im a little sleepy I guess..
__________________
demo videos
Close, open-relationship: C4D / Zbrush
Hate / love: Maya / Houdini
Former gf: XSI
 
  01 January 2018
A simple thought experiment, to see how multithreading is not a solution in many cases is with the domino effect.
When you have a single row of dominoes, no other domino can be calculated unless the neighbour collides with it. Therefore each domino row needs to be evaluated in a sequential manner.
Now, if you have many rows of dominos that don't interact, you could, in theory, assign a different thread to it, but that raises the question of whether each row will eventually interact, something you won't know until it happens. So, even if 2 rows of dominoes, assigned to 2 threads are being evaluated in parallel, the moment they interact, you need to bring them both into the same context of serial execution, as one affects the other.
I'm sure there are ways of dealing with problems like these in a more efficient manner, but overall, this is a typical example where multithreading can't be (easily) implemented.

As a side note, I have had experience with another application, where  multithreading, made a particular simulation run faster when I restricted the execution to 4 threads out of 24 available.
This is an example of multithreading slowing down the performance, rather than making it faster.
__________________
Follow me on Twitter@nosemangr - Watch me on Noseman's Youtube Channel
 
  01 January 2018
Originally Posted by luisRiera: Im sorry for the confusion about multithreading.. If I may ask.. how can Maxon improve speed in certain areas? or, what does a new core engine means? I thought everything was being "multithreaded", my mistake for lack of knowledge.

edit.. just noticed you already responded.. Im a little sleepy I guess..

Some parts of C4D, as with every 3D program, haven't been touched in any meaningful way for a long time. Some parts of C4D are virtually the same code from 20 years ago. Back then, multi- core/cpu machines were rare and the tools for working on them were poor, so little to no effort was put into making the features capable of using more than one core at a time because it just wasn't worth the effort in a time when we all had single Pentium 3/4 chips or G3 and G4 machines.

Obviously, the direction has been more cores instead of endlessly faster GHz speeds, and so some features can only use a fragment of the available power. One example would be lens flares, that code hasn't changed much since C4D was back on the Amiga.

The problem for a long time is that some parts haven't been sped up and improved, because to do so would have just been putting a bandaid on, what needed to happen is for the new foundations to be laid for the Future, and then the new Features could be written for this. The first stage is done, now they are onto the stage where old stuff can be re-made and new features can be added. Though as Srek states, some features are just pointless to write for use on multiple cores because each bit of code on each core depends on the results of another core, so they're all just sat there doing nothing.

In a nutshell, what needs to happen, is currently happening, it's just a question of time before you see the results. One thing we are all waiting on which affects almost everything you do in C4D, is an improved object handling system. Every item you have in C4D causes it to slow down. Every keyframe, every tag, every object, every particle. The more that exist, the slower it gets. This is why a cloner with 20,000 objects and 1 million polys is much slower than 1 object with 1 million polys.
__________________
Matthew O'Neill
www.3dfluff.com
 
  01 January 2018
Originally Posted by imashination: This is why a cloner with 20,000 objects and 1 million polys is much slower than 1 object with 1 million polys.


That's a perfect task for GPU acceleration. I'm writing a GPU algorithm right now that runs on over 1000 GPU cores on an Nvidia 1060 GPU.

For stuff where you need to, say, recalculate the position, rotation, scale and velocity of 100,000 objects each frame, GPU really is your friend.

Coming from CPU, I'm actually constantly surprised how many types of calculations GPUs can pull off really quickly compared to CPUs.
 
  01 January 2018
The problem as far as im aware is the complexity allowed by GPU. A GPU can certainly handle vast amounts of parallel data, the problem comes with adding depth and complexity to them. For example with GPU render engines, they can process vast numbers of pixels quickly, but the shaders and materials for those pixels cannot be too complicated, or it has to render them in several passes which would defeat the point.

So yes you can handle many objects, but can they have material tags? compositing tags? check for xpresso nodes? parse mograh effectors? still work in a hierarchy? refresh other objects in the scene when needed? change parameters of the object, per object, with a falloff in an animation whilst reacting to an LOD object?

Plus what happens on a slower GPU, would cinema be usable with an intel gpu? will it stay stable with all the driver fluff? does it react the same under opencl/metal across platforms?
__________________
Matthew O'Neill
www.3dfluff.com
 
  01 January 2018
A question, any idea if GPU would also be in use by this code rebuild of Cinema 4D  or is just CPU?
 
  01 January 2018
There is no restriction in the core to use only CPU or only GPU for anything. hat is used depends on what is needed and makes sense.
Hard dependencies are a difficult concept,  if GPU use were implemented in every aspect of the core then the use on virtual machines for rendering or similar would be made difficult and user with single GPUs or even only mobile GPUs would have serious disadvantages.
__________________
- www.bonkers.de -
The views expressed on this post are my personal opinions and do not represent the views of my employer.
 
  02 February 2018
Originally Posted by imashination: The problem as far as im aware is the complexity allowed by GPU. A GPU can certainly handle vast amounts of parallel data, the problem comes with adding depth and complexity to them. For example with GPU render engines, they can process vast numbers of pixels quickly, but the shaders and materials for those pixels cannot be too complicated, or it has to render them in several passes which would defeat the point.


The current GPU algorithm I am working on is over 200 Kilobytes of C source code and runs parallelized on hundreds of Nvidia 1060 GPU cores - each core executes the whole 200Kb algorithm in its entirety.

So far I have not come across any sort of "it has to be simple to run on GPU" problem at all. I've been throwing dozens of pages of hugely complex math at the GPU and it hasn't complained that it can't run it or somesuch. Everything runs in realtime at 4K UHD 30 FPS, too.

So the idea that you cannot have complex materials or shaders calculated on GPU is probably false. GPUs actually excel at precisely the kind of math that materials and shaders are calculated with.

What GPUs are not designed for - yet - is typical CPU tasks like sorting Database records, compiling source code, serving webpages to remote clients, running Javascript or executing application code that has huge amounts of branching in it.

But even that may change 5 - 6 years from now. You may one day have a desktop computer that is basically just a powerful GPU and has no CPU at all - everything from the OS to the software apps runs on a GPU with thousands of worker cores and say 64Gb of VRAM on this computer.

The biggest challenge with GPUs is that a lot of software was written specifically for X86 CPUs many many years ago, and if you were to shift some or a lot of it over to the GPU, you'd wind up having to port and rewrite hundreds of thousands of lines of legacy CPU code to GPU code.

Unless there is a pressing need for more speed, software companies are just not going to go to the time and expense of undertaking such a port.
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:36 PM.


Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.