Dinkydau
|
|
« on: February 24, 2017, 03:20:12 AM » |
|
I have noticed 2 ways in which Kalles Fraktaler can be found to be rendering much slower than it actually can. I don't know the causes and I don't know whether these are related.
The first is that something is taking up a lot of time when doing renders at a resolution close to the maximum. After the first reference point there are very long periods when the program uses the full capacity of one CPU core. Could it be the series approximation taking much longer with large images? I would guess it's not the reference calculation because that's multithreaded. I was also thinking of image resizing code. The zoom-in animation is slow on my computer when I use a resolution larger than the default 640×360. I can imagine, if similar code is used to display the render in progress, it taking a very long time at a resolution that is 2330 times larger than default.
The second problem happens at large depths (say, E3000+, but that's just a guess). It has happened a few times that the first rendered pixels started to appear and it was so slow I could see them appear in groups of maybe 12. After restarting the program the rendering is a lot faster. I couldn't get the rendering to be faster again without restarting the program. Thus far, each time it happened, it was after I did the following: I make use of Newton-Raphson zooming and I let it zoom to the minibrot. When the first reference is computed, I select "reuse reference" and set the zoom depth to what I want it to be manually. Then I can use the same reference to zoom in and out and find the morphing I want. Ideally it's at 0.75*(minibrot_depth) but sometimes it's not. Something that may be relevant is that I use hibernate. Especially at large depths, I may hibernate and restart my computer several times during the Newton-Raphson zooming.
|
|
|
Logged
|
|
|
|
quaz0r
Fractal Molossus
Posts: 652
|
|
« Reply #1 on: February 24, 2017, 03:34:25 AM » |
|
i think kalle ties the number of series terms used to the resolution, increasing the terms with increased resolution. i doubt there really is any good heuristic you could come up with to make that behavior optimal in all cases. is that behavior able to be overridden / configured ? i suspect overall it is a misguided approach
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #2 on: February 24, 2017, 07:25:29 AM » |
|
You're right. "Auto approximation terms" can be disabled and the number of terms can be set. I may have forgotten that when I attempted the large render.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #3 on: February 24, 2017, 01:45:46 PM » |
|
Yes, first issue is that series approximation is using more terms for higher resolution. I didn't limited it to a reasonable maximum though...
Second issue I don't know. I guess you've done like that many times without problem, or does it get slow every time you do like that? I tried it but couldn't see any difference myself...
|
|
|
Logged
|
|
|
|
DarkBeam
Global Moderator
Fractal Senior
Posts: 2512
Fragments of the fractal -like the tip of it
|
|
« Reply #4 on: February 24, 2017, 04:52:36 PM » |
|
Effectively often kalles gets very slow in some spots. I found that it happens often when the images are closer to the bulb or in some elephant valley locations while the classic "antenna" is almost always super fast.
|
|
|
Logged
|
No sweat, guardian of wisdom!
|
|
|
quaz0r
Fractal Molossus
Posts: 652
|
|
« Reply #5 on: February 24, 2017, 05:01:21 PM » |
|
Effectively often kalles gets very slow in some spots. I found that it happens often when the images are closer to the bulb or in some elephant valley locations while the classic "antenna" is almost always super fast.
thats just the mandelbrot set
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #6 on: February 24, 2017, 06:45:25 PM » |
|
Yes, first issue is that series approximation is using more terms for higher resolution. I didn't limited it to a reasonable maximum though...
Second issue I don't know. I guess you've done like that many times without problem, or does it get slow every time you do like that? I tried it but couldn't see any difference myself...
It doesn't happen every time, just some of the time. Unfortunately I don't know how to reproduce the problem. Maybe it happens at shallow locations too but it's just not noticeable there. I will let you know if I find something.
|
|
|
Logged
|
|
|
|
DarkBeam
Global Moderator
Fractal Senior
Posts: 2512
Fragments of the fractal -like the tip of it
|
|
« Reply #7 on: February 25, 2017, 04:24:09 PM » |
|
|
|
|
Logged
|
No sweat, guardian of wisdom!
|
|
|
Dinkydau
|
|
« Reply #8 on: March 14, 2017, 02:15:41 AM » |
|
You're right. "Auto approximation terms" can be disabled and the number of terms can be set. I may have forgotten that when I attempted the large render.
Coming back to mention this wasn't it after all. It's also hard to say whether there's progress or not because the reference count is unreadable due to there being too much text in the field (probably because of the 4-digit exponent in the depth). I'm currently doing a render. The first reference was computed and all the pixels were computed, some of them glitches. It's stuck somewhere between that and where it would start using the next reference to solve glitches. I just noticed the CPU usage drops to close to, but not quite, 0% (0,07-0,12% and I have 6 cores and 12 threads) when the program is minimized.
|
|
« Last Edit: March 14, 2017, 02:38:09 AM by Dinkydau »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #9 on: March 14, 2017, 05:07:24 PM » |
|
Coming back to mention this wasn't it after all. It's also hard to say whether there's progress or not because the reference count is unreadable due to there being too much text in the field (probably because of the 4-digit exponent in the depth).
I'm currently doing a render. The first reference was computed and all the pixels were computed, some of them glitches. It's stuck somewhere between that and where it would start using the next reference to solve glitches. I just noticed the CPU usage drops to close to, but not quite, 0% (0,07-0,12% and I have 6 cores and 12 threads) when the program is minimized.
Oh, I think there is a problem with saving jpeg when the window is minimized, can it be that? Someone wrote that to me long ago but I haven't remembered having a look at it...
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #10 on: March 14, 2017, 09:25:01 PM » |
|
That seems unlikely to me because I'm not trying to save a JPEG - it's a problem that affects the rendering - but who knows the problems may be related. I also tried Claude's build and it crashes at this stage. I didn't have enough RAM to keep both processes so I'm now trying it again with the normal kalles fraktaler 2.11.1.
I have attached the parameter file that I'm trying to make a render of. This is what I do: 1. Open kalles fraktaler; 2. Set the window to 1000×1000; 3. Open Iterations window and set Bailout=2, uncheck both "Approximation low tolerance" and "Auto approximation terms", set Approximation terms to 66, click OK; 4. Open Set image size window and set Width to 23160 (which automatically sets Height to 23160 as well); 5. Wait for the render to finish. I might minimize the window a few times.
|
|
« Last Edit: March 14, 2017, 09:36:29 PM by Dinkydau »
|
Logged
|
|
|
|
|
Dinkydau
|
|
« Reply #12 on: March 16, 2017, 03:05:07 AM » |
|
Bitmap size should not be the issue on windows I think. 23160×23160 is just below the maximum of 2^29 pixels (although I can't easily find a source that confirms this). It's a resolution that works in Mandel Machine at least. I have more than enough RAM. Cache - I don't know. I'm currently rendering 4 tiles of 16000×16000 and that seems to work fine. Maybe I should upload a debug build without symbols having been stripped - it's much bigger but if you know how to use a debugger it could help find the problem?
I haven't used one before.
|
|
|
Logged
|
|
|
|
|