Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
You can spin off threads all day long. If they all block waiting for resources performance is actually worse than doing the same task in one thread.
Take loading a figure. The base figure file has to be read into RAM from storage. There really is no smaller atomic operation there so creating additional threads will not help. Then all the characters morphs have to be found and loaded. Since the install process is just unzipping files and putting them in the file structure that means reading every file in some part of the Daz file structure, processing the ones with morphs,. rinse and repeat. Again reading a file is an atomic process and the I/O op must block even if you try to create a thread for each file. The processing could be spun off if the thread overhead is worth it but processing text files is fast and creating threads is slow. Now the texture has to be loaded from file, another atomic operation, and so on.
Multiple threads are best for times when the system needs to perform the same algorithm many times on different data. for instance tile based rendering, or some process can run to completion without interfering with the user.
Creating a bunch of threads just because you naively think a bunch of threads will finish the job faster probably won't.
Also keep in mind that if there are, say, 3 dozen active threads but only 8 CPU threads available then every time an active thread is due for a time slice the previously active thread's whole state must be placed in RAM, then the new thread's state has to be read from RAM into the CPU. This is pretty trivial per thread but if a bunch of threads are blocked waiting for the same resource or waiting for data from a thread running a long process then all that swapping adds up. So it is usually a good idea to keep the thread count low or, in the case of very parallel processes like tile rendering, polling the CPU for the available physical threads available and keeping the number of created threads at or below that total.
i doubt performance would be worse if everything is loaded at the same time, and stored in RAM until another processed has finished to just collect the data from the RAM, instead of having to load each item seperately, then process the data. one item at a time
morphs are only float values, you can end up with 1000 loaded onto the G8 base model, 32 threads would be aload quicker, then 4 or 8 threads
Except that a) the disc IO would be flooded and would be stuck waiting and b) morph deltas are discarded if the morph is zero (I think they may be discarded anyway, and reread if they are needed due to an ERC link or the like, but that is a guess).
In any event this is all building cstles in the air since we do not have the details of the processes involved and, as far as I am aware, have not coded a similar system ourselves.
things have to move with the times to stay on top of the game, all a user would need is their content library on a nVME
https://www.enterprisestorageforum.com/storage-hardware/nvme-speed.html
Exactly. It's the AMD video cards and not AMD cpus that doesn't support Iray.
You clearly don't know how these things work at the low level.
I'll skip the EE stuff and just try to explain from a coding abstraction what is going on.
The basics, hardware threads are parallel command pipelines. Software threads are an analog of that but while there limits on the number of HW threads there isn't one on SW threads, unless imposed by the coders. RAM and I/O devices (drives, USB ports, graphics cards etc.) are not designed for parallel access but serial, IOW these devices expect one discreet operation at a time. So if two or more threads try to access such a device at the same time the results are undefined, IOW 2 threads trying to open 2 files and reading their contents could get blocks of data from the other file. So in order to access I/O safely in a multithreaded environment a thread must first check that the resource is unlocked, obtain a lock on that resource while using it and then release that lock when it is done. If a thread needs access to a locked resource it blocks, stops processing, until the lock is released. So 2 or more files, on the same drive, cannot be read at the same time.
Now why is performance worse for a situation where lots of small text files are read and processed? Creating a thread takes a not insignificant amount of time and consumes some resources. Checking for a lock takes clock cycles. Repeatedly checking if the lock is released takes clock cycles. Acquiring a lock takes clock cycles. Getting data from one thread to another has to be done in the same manner as accessing a resource, the thread waiting on the data blocks until the other thread signals that the data is ready which again wastes clock cycles. Closing a thread takes clock cycles as all the resources used by that thread are released.
So in a single thread its read file, process rinse and repeat. To do it multithreaded it's this: Main thread spawns threads for each file then blocks waiting for the threads to signal they're done. Each thread tries to read a file, blocks waiting for the drive to be available, reads the file, does the processing, signals the main thread that the data is available and then the thread has to be closed.
So running mutliple threads when I/O is heavily involved or relatively light weight processing needs to be done just doesn't make sense. Threads work great for manipulating data that is all held in RAM or where a thread can have exclusive access to the serial resource.
Going to NVME storage will help as the length of time needed to read each file is reduced. As would using drives in RAID 1.
Finally it is extremely difficult to convert existing software from single threaded, or lightly multithreaded, to heavily multithreadedeven if the use case makes that appealing. The code needs a ground up rewrite. thread code need to be broken out of the existing program and have all the locking/blocking/signaling code added. Then this all needs to be tested. Nothing is quite as hard to detect as some inobvious thread bug (such as two threads getting access to a pointer to a stored value where they change the data unexpectedly). You could run the program, with identical conditions, dozens of times and only have the error occur once. Trying to trace through and debug the issue won't help as that is an inherently time consumptive process and tracing through in a debugger dozens of times, examining each variable at each step, would take dozens to hundreds of man/hours.
i know how it works, if it worked your way, a game level would take a week to load, instead of 1 or 2 minute(s)
No it wouldn't and doesn't. Games were single threaded until just the last couple of years and load times were rarely an issue. I get that you think you know better but facts are stubborn things.