Jump to content

Search the Community

Showing results for tags 'multithreading'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Lounge/General chat
    • Education
    • Jobs
    • Marketplace
  • Houdini
    • General Houdini Questions
    • Effects
    • Modeling
    • Animation & Rigging
    • Lighting & Rendering
    • Compositing
    • Games
    • Tools (HDA's etc.)
  • Coders Corner
    • HDK : Houdini Development Kit
    • Scripting
    • Shaders
  • Art and Challenges
    • Finished Work
    • Work in Progress
    • VFX Challenge
    • Effects Challenge Archive
  • Systems and Other Applications
    • Other 3d Packages
    • Operating Systems
    • Hardware
    • Pipeline
  • od|force
    • Feedback, Suggestions, Bugs

Product Groups

There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 2 results

  1. Hello, I was recently testing a flip simulation on a workstation with dual xeon 2630 v4 processors 10 cores each clocked at 2.2 GHZ, to my astonishment my laptops quadcore 4770HQ @2.2GHZ delivered ,not the same, but better FLIP simulation times. Can anyone explain to me why this is. I heard someone tell me something about threading. Can someone give me some insight on which nodes are multithreaded. with the smoke solver its stranger when my division size is higher like 0.2 the quadcore processor absolutely destroys the dual xeon, flying past the simulation. but when I start reducing that division size the xeon processors start to catch up and eventually when I am at a final render division size the xeons are ahead of the quadcore. Also when I cache out a simulation and check task manager when the cache is somewhere in the middle of the simulation(presumably where the flip simulation has the most particles to solve), task manager shows the cpu hovering around 2-3 %.
  2. Hello. According to documentation, writing to GU_Detail is not thread safe. I have a couple of questions about that. 1. If i need to protect my data, i can use locks (UT_Lock). Cant it be used to write to gdp? For example (pseudo code): void doWork(GU_Detail *gdp) { { UT_Lock::Scope lock(); // Write to gdp here ? } } 2. I'd like to understand what GU_DetailHandle class is, and why and when should i use it? This class also offer some locking methods such as writeLock() and a helper class GU_DetailHandleAutoWriteLock. I guess the later is what i need? 3. To be clear, what i'm trying to do is to generate a hundreds of new GU_Detail instances in different threads, and then merge them down into one detail. Something similar to Duplicate SOP. Consider a following code single thread code: // get geometry from second input const GU_Detail *pattern = inputGeo(1); GU_Detail *copy; for (int i(0); i < 100; i++); { copy = new GU_Detail(pattern); // Call functions to modify copy geometry gdp->merge(*copy); } I want the for loop to be executed in parallel. I'm planing to use THREADED_METHOD2 macros. I'm curious, how GU_DetailHandle can be used in this situation to synchronise writing to detail? OR maybe i should go with another strategy, for example threads produces GU_Details, and main thread performs merging? I'd like to hear any ideas and your experience guys.
  • Create New...