fluid bake time differes between first and following bakes (up to twice slower as the first) #36796

New Issue

Alexander N. · 2013-09-22T16:55:04+02:00

Alexander N. commented

2013-09-22 16:55:04 +02:00

%%%--- Operating System, Graphics card ---
Ubuntu 13 64bit, i7-3770, (64GB SSD - partition)
Windows 7 64bit, i7-3770, (64GB SSD - partition)

- Blender version with error, and version that worked ---

blender-2.68-r60296-linux-glibc211-x86_64.tar.bz2 @ ubuntu - with issue
blender-2.68-r60296-win64.zip @ windows7 64 bit - without issue

- Short description of error ---

when baking fluid just after blender launched, bake time is normal.
when baking fluid a second time or third, bake time is up to twice as long as the first time.
to get the normal bake time again, you have to close blender application and relaunch/rearm blende. but only the very first bake will get the normal short bake time, the second ist again twice as long.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

open blender
open attached blend file
press "Bake" - bpy.ops.fluid.bake()
take the time from pressing bake to disappear bake progressbar on the status bar on the top
e.g.: 1:43.1 .. 1:45.8 (@windows 1:48.1 .. 1:52.3)
wait a moment, to be sure the CPU has a similar temperature (ensure that it is not a termap problem)
press "Bake" again
take the time from pressing "Bake" to disappearing progress bar
e.g.: 3:02.8 .. 3:04.4 (@windows 1:48.1 .. 1:52.3)
wait a moment, to be sure the CPU has a similar temperature (ensure that it is not a termap problem)
press "Bake" again
take the time from pressing "Bake" to disappearing progress bar
e.g.: 3:03.2 .. 3:05.9 (@windows 1:48.1 .. 1:52.3)

(time format: e.g.: 3.45.6 means 3 minutes, 45 seconds, 6 tenth of a second)

close blender application and redo the steps, you will see the same behavior.
(just reopen the file or open an other and then open the same file again will not fix that behavior)

(the fan of the CPU is silent, but you can hear a slight different speed between very first bake and the following bakes - at the following bakes the speed is not as constant as at the first bake.)
%%%

%%%--- Operating System, Graphics card --- Ubuntu 13 64bit, i7-3770, (64GB SSD - partition) Windows 7 64bit, i7-3770, (64GB SSD - partition) - Blender version with error, and version that worked --- blender-2.68-r60296-linux-glibc211-x86_64.tar.bz2 @ ubuntu - with issue blender-2.68-r60296-win64.zip @ windows7 64 bit - without issue - Short description of error --- when baking fluid just after blender launched, bake time is normal. when baking fluid a second time or third, bake time is up to twice as long as the first time. to get the normal bake time again, you have to close blender application and relaunch/rearm blende. but only the very first bake will get the normal short bake time, the second ist again twice as long. - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. open blender 2. open attached blend file 3. press "Bake" - bpy.ops.fluid.bake() 4. take the time from pressing bake to disappear bake progressbar on the status bar on the top e.g.: 1:43.1 .. 1:45.8 (@windows 1:48.1 .. 1:52.3) 5. wait a moment, to be sure the CPU has a similar temperature (ensure that it is not a termap problem) 6. press "Bake" again 7. take the time from pressing "Bake" to disappearing progress bar e.g.: 3:02.8 .. 3:04.4 (@windows 1:48.1 .. 1:52.3) 8. wait a moment, to be sure the CPU has a similar temperature (ensure that it is not a termap problem) 9. press "Bake" again 10. take the time from pressing "Bake" to disappearing progress bar e.g.: 3:03.2 .. 3:05.9 (@windows 1:48.1 .. 1:52.3) (time format: e.g.: 3.45.6 means 3 minutes, 45 seconds, 6 tenth of a second) close blender application and redo the steps, you will see the same behavior. (just reopen the file or open an other and then open the same file again will not fix that behavior) (the fan of the CPU is silent, but you can hear a slight different speed between very first bake and the following bakes - at the following bakes the speed is not as constant as at the first bake.) %%%

Alexander N. commented

2013-09-22 16:55:04 +02:00

Changed status to: 'Open'

Brecht Van Lommel commented

2013-09-24 00:20:57 +02:00

%%%I couldn't confirm this bug on OS X 10.8.4, though that's not really surprising of course, as it doesn't happen on Windows either.%%%

Bastien Montagne commented

2013-09-24 20:58:36 +02:00

%%%I can confirm the issue on my i7/debian64. Seems to be related to resolution too, at 50 it’s between 40 and 60 seconds here, while at org (110) resolution, first run is about 1min30sec, and I aborted the second one after more than five minutes!

I wonder what’s the issue here, CPU and mem usage look the same on first glance… :/%%%

%%%I can confirm the issue on my i7/debian64. Seems to be related to resolution too, at 50 it’s between 40 and 60 seconds here, while at org (110) resolution, first run is about 1min30sec, and I aborted the second one after more than five minutes! I wonder what’s the issue here, CPU and mem usage look the same on first glance… :/%%%

Alexander N. commented

2013-09-24 22:12:24 +02:00

%%%maybe a kind of memory fragmentation in RAM ... ;)%%%

Sergey Sharybin commented

2013-09-25 08:42:01 +02:00

%%%Don't think it's a memory fragmentation issue. We're using jemlloc on linux which reduces fragmentation comparing with native allocator.

It's something to do with openmp. The thing is, second time simulation runs, all the cores are loaded only by half (when doing simulation first time, all the cores are 100% load). This happens even if first simulation baked only 1-2 frames.

Not sure yet whether it's an issue of openmp itself, or some issue in elbeem.%%%

%%%Don't think it's a memory fragmentation issue. We're using jemlloc on linux which reduces fragmentation comparing with native allocator. It's something to do with openmp. The thing is, second time simulation runs, all the cores are loaded only by half (when doing simulation first time, all the cores are 100% load). This happens even if first simulation baked only 1-2 frames. Not sure yet whether it's an issue of openmp itself, or some issue in elbeem.%%%

Sergey Sharybin commented

2013-09-25 09:12:40 +02:00

%%%Further developer note: vtune reports one of the openmp threads pretty much doing nothing.

Brecht, you've got more experience in openmp troubleshooting than me, does this light some lamp for you? :)%%%

%%%Further developer note: vtune reports one of the openmp threads pretty much doing nothing. Brecht, you've got more experience in openmp troubleshooting than me, does this light some lamp for you? :)%%%

Sergey Sharybin commented

2013-09-26 12:27:20 +02:00

%%%Developer note:
Here's a patch which fixes obviously wrong mixing of max/num threads. Now elbeem would not have affect on omp blocks used in other blender areas. This still doesn't solve issue original issue tho.%%%

%%%Developer note: Here's a patch which fixes obviously wrong mixing of max/num threads. Now elbeem would not have affect on omp blocks used in other blender areas. This still doesn't solve issue original issue tho.%%%

Sergey Sharybin commented

2013-09-26 23:23:14 +02:00

%%%Developer note:
And here's another patch which fixes memory leak detected while looking into the code. Two questions about the patch tho:

Would want someone to doublecheck. Maybe there's an easier way to delete all vector's elements (call delete- on them).
Is it fine to have guardedalloc headers there?

As for the original issue, still didn't figure anything out.%%%

%%%Developer note: And here's another patch which fixes memory leak detected while looking into the code. Two questions about the patch tho: - Would want someone to doublecheck. Maybe there's an easier way to delete all vector's elements (call delete- [ ] on them). - Is it fine to have guardedalloc headers there? As for the original issue, still didn't figure anything out.%%%

Sergey Sharybin commented

2013-09-27 20:56:01 +02:00

%%%Developer note: patches have been commited to the svn.%%%

Alexander N. commented

2014-02-11 08:04:39 +01:00

Changed status from 'Open' to: 'Resolved'

Alexander N. closed this issue

2014-02-11 08:04:39 +01:00

Alexander N. self-assigned this 2014-02-11 08:04:39 +01:00

Alexander N. commented

2014-02-11 08:04:39 +01:00

i tested with "blender-2.69-2038eb1-linux-glibc211-x86_64.tar.bz2" and it looks ok to me - so i closed this track.
constant fluid bake time from bake to bake (~136.6s, ~111.4, ~109s, is see the differences as normal latency)

i tested with "blender-2.69-2038eb1-linux-glibc211-x86_64.tar.bz2" and it looks ok to me - so i closed this track. constant fluid bake time from bake to bake (~136.6s, ~111.4, ~109s, is see the differences as normal latency)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

fluid bake time differes between first and following bakes (up to twice slower as the first) #36796