FOTD 22-07-02 (Seahorse Minibrot [7])
FOTD -- July 22, 2002 (Rating 7) Fractal visionaries and enthusiasts: For today's glorious fractal we return to perhaps the richest area in all of fractaldom -- Seahorse Valley of the Mandelbrot set. Yes, I realize that this area has been explored almost ad infinitum, but it holds so many promising places that I just can't let it alone. Today's image is one of a midget located deep in a seahorse-tail spiral on the west side of the valley. The nature of the location is made abundantly clear by the tightly-wound spirals around the midget. I have written the mathtolerance entry into the parameter file because the magnitude of the image is so great that the program has a tendency to flip into arbitrary math mode when calculating the image, with a big slow-down but no image improvement. Curiously, the outside=tdis setting is the cause of the 1-1/2 hour render time. When calculated with outside=iter, the image renders in 4 minutes. I have no idea why the <tdis> option should take over 20 times as long to render as the normal <iter> method. I named the image "Seahorse Minibrot" as more of a description than a title. Since I kind of like the amber coloring, I rated the image at an above average 7. The 90-minute render time of the parameter file is quite slow. Some may enjoy watching the image majestically paint itself onto the screen; most will decide to download the completed GIF image from Paul's site at: <http://home.att.net/~Paul.N.Lee/FotD/FotD.html> or from Scott's site at: <http://sdboyd.dyndns.org/~sdboyd/fotd/index.html> The fractal weather Sunday here at Fractal Central was quite warm and muggy, which is typical for this time of year. The temperature of 90F 32C kept the fractal cats typically lazy until supper time, when they suddenly remembered they were hungry and began crying to be fed. One certain thing however is that the rest of this Monday will not be lazy, at least for me, burdened as I am with a pile of work to finish. So as I begin the task, take care, and know truth. Jim Muth jamth@mindspring.com START PARAMETER FILE======================================= Seahorse_Minibrot { ; time=1:30:55.21--SF5 on a P200 reset=2002 type=mandel passes=1 mathtolerance=/1 center-mag=-0.75285852351178220/+0.043143142026493\ 12/1.333782e+013/1.0005 params=0/0 float=y inside=0 maxiter=36000 bailout=6 periodicity=10 outside=tdis colors=000m5zu8zr7zp5zm5zl4zj4zg2we2uc1ta1r`0pY0mW\ 0lT0jR0iQ0gN0dM0cJ0aI0`G0ZD0WC0VA0T80R50N70Q80RA0T\ A0VC2WD5YDA`FCaGFcIJdJMeLPgLRiJTgITgGTeGTeFTdDTdDT\ cCTcAVaAVaAV`8V`7VZ7VZ5VY4VY2WW2WW1WV0WV0WT0WT0WR0\ WR0YT2ZT5ZT8`TAaTDaVGcVJcVMdVPeVReWVgWYiW`iWcjWcoY\ dlWejWgiWigWjeVldVmcVmaVo`VpZTrYTtVTuTTwRRxQRxPRzN\ RzMRzLQzJQzIQzGQzFQzCLrAGjACc87W72P50700C10I40N70T\ A0ZD0cG0iJ0oN0uQ0zT0zW0xZ0p`0ja0cc1Wd2Qe5Jh7Ck87mA\ 0pA0tA0sC0sD0tD0qF0oG1nG2kI4hJ5gJ7eL8cMAcMAaNA`PC`\ PDZQFYRGYRIWTJVVLVVMTWNRYPRYQQZRP`TNZRP`RPaRQcRQdQ\ ReQReQTgQTiPVjPVlPWlPWmPYoNYpNZrNZrN`tM`uMawMaxMcx\ MczLdzLdzLezLezJgzJgzJizJizJizLgzMezMezNdxPduPcrQc\ oRalRaiT`eV`cVZ`WZYYYVYYRZWP`WM`VJaVGcTDcTAdR8eR5e\ Q2gQ0iP0iP0jN0iM0jN0lP0lQ0mQ0oR0oT2pT5pV8rWAtWDtYG\ uZJuZMw`PxaRxcVzcYzd`zeczeezgizilziozjrzluzpxzuzzl\ xzduzYtzQpzJozCla5zd5zi5z } END PARAMETER FILE=========================================
On Monday 22 July 2002 08:19, Jim Muth wrote:
Curiously, the outside=tdis setting is the cause of the 1-1/2 hour render time. When calculated with outside=iter, the image renders in 4 minutes. I have no idea why the <tdis> option should take over 20 times as long to render as the normal <iter> method.
When I read Jim's email today, I thought my computer (A 900 Mhz Athalon) would take *at least* 30 - 45 minutes to render the FOTD. I don't compare the render-time every day, but usually my computer takes about 1/3 to 1/2 the time to render the FOTD as does Jim's P200. To my surprise, it took only 8:44.56 today! I re-loaded the image into Xfractint and compared the .par with what was in his email. Everything was the same. I'd like to hear from somebody with a Windows-based machine, at a comparable speed, to find out how long it took them to render today's FOTD. Could the difference be because Xfractint defaults to floating-point mode? P.N.L. - how long did it take your computer to render it? (As of 11:52, Paul still doesn't have the FOTD posted.) Until later, Scott Boyd
----- Original Message ----- From: "Scott D. Boyd" <sdboyd56@swbell.net> To: <fractint@mailman.xmission.com> Sent: Monday, July 22, 2002 9:53 AM Subject: Re: [Fractint] FOTD 22-07-02 (Seahorse Minibrot [7])
On Monday 22 July 2002 08:19, Jim Muth wrote:
Curiously, the outside=tdis setting is the cause of the 1-1/2 hour render time. When calculated with outside=iter, the image renders in 4 minutes. I have no idea why the <tdis> option should take over 20 times as long to render as the normal <iter> method.
When I read Jim's email today, I thought my computer (A 900 Mhz Athalon) would take *at least* 30 - 45 minutes to render the FOTD. I don't compare the render-time every day, but usually my computer takes about 1/3 to 1/2 the time to render the FOTD as does Jim's P200. To my surprise, it took only 8:44.56 today!
I re-loaded the image into Xfractint and compared the .par with what was in his email. Everything was the same. I'd like to hear from somebody with a Windows-based machine, at a comparable speed, to find out how long it took them to render today's FOTD.
42.5 minutes on my 750 MHz Pentium III, running a DOS box in WIN Me, and drawing 800 x 600. John W.
----- Original Message ----- From: "John Wilson" <juanw@telus.net> To: <fractint@mailman.xmission.com> Sent: Monday, July 22, 2002 4:01 PM Subject: Re: [Fractint] FOTD 22-07-02 (Seahorse Minibrot [7])
----- Original Message ----- From: "Scott D. Boyd" <sdboyd56@swbell.net> To: <fractint@mailman.xmission.com> Sent: Monday, July 22, 2002 9:53 AM Subject: Re: [Fractint] FOTD 22-07-02 (Seahorse Minibrot [7])
On Monday 22 July 2002 08:19, Jim Muth wrote:
Curiously, the outside=tdis setting is the cause of the 1-1/2 hour render time. When calculated with outside=iter, the image renders in 4 minutes. I have no idea why the <tdis> option should take over 20 times as long to render as the normal <iter> method.
When I read Jim's email today, I thought my computer (A 900 Mhz Athalon) would take *at least* 30 - 45 minutes to render the FOTD. I don't
compare the
render-time every day, but usually my computer takes about 1/3 to 1/2 the time to render the FOTD as does Jim's P200. To my surprise, it took only 8:44.56 today!
I re-loaded the image into Xfractint and compared the .par with what was in his email. Everything was the same. I'd like to hear from somebody with a Windows-based machine, at a comparable speed, to find out how long it took them to render today's FOTD.
42.5 minutes on my 750 MHz Pentium III, running a DOS box in WIN Me, and drawing 800 x 600.
John W.
33 minutes on a 733 pentium III, running a Dos box on WIN XP at 640 X 480 Melton V.
On Monday 22 July 2002 11:53, Scott D. Boyd wrote:
So far, I've had two replies: 42.5 minutes on a 750 Mhz P3, in a DOS box on Win ME at 800 x 600 33 minutes on a 733 Mhz P3, in a DOS box on WIN XP at 640 X 480 PNL's render time was 33:50 (I checked his Website). Jonathan - Does the nasm assembler support in Xfractint 20.2.04 really make that much of a speed improvement, or is it something else?
When I read Jim's email today, I thought my computer (A 900 Mhz Athalon) would take *at least* 30 - 45 minutes to render the FOTD. I don't compare the render-time every day, but usually my computer takes about 1/3 to 1/2 the time to render the FOTD as does Jim's P200. To my surprise, it took only 8:44.56 today!
I re-loaded the image into Xfractint and compared the .par with what was in his email. Everything was the same. I'd like to hear from somebody with a Windows-based machine, at a comparable speed, to find out how long it took them to render today's FOTD. Could the difference be because Xfractint defaults to floating-point mode?
Scott
Scott D. Boyd wrote:
PNL's render time was 33:50 (I checked his Website).
Curious how you got that value, since FractInt said something different on my PC. P.N.L. -------------------------------------------------------------- http://www.fractalus.com/cgi-bin/theway?ring=fractals&id=43&go
On Tuesday 23 July 2002 01:15, you wrote:
Scott D. Boyd wrote:
PNL's render time was 33:50 (I checked his Website).
Curious how you got that value, since FractInt said something different on my PC.
I had downloaded your image, and then loaded the image into Xfractint. Then hit the Tab key to view the "info about image". Did I read it wrong? Was it 33.50 seconds? How long did it take according to Fractint? Until later, Scott
Scott D. Boyd wrote:
I had downloaded your image, and then loaded the image into Xfractint. Then hit the Tab key to view the "info about image". Did I read it wrong? Was it 33.50 seconds? How long did it take according to Fractint?
I checked the render time just after it was rendered earlier yesterday, just before uploading to the website. It was 00:30:55 then. I just reloaded the GIF image into FractInt and it says the same thing. If your copy of my posted image says something different, then there is a bug in one of our versions of FractInt. Did a very quick glance through LOADFILE.c and GIFVIEW.c looking for the GIF Extension Block layout. Wanted to verify the actual hexadecimal data of the file to see what was really there. But got lost browsing around the code. How about someone giving a displacement and length for the "time" fields from the beginning of the extension block. Sincerely, P.N.L. -------------------------------------------------------------- http://www.fractalus.com/cgi-bin/theway?ring=fractals&id=43&go
42.5 minutes on a 750 Mhz P3, in a DOS box on Win ME at 800 x 600 33 minutes on a 733 Mhz P3, in a DOS box on WIN XP at 640 X 480 PNL's render time was 33:50 (I checked his Website).
24:11.47 on a Athlon 1800+ (1533 Mhz) in DOS at 800 x 600 Mary
Scott D. Boyd wrote:
So far, I've had two replies: 42.5 minutes on a 750 Mhz P3, in a DOS box on Win ME at 800 x 600 33 minutes on a 733 Mhz P3, in a DOS box on WIN XP at 640 X 480 PNL's render time was 33:50 (I checked his Website).
Jonathan - Does the nasm assembler support in Xfractint 20.2.04 really make that much of a speed improvement, or is it something else?
Xfractint is running 32-bit code compiled with an optimizing C compiler. Fractint is running 16-bit code compiled with an old MS C compiler. The assembly code is not being used for the same reason it isn't running in Fractint with this PAR (outside=tdis). Jonathan
----- Original Message ----- From: "Scott D. Boyd" <sdboyd56@swbell.net> Sent: Monday, July 22, 2002 10:43 PM Subject: Re: [Fractint] FOTD 22-07-02 (Seahorse Minibrot [7])
On Monday 22 July 2002 11:53, Scott D. Boyd wrote:
So far, I've had two replies: 42.5 minutes on a 750 Mhz P3, in a DOS box on Win ME at 800 x 600 33 minutes on a 733 Mhz P3, in a DOS box on WIN XP at 640 X 480 PNL's render time was 33:50 (I checked his Website). Here's another, (if you are still collecting);
31 minutes on a 750 Mhz P3, in a DOS box on Win ME at 640 x 480. (the same machine that took 42.5 minutes to render an 800 x 600) John W.
Scott D. Boyd wrote:
I'd like to hear from somebody with a Windows-based machine.... P.N.L. - how long did it take your computer to render it?
Render Time = 00:30:55 with VIDEO=SF5 (640x480 @ 256) in full screen starting from the Run command. While ten other applications were active, including being connected to the Internet. Windows-98 (2nd-ed. 4.10.2222 A) DELL Dimension XPS T700r Pentium-III 700-MHz 128-MB DIAMOND Viper V770D Ultra NVIDIA 32-MB DELL Trinitron 21" monitor Sincerely, P.N.L. -------------------------------------------------------------- http://www.fractalus.com/cgi-bin/theway?ring=fractals&id=43&go
Jim Muth wrote:
Curiously, the outside=tdis setting is the cause of the 1-1/2 hour render time. When calculated with outside=iter, the image renders in 4 minutes. I have no idea why the <tdis> option should take over 20 times as long to render as the normal <iter> method.
That is because the outside=tdis (and fmod) option causes Fractint to switch to the C code, instead of using the assembly code. Jonathan
participants (7)
-
Jim Muth -
John Wilson -
Jonathan Osuch -
M J Benkers -
Melton Voelkel -
Paul N. Lee -
Scott D. Boyd