Bug/pathological case

  • 11 Replies
  • 103 Views

0 Members and 1 Guest are viewing this topic.

Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« on: August 01, 2020, 06:49:08 PM »
Code: [Select]
hist_julia03 {
fractal:
  title="hist_julia03" width=960 height=540 layers=1
  credits="Owner;8/1/2020;Paul Derbyshire;5/10/2012" antialiasing=yes
layer:
  caption="Background" opacity=100 method=linear
mapping:
  center=0/0 magn=1.3
formula:
  maxiter=10000000 filename="Standard.ufm" entry="FastJulia"
  p_seed=-0.390540456681171/0.586787836352608 p_bailout=4.0
inside:
  transfer=none
outside:
  density=0.2 transfer=log filename="Standard.ucl" entry="Smooth"
  p_power=2/0 p_bailout=4
gradient:
  smooth=yes index=0 color=15459814 index=99 color=2726861 index=200
  color=76 index=300 color=66047
opacity:
  smooth=no index=0 opacity=255
}

In a fractal window at 960x540 with AA on (so, actually calculating 1920x1080 samples) this renders in about 10 seconds on my machine.

A disk render at 19200x10800 is taking way, way longer than 1000 seconds (under 20 minutes). It's at about one third after two hours.

Nearly every fractal I render behaves as one would expect: a 960x540 AA windowed render takes about 1% as long as a 19200x10800 disk render. This one is exceptional.

Does anyone have any idea why?

Linkback: https://fractalforums.org/ultrafractal/59/bugpathological-case/3691/

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #1 on: August 01, 2020, 09:32:59 PM »
Code: [Select]
hist_julia03 {
fractal:
  title="hist_julia03" width=960 height=540 layers=1
  credits="Owner;8/1/2020;Paul Derbyshire;5/10/2012" antialiasing=yes
layer:
  caption="Background" opacity=100 method=linear
mapping:
  center=0/0 magn=1.3
formula:
  maxiter=10000000 filename="Standard.ufm" entry="FastJulia"
  p_seed=-0.390540456681171/0.586787836352608 p_bailout=4.0
inside:
  transfer=none
outside:
  density=0.2 transfer=log filename="Standard.ucl" entry="Smooth"
  p_power=2/0 p_bailout=4
gradient:
  smooth=yes index=0 color=15459814 index=99 color=2726861 index=200
  color=76 index=300 color=66047
opacity:
  smooth=no index=0 opacity=255
}

In a fractal window at 960x540 with AA on (so, actually calculating 1920x1080 samples) this renders in about 10 seconds on my machine.

A disk render at 19200x10800 is taking way, way longer than 1000 seconds (under 20 minutes). It's at about one third after two hours.

Nearly every fractal I render behaves as one would expect: a 960x540 AA windowed render takes about 1% as long as a 19200x10800 disk render. This one is exceptional.

Does anyone have any idea why?
Maybe a clue is that if you turn off periodicity checking behavior is again as expected.
At 1920X1080 (no AA) it renders for me in 0.46s with normal periodicity checking but in over 7mins without periodicity checking.

Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« Reply #2 on: August 01, 2020, 11:03:48 PM »
If disk rendering turned off periodicity checking, all of them would be affected similarly -- all with trapped points, anyway. But that's not what I find. Most Mandelbrot/Julia fractals with trapped points take almost exactly 100x as long disk rendered at 19200x10800 as window rendered at 1920x1080 (or equivalent). So something is causing special case/pathological behavior with this specific Julia set.

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #3 on: August 02, 2020, 02:08:18 AM »
Periodicity testing is not turned off when rendering to disk.
Rendering time does not generally scale linearly with number of pixels, as at higher resolution some of the "added" pixels require much higher iteration number (including periodicity checking tricks).
It is a property of this Julia set that a lot of the extra pixels need many more iterations. You can check by gradually increasing size and observing "Max. iterations". Not sure how to make this argument more precise, but I suspect the fractal dimension of this Julia set is very high.

I've seen this behavior (10X size disk render takes much much longer than 100X small render) before on occasion.

One possible source of this (not in this case) can be that if you made some animation with the fractal, then just want to do a single image render and motion "blurring" was turned on in the animation setting, only one thread will be used to render (a bug I reported a while ago, should get fixed when 6.03 comes out finally).

Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« Reply #4 on: August 02, 2020, 05:25:08 AM »
Quote
Rendering time does not generally scale linearly with number of pixels

That's not been my experience, aside from if the larger render is on the other side of a breakpoint for using a higher precision data type.

Until now, anyway.

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #5 on: August 02, 2020, 05:41:38 AM »
That's not been my experience, aside from if the larger render is on the other side of a breakpoint for using a higher precision data type.

Until now, anyway.
But still strictly true I think, though the effect may be too small to observe in many cases; this is an exception.
Rather than consider it an obstacle to make hidef pictures, maybe it could be used in some other way.

E.g., take a pixel (a square let's say) and keep subdividing it with \( n \) pixels. How does the render time scale with \( n \)? I conjecture \( O(n^\mu) \) with \( \mu \geq 1 \), with \( \mu \) related to the fractal dimension, and \( \mu=1 \) for non-fractals. We'd have to define "render time" more precisely here, taking into account period detection. Could be some new coloring method by \( \mu \)?

What's special about this Julia set? A Feigenbaum point? Very hard to render the location in the M-set.

I think Julia set of 1/4 behaves similarly, to break it down to the simplest case.


Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« Reply #6 on: August 02, 2020, 06:02:02 AM »
Nothing of the sort happened with c = 1/4. Normal scaling there, or close to.

The only thing unusual about this one is that it has a Siegel disk. But I've rendered others before (notably, in the triskelion formula) without odd scaling behavior becoming apparent ...

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #7 on: August 02, 2020, 06:12:08 AM »
Nothing of the sort happened with c = 1/4. Normal scaling there, or close to.
I just tried and get a different result. 640X360 renders in .05s at 1e9 iterations and normal period checking, at 19200X10800 it takes,..., long time..., estimated time is 10min and ETA still goes up by 10 seconds per second,... I'll run it overnight and let you know tomorrow.

Can you try with these settings or tell me how exactly to reproduce your result?




Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #8 on: August 02, 2020, 07:00:10 PM »
It finished, but UF does not report runtime so all I know is less than 8 hrs.

Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« Reply #9 on: August 02, 2020, 07:45:48 PM »
Well, I'm pretty sure I had that one complete in 10 minutes or so. Looks like your copy acts flaky on one that mine doesn't!

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 2191
« Reply #10 on: August 02, 2020, 08:21:52 PM »
Well, I'm pretty sure I had that one complete in 10 minutes or so. Looks like your copy acts flaky on one that mine doesn't!
I ran 6.02, and you? On my 4.03 indeed it runs in less than time to make a coffee.
Your original parameter file crashes 4.03. (??)
I'll post a bug report to the UF forum.
Code: [Select]
dot25 {
fractal:
  title="dot25" width=640 height=360 layers=1
  credits=""
layer:
  caption="Background" opacity=100 method=multipass
mapping:
  center=0/0 magn=1.3
formula:
  maxiter=1000000000 filename="Standard.ufm" entry="FastJulia"
  p_seed=.25/0 p_bailout=4.0
inside:
  transfer=none
outside:
  density=0.2 transfer=log filename="Standard.ucl" entry="Smooth"
  p_power=2/0 p_bailout=4
gradient:
  smooth=yes index=0 color=15459814 index=99 color=2726861 index=200
  color=76 index=300 color=66047
opacity:
  smooth=no index=0 opacity=255
}

Offline pauldelbrot

  • *
  • 3f
  • ******
  • Posts: 2061
« Reply #11 on: August 02, 2020, 09:25:35 PM »
6.01 here.