Re: [Fractint] Fastest Fractint Setup
Comments in line.
Vortex Swirling wrote:/
I have been wondering what makes for a fast Fractint setup nowadays?/
A real fast PC running straight DOS. :-)
But I use two machines for the rendering of Jim's FOTDs: • A 10-year old P3 running Win-98. • An 7-year old P4 running Win-XP. Out of necessity, I built a new machine a few months ago. The processor is an Intel I7 920 2.66Ghz. It has 4 physical cores and 8 logical cores.
/>
What I would like for the group to do is pick one of the FOTD's which is computationally intensive. Then those who'd like to participate generate said fractal and report times with a system description./
The recent "Seahorse Valley-12" has a rather lengthy calc-time. We already know how long it took on Jim's machine. I tried this on both setups. On the DosBox setup (with cycles=max) it was taking north of 3 hours so I evoked the mercy rule and just stopped it. This was at 320x240.
On Ubuntu 64 running xfractint 20.04.9 I completed in around 18 minutes. It would probably have been a bit faster but I kept messing around during the run. The screen size was the default of 800x600 so this is higher than Jim's 640x480. I check the Performance Monitor which running this and it was indeed using all 8 processors. Well that settles it, I will use xfractint. xfractint needs a little work but, if set up right it works. I can't seem to walk around directories without crashing so I make sure that the pars and formula I am working with are in the pars and formulas directories. The -geometry parameter doesn't seem to work and it is difficult to resize the screen and know what its going to be. I can't change maps. I can't do disk video. Sound doesn't work. Color cycling is not possible the way xfractint is written. However, it might be possible to load the gif in a seperate OpenGL application and, given the map as a parameter, be able to do the color cycle. The OpenGL application, "Antiprism", where I have done programming work can do it. (I didn't code the color cycling but the code for it was open source and free to be added in).
Too bad FractInt will not run on my double QuadCore 64-bit 16-MB RAM machine. Up until a couple of months ago, it rated the highest in speed doing similar fractal rendering tests in two other email lists. /
Also any tweaks or suggested improvements in system setup are welcome./
I can make a few when it comes to the Windows OS. There are so many things that get established a certain way with the default settings. And they really slow machines down. After months, I am still running Vista 64 with most of the defaults. This are so fast I haven't had to change anything. If it were to shave a minute off xfractint's time I probably wouldn't find it worth it. If it halved the time it would be different story.
Roger
Roger,
xfractint needs a little work but, if set up right it works. I can't seem to walk around directories without crashing so I make sure that the pars and formula I am working with are in the pars and formulas directories.
I have a fix for this. The problem is tied to hard coded array sizes. I'll clean this up before I release my next patch. Jonathan
Hi Jonathan,
xfractint needs a little work but, if set up right it works. I can't seem to walk around directories without crashing so I make sure that the pars and formula I am working with are in the pars and formulas directories.
I have a fix for this. The problem is tied to hard coded array sizes. I'll clean this up before I release my next patch.
Jonathan
This would probably be better in the fractdev group but I don't want to join that for just one post! I was wondering what you thought of the idea of using OpenGL for xfractint? It is readily compiled under Cygwin even under Vista 64. Likewise, it is readily compiled under most common Linux distributions. Quite nicely, there is a solution for palette rotation in OpenGL which works in both environments (I've seen it work). Of course the building of the traditional menus might be some work if they wanted to be kept. But all keystrokes can be captured and fractint usage would be able to be as it always has been. Roger
Roger Kaufman wrote:
Hi Jonathan,
xfractint needs a little work but, if set up right it works. I can't seem to walk around directories without crashing so I make sure that the pars and formula I am working with are in the pars and formulas directories.
I have a fix for this. The problem is tied to hard coded array sizes. I'll clean this up before I release my next patch.
Jonathan
This would probably be better in the fractdev group but I don't want to join that for just one post!
I was wondering what you thought of the idea of using OpenGL for xfractint? It is readily compiled under Cygwin even under Vista 64. Likewise, it is readily compiled under most common Linux distributions.
Quite nicely, there is a solution for palette rotation in OpenGL which works in both environments (I've seen it work).
Of course the building of the traditional menus might be some work if they wanted to be kept. But all keystrokes can be captured and fractint usage would be able to be as it always has been.
That's a great idea! Although I (using an older laptop on which OpenGL runs like a dead snail) would want a non-OpenGL fallback ... but I don't do much color cycling, anyway. -- David gnome@hawaii.rr.com authenticity, honesty, community
Roger,
I was wondering what you thought of the idea of using OpenGL for xfractint? It is readily compiled under Cygwin even under Vista 64. Likewise, it is readily compiled under most common Linux distributions.
Yes, it has been given some thought. It is a reasonable idea. I don't know enough of the details to make a decision at this time. If I could figure out how to force a refresh with X11, then color cycling would not be an issue. Open up the palette editor, change the color map, and then close the palette editor. The area under the palette editor will have the new color map displayed. So, it *can* be done in X11.
Quite nicely, there is a solution for palette rotation in OpenGL which works in both environments (I've seen it work).
Of course the building of the traditional menus might be some work if they wanted to be kept. But all keystrokes can be captured and fractint usage would be able to be as it always has been.
One problem is that we need to have a stable interface because I don't want to have to rewrite the code every year or so to keep up with changes to the graphics engine. I ran into this when I was working with the Allegro port of Rich's code. Jonathan
participants (4)
-
david -
Jonathan Osuch -
Roger Kaufman -
Vortex Swirling