Welcome to Fractal Forums

Looks very impressive for a first release, nice work! Did you write the optimised iteration kernels yourself using intrinsics, or is this via some JIT compiler?

Just started playing, LOVE  :joy: the load image to build a palette function.
You can use this to grab the colours from any JPG or PNG to build your palette.
I've used it below to grab a palette from a multi layered Kalles Fraktaler image (14 layers!)

Any chance for a 32bit version?

Can I compile this on Linux ... ?

The comment: the image often scrambles on panning (but a recompute fixes it.)

The question: Is there anything I can do to get the details filled in on deeper zooms? I've tried increasing the iterations and the precision and the scale, but beyond about magnification 100 the denser areas are often missing and previously filled-in areas will go flat on zooming in or out -- though zooming in further will sometimes fill them in. Do I just have to wait for the glitch-solving functionality?

Is this a collaboration between Michael Condron, Bruce Dawson, Kevin Martin and Karl Runmo? The program feels to be based on ultra fractal, is that true?

Tick tock renders in 1,5 seconds.

Mandel Machine v1.0.1 is available (http://web.t-online.hu/kbotond/mandelmachine/ (http://web.t-online.hu/kbotond/mandelmachine/)). Changes:

• FIXED: Application hangs when increasing iteration limit with histogram coloring

Unfortunately, with the new version I'm getting  a different kind of hang quite frequently. Usually it happens when panning, but occasionally when zooming; the rendering freezes showing the status message "Initializing series approximation." In this condition it is still possible to save the definition file and carry on after restarting the program and loading the saved parameters.

Can you post the parameter file you saved after the program froze?

I doubt that it is only because of the use of assembler that made your Mandel Machine more than 6 times faster than mine Kalles Fraktaler.
Are you able to skip more pixels with Series Approximation?

Or did you find other ways to optimize the render?

Recently I loaded the my location Tick Tock from Kalles' collection of locations on my computer with 32 cores.

I guess you split up the image and do serial approximation on every parts to find more pixels to skip?

Sure.

Series approximation in MM is based on 5 coefficient series instead of 3 suggested by Kevin Martin's original article. The first 4 series are used to approximate the deltas, the fifth is for finding the maximum skippable iterations: when any of the first four terms in equation (2) becomes only one magnitude or less greater than the fifth term, we cannot skip more iterations. (There are some additional conditions to check, but this is the main principle.) I also experimented with 6 coefficient series, and it produced only insignificant gains, but made the initialization of series approximation more time consuming.

ellarien, I couldn't make the program hang at the location you sent. Could you reproduce it and describe the exact circumstances? A screen capture showing the Statistics and History panels would also help.

So how does the formula for D[n+1] and E[n+1] look like?

I just loaded the location, zoomed out a few times, then panned twice (while the screen was exhibiting a large 'glitched' area of flat colour) and it froze on the second time. Screen-snips attached. (768-pixel high screen, so I had to do it in pieces.)

It happened just the same when I started clean and zoomed in until the perturbation theory started to fail, then tried to pan; after a bit of experimentation I think it only happens when panning after a glitch has appeared, and not always the first time -- sometimes it takes two or three tries.

Interestingly, it seems to be only the computation that hangs -- everything else can be interacted with, including dragging the partial image around with a right-click and moving the scroll bars to look at the history and statistics.

D_n+1 = 2X_nD_n + 2A_nC_n + B_n²
E_n+1 = 2X_nE_n + 2A_nD_n + 2B_nC_n

Finally rendered a somewhat bigger picture without crashes or freezes:

D_n+1 = 2X_nD_n + 2A_nC_n + B_n²
E_n+1 = 2X_nE_n + 2A_nD_n + 2B_nC_n

When rendering large images the program almost doesn't respond. It responds normally again when the render is finished.

Currently the center pixel is the reference. All pixels that would escape later get the same iteration count as the center, so large blobs can appear if the image is not centered on a minibrot or Misiurewicz point. This won't be a problem as soon as automatic blob correction is ready. Until then you can manually enter a new reference by right-clicking inside a blob, preferably in its center.

Could you post the coordinates for your test location? Does the program lock up with both perturbation and pixel guessing off?

How do you decide which pixels to update?

All pixels that would escape later get the same iteration count as the center, so large blobs can appear...

As Botond Kósa write - all pixels in the blob get the same iteration count.

As Botond Kósa write - all pixels in the blob get the same iteration count.
But - But!!!!!
This is only a special case, when only the main Mandelbrot have influence, i.e. no minibrot.
If your zoom path pass close to one (or several...) minibrot there are many variations:
* The blobs can contain a couple of iteration values, randomly spread through the blob
* The blobs can contain an iteration count value that is lower than other ares in the same view
* The blobs can have gradient content
* The blobs can have structured pattern
* etc etc etc

Botond Kósa I have a question for you - do you use only double datatype for calculating the pixels? It seems you use more precision than what is possible with the double datatype, since Mandel Machine get fewer glitches than Kalles Fraktaler when one reference only is used...

Kalle, when "Use long double always" is turned on in KFR, do you also store the reference orbit in long double precision, or do you use it for the calculations only?

Kalle & hapf, could you post some locations where you found blobs that cannot be corrected by using additional references? It would be extremely helpful.

Kalle & hapf, could you post some locations where you found blobs that cannot be corrected by using additional references? It would be extremely helpful.

Update: A clean version of this region. 3 references used.

Nice, and I know how you did it ;) (because I done it too here http://www.fractalforums.com/movies-showcase-(rate-my-movie)/flake-second-attempt/ (http://www.fractalforums.com/movies-showcase-(rate-my-movie)/flake-second-attempt/))
If you begin with a point not in the center of this view - then the glitches wont contain the structure and can easier solved with just a few extra references :)
But to automatically decide in a program is impossible I think, unless someone find a mathematically way to certainly identify glitches.

KF latest version is able to skip 23653 iterations in this view (min 29674), how many can you skip :)

I checked for a test image and average iterations were ~30500. Skipped 8358. It depends how much error you allow.
23653 looks impossible for 3 terms. What's your max error and average error here? Do you use 5 terms instead of 3?
I looked into more than 3 terms but found it not helpful. Maybe I overlooked something and should retest it.

Yes, it is using 5 terms and allowing 0.1% error.
The 4th and 5th terms of Series Approximation get intermediates with extreme exponents, perhaps not even possible to express in long double. I need to use my floatexp class that takes an integer as exponent and double as mantissa to calculate this.

But with the previous version, using 3 terms and only allowing 0.0001% error, and using double datatype only, I could still skip 15769 iterations, so 8358 sounds very low.

Are you testing the whole picture?

No, only the 4 pixels in the corners.
I thought they would give the most errors since they are farthest away from the reference.

No, only the 4 pixels in the corners.
I thought they would give the most errors since they are farthest away from the reference.

I kind of expected this situation when the perturbation method was first described: you have a new chaotic system approximating another chaotic system, and until there's a lot of mathematical analysis and heuristic half-fixes etc, there will be random spurious problems.
I've resisted asking until now: is this really worth the headache and uncertainty? What exactly is wrong with the existing (trustworthy!) methods, that do not require any kind of checking to make sure the result is correct? If it's purely a matter of computation, then surely GPUs are up to the task...

The error does not primarily depend on the pixel's distance from the reference. It depends on the pixel's orbit's distance from the reference orbit. If a pixel is in a dense region, the likelihood of an error is higher than for a pixel that is inside a slowly changing gradient. I found that testing the 4 corners is not always enough. If the corners are in sparse regions you could get visible error in the dense parts of the image. The more pixels are tested, the less is the chance of having all of them in sparse regions.
Mandel Machine tests for the 4 corners and the 4 edge midpoints, for performance reasons. Ideally all edge pixels should be tested.

GPUs are limited to double precision. Rather restrictive for zoom depths. There is nothing wrong with older methods if you want to go deep and don't mind waiting a couple of hunded times or more longer.  ;D

I can't understand why you focus on the 8.5 seconds or 2 seconds and totally refuse to account for the tons of human inspection time (likely on the order of minutes) that something didn't go wrong. And what if you miss a bit that looks a little different? Don't even get me started with apples-to-oranges (completely different programs) comparisons...

Hey man, have your fun of course, I just don't see this as being terribly practical if you can't have faith in the output, no matter how few nanoseconds or whatever the render took...

"A million miles an hour in the wrong direction helps nobody" - American saying?

almost always

I guess you're still missing my point about how "almost" is actually really a problem. "It's a million trillion times faster! Except when you notice something is wrong and have to fiddle and make re-renders, so just check every frame of your animation by hand!" Seriously... if that's acceptable to you then fine, but I am just constantly surprised at how that is regarded as a step forward...

Anyway sorry for the skepticism here, but as as a developer of commercial software, I can't imagine myself ever saying to users "yeahhhh well sometimes the output can be bogus in subtle ways, just always check everything with a bunch of test renders and if it's wrong here's a bunch of parameters to fiddle with..."

What is at least completely objective is saying, that you shouldn't compare apples and oranges, i.e. different programs (which can be highly optimised or not) and one which consistently produces the right output, the other which maybe-sometimes-usually-doesn't-need-too-much-checking-to-see-if-it-was-right, etc...

My two basic logical objections are:

1. It is disingenuous to talk about 2 seconds render if you always (unless you're into blind faith) have to do a normal-speed test render to make sure the 2 second one didn't go wrong (and even then you might just not have looked long enough and miss it, ending up with a bogus render).

2. Throwing out hard numbers like "weeks" without specifying what program (yes yes, UltraFractal is terribly slow, hooray you successfully compared against an ancient program which at least always gives the right result), and assuming that no better can be done without resorting to brutal approximations that only work some of the time. It's just a completely different thing, sort of like trying to compare an exact solution to the travelling salesman problem running on a 386, to some low accuracy statistical approximation on the GPU that you can't really have any faith in at the end.

I am comparing with fractal extreme of course, the fastest 'normal' program there is :)

I am just constantly surprised at how that is regarded as a step forward...

Yes, I understand of course that GPUs don't do higher than FP64 internally (and that at greatly reduced speed compared to FP32), but as with CPUs a GPU is Turing complete and can surely do any higher precision computation the CPU can do.

I don't think there are GPU solutions for arbitrary precision with lots of bits that outperform a multi core CPU, but I'm happy to hear of the contrary if anyone can provide details.

Found something strange in Mandel Machine which I did not see before. Perhaps a bug?

(http://i.imgur.com/A0Suh8j.png)

The blue rectangles don't seem to fit the picture. Seen similar (smaller) things a few zoomlevels back. Param file attached. Rerendering from this file reproduces the error (did not do a restart of the program).

<EDIT>
Notice the lowest big black circle. Between the big black circle and the smaller one, there is a stripe of what looks like the same blue color. Also seen on deeper zoomlevels.
</EDIT>

Bruce Dawson from fractal extreme investigated the use of GPGPU for deep zooming. The conclusion was that GPUs could be used and they would be good for low depths, but they are less efficient exactly where they are needed most: at the deeper zoom levels. Mandelbrot rendering up to the max depth for floating point precision is already so fast that it doesn't really need to be optimized more. The human efforts would be too big for almost unnoticeable extra performance. However, perturbation requires only few high-precision calculations even at high zoom levels, so maybe those GPUs aren't that bad of an idea after all!

CUDA Device count = 1

Some properties of CUDA device 0:
=================================
Name: GeForce GTX 760
Compute capability: 3.0
Number of multiprocessors: 6
Total global memory: 2147155968 bytes
Shared Mem/Block: 49152 bytes
Shared Mem Access: 8 bytes
=================================

*********************
n_digits = 156
prec_words = 12, 12
MAX_PREC_WORDS = 145
n_words = 17
numElement = 307200
*********************
Prepare data.................................
        done.
test_add ........................................
numElement = 307200, interval = 307200
numBlock = 2400, numThread = 128
interval memory layout...
*** GPU add: 0.003 sec ***
*** CPU add: 0.164 sec ***
*** The abs. of max. rel. error = 10 ^ 0 x 0 ***
*** The abs. of avg. rel. error = 10 ^ 0 x 0 ***
A sample when i = 164661
GOLD = 10 ^ 0 x 1.146514967712305809649915716387329890097697486394245497434308221497424464834325631
79364833248365700345339165485223330578732787146025929987360878945595128796
REF  = 10 ^ 0 x 1.146514967712305809649915716387329890097697486394245497434308221497424464834325631
79364833248365700345339165485223330578732787146025929987360878945595128796

...

Could you provide some hints on how to interpret these results?

What do n_digits, prec_words, MAX_PREC_WORDS and n_words mean?

I think a large bailout is not good. A bailout of 2 is perfect and natural to the mandelbrot set, because it is the minimum bailout required to catch all the points that belong to the set. A larger bailout value doesn't affect the set itself, but it does affect the structures of the iteration bands. There, valuable information is lost. It is especially apparent in the needle/antenna. Even at a magnification of something like E10000, the structure of the iterations bands contains enough information to find your way around the line and find a minibrot.

I think a large bailout is not good. A bailout of 2 is perfect and natural to the mandelbrot set, because it is the minimum bailout required to catch all the points that belong to the set. A larger bailout value doesn't affect the set itself, but it does affect the structures of the iteration bands. There, valuable information is lost. It is especially apparent in the needle/antenna. Even at a magnification of something like E10000, the structure of the iterations bands contains enough information to find your way around the line and find a minibrot.

Hello! How to correctly load palette? All my palettes is .bmp files, 4096x10. When I load and press 'OK' program do nothing! How to do that?

After you load the bitmap (.bmp) file, you have to drag a line from one place to another on the bitmap that is displayed on the screen to set the palette, so for your image, you would start at the left hand side, drag a line to the extreme right, and the palette would display in the area above.

This means you do not have to use the entire image for palette, you can load a picture of anything and create a palette from that.

This means you do not have to use the entire image for palette, you can load a picture of anything and create a palette from that.

I'm finding a frustrating 'opportunity' with Mandel Machine (v1.1.3).
On large images 1680x1050 with high supersampling 4x4 the color offset slider seems set the previous slider position not the current.
If the slider is positioned in the middle and I make a big change sliding it all the way to the left it only shifts the palette on the rendered image slightly.
If I then slightly nudge the slider to the right, a big change to the images palette happens.
It seems the rendered image renders the previous position not the current.
This happens when nuding the offset slider, say I nudge the slider several times to the left.
I've overshot so now I nudge to the right, the image changes as if I had continued nudging to the left.
After another nudge right and the images changes as expected.
Always being one step behind makes it very hard to get the exact background colour, especially with my stripey palettes.
The workaround is to get the palette offset 'just so' with no supersampling before committing to a 8x8 supersample render.

The program still has stability problems here. It crashes a lot when I try to change parameters while a render is going on. It also crashes often when I try to abort a render.

Something that would greatly enhance exploring: faster zooming with the mouse wheel. Currently the render has to finish first before more zooming with the mouse wheel is allowed. I would even suggest to make the smooth transition animation a little shorter. Speed is key for exploring.

More ideas: pause button, and ability for the program to remember the last location where a file was loaded and where a file was saved.

The program still has stability problems here. It crashes a lot when I try to change parameters while a render is going on. It also crashes often when I try to abort a render.

Something that would greatly enhance exploring: faster zooming with the mouse wheel. Currently the render has to finish first before more zooming with the mouse wheel is allowed. I would even suggest to make the smooth transition animation a little shorter. Speed is key for exploring.

More ideas: pause button, and ability for the program to remember the last location where a file was loaded and where a file was saved.

But - i have already Java 64bit Last version installed.
Why dont use the prg this install ?
Dont need an additional Jave ... better use the (IF ! ) already installed Jave - as if the user update his jave - the prg benefit from this upgrade too :)

A few palette related things I've noticed.
When loading a palette from an image the palette isn't applied immediately.
Another zoom or change of the palette sliders activates the new palette.

Palettes loaded from an image (PNG, JPEG, BMP) don't get saved into the mmf file.
This gives a differently coloured image when you reload it.
I can guess why this happens, loading from an image there is no rendering.palette line to save later on so the previous one is used.
Creating this line at save time would have to be done from the internal array which is million items?
Better to create the rendering.palette line when loading from an image, might slow that process down slightly.

Loading a mmf file that just contains palette information forces a recalculation.
I would like to apply different palettes to the final image and composite the different layers using GIMP.
If a mmf file doesn't have information from the image or location sections a recalculation needn't be done?

Also one other question.  Is the limit of 1,900 zooms able to be lifted?  I have hit that a few times while deep zooming (it's so fast nowadays I don't always realise I'm near the limit) and thought it was a bug until I reread this post!

The palette is saved as a sequence of key colors.

Thanks, so for some reason the palette saved is always the default one. I should have found it while testing, maybe it was too late at night (or early in the morning :dink:)
Scrolling speed will be faster in the next version.

Lovely image but interesting glitch.  The only way I could save it was by grabbing the window.

Lovely image but interesting glitch.  The only way I could save it was by grabbing the window.

(http://www.needanother.co.uk/uploads/Interesting Glitch.png)

I enclose the parameters:

www.needanother.co.uk/uploads/Polished Emerald.mmf (http://www.needanother.co.uk/uploads/Polished Emerald.mmf)

PNG saves too long. Botond, for saving PNG use GDI+. It saves All formats as fast. Dinkydau use my program. It very slow, but saves as fast. GDI+

Any news on a 32 bit version?

It is in the backlog, but with low priority. I plan to implement unlimited zooming and Pauldebrot's ultimate glitch detection first.

Thanks, this seems to be the result of the series approximation being too aggressive.

an interesting glitch indeed, here is that location rendered with SFT...

Which location?

Oh, I remember, that is a tough location! I could only raise the iteration count to 250 millions (I have 10 GB RAM), and it is still too low to display anything but a flat area.

But stay tuned, the next release of Mandel Machine will be focused around a cleverer series approximation, and one pleasant side-effect will be reduced memory footprint!

You skip 90% of iterations on average? With how many coefficients? And what are the max errors you accept?

That sounds amazing!  :o

The location has minimum 377372 and maximum 378486 iterations.
The difference is 1114, so I guess you need to calculate at least that amount?

KF can skip 310508 iterations, but renders this in 640x360 in 6 minutes, which is "only" 150 times faster than FX, not considering hardware... :)
Long double is used for this location, which breaks KF if the maximum number of iterations is set lower than 310508

Amazing speedup! ;D What do you mean only the iterations after series approximation are kept in memory? I thought the amount of iterations you can skip with SA varies from pixel to pixel. Or do you set some minimum threshold of iterations to skip with SA, and if SA is not effective enough for a pixel, you try a new reference point?

Are you storing the coefficients with arbitrary precision? Do you compute the start value with skip with arbitrary precision?

You could also look up the details in the source code of Kalles Fraktaler.

Thanks for that, and you've done amazing improvements on it, since it is about 10 times faster than mine?
And indeed much faster than using long double!
SIMD, no C++ operations, normalization only when needed, assembler, etc?

I found some issues with the location that was given by simon.snake, zoomed further a little bit to 1448.
The approximation breaks and it get very slow when it is changed, fewer terms makes it a little better but it is distorted unless approximation is turned off completely.

I don't quite follow your description on how you determine how many iterations you can skip.
In KF I simply use a couple of reference pixels, in the corners, calculated with perturbation starting from iteration 0, and compare how many iterations that get correct within a given tolerance, about 0.1%.

Did you remove all auto-glitch correction? Anyway, if you implement Pauldelbrot's method your program will be super! :)

At what location and zoom level did you measure the 10x difference?

I found that checking the corners only is not always enough. In fact, when the image is centered on a julia, there are some cases when the borders are rendered correctly but the center is corrupted due to the SA skipping too many iterations.

This was on the Magnum-Opus location.
With pixel grouping=1 and SA=6 terms, which is comparable with KF, MM calculates this in 43 seconds and KF in 6 minutes.
Is MM using long double or ASFloat for this?

Yeah, I also found that corners is not enough and I have added pixels on the middle top, bottom, right and left, in total 8 test pixels, in the eventual next version of KF. If one of them fails the tolerance, that's where the limit is set.
But my problem were locations at the <-2,0i> spike and not at embedded julias. I never had problems with that the borders but not the center were rendered correctly.

In the previous version of Mandel Machine I was having this glitch. It appears when 0 or 6 terms are being used for the series approximation. Note that it happens even with 0 terms! 10 terms (or any more than that) now gives the correct result.

Botond, can you make saving history elements to files and when recovering - just re-read file and data??? I consider that will reduce RAM usage :)

Yes, this is the original operation, I just switched it off temporarily in the latest beta, so it has to recalculate everything when restoring a previous state from history. But this doesn't increase RAM consumption.

So... All the same... Reference eats many RAM and you can't change this fact...

Another issue, but this time a relatively small one.  Colour Palettes can be loaded from .gif files but they do not show up automatically.

Botond, fix the bugs, please.
1) I can't set high image sizes (more than 16000x9000).
2) Auto solve glitches

P.s. If you can, make SIMPLIEST render sequence to PNG! Please.

Botond, I have 3 questions:
1) How to make this awesome style of windows?

2) How to make 'Window in window'?

3) How to solve problem with very high images (more than 15360x8640)?

I can't set high image sizes (more than 16000x9000).

Also note that using supersampling multiplies the image size and the memory requirement by 4 for each step of supersampling. For example rendering a 16000x9000 image with 2x2 multisampling results in a full 32000x18000 image to be stored in memory, which requires 7 GB. Rendering it with 4x4 supersampling would require 27.6 GB.

There is also a hard limit in MM on the image size. It is currently 536 megapixels, and this prevents a 16000x9000 image with any supersampling to be rendered (it would take 576 megapixels even with 2x2 supersampling). I plan to lift this limitation in the future, but this is a low priority enhancement.

Also note that using supersampling multiplies the image size and the memory requirement by 4 for each step of supersampling. For example rendering a 16000x9000 image with 2x2 multisampling results in a full 32000x18000 image to be stored in memory, which requires 7 GB. Rendering it with 4x4 supersampling would require 27.6 GB.

There is also a hard limit in MM on the image size. It is currently 536 megapixels, and this prevents a 16000x9000 image with any supersampling to be rendered (it would take 576 megapixels even with 2x2 supersampling). I plan to lift this limitation in the future, but this is a low priority enhancement.

Not true, you can trivially do it in smaller sub-blocks or tiles, buckets, whatever you want to call them. This is only true for IFS fractals, where you cannot simply ask for the colour of a (sub-)pixel.

In fact, because of this convenient property for escape-time fractals, you don't even need to store the full 1:1 image in memory, just some small buffer so that you aren't saving the pixels to disk one at a time (which you can compute in file-format order and save directly).

Since you are achieving enormous speed-ups by exploiting the Series Approximation to the extreme, I think this information is useful to you:
http://www.fractalforums.com/announcements-and-news/kalles-fraktaler-2/msg74804/#msg74804

Hello, Botond! How to realize Marianni/Silver algorithm for simpliest z^2+C??? I tried to read post on the sites, but do not understand. Can you help me?

Mandel Machine is a highly efficient Mandelbrot set explorer application.
http://web.t-online.hu/kbotond/mandelmachine (http://web.t-online.hu/kbotond/mandelmachine)

(http://web.t-online.hu/kbotond/mandelmachine/mm_screenshot_large.png)

[...]

Special thanks to Michael Condron, Bruce Dawson, Kevin Martin and Karl Runmo for sharing their ideas.

Any comments are welcome.

any idea what is happening here?
am i doing something wrong?

It looks the same as when my GPU tries rendering beyond precision limits.

I like your image render! I'm quite flattered you used my coordinate!  ;D
http://stardust4ever.deviantart.com/art/XX-Reactor-Core-Deep-Zoom-131573460
 :thumbsup1:

I have to say, your gallery on deviantart drove me to improve the speed of Mandel Machine. Before implementing the perturbation algorithm, it was already 30-40% faster than Fractal Extreme at zoom depths beyond 500. (This can be tested by unchecking "Use perturbation algorithm" under Computation.)

It is truly unbelievable you had the patience to find such deep locations like Magnum Opus Ex, using the conventional algorithm with full precision calculations.

...
For Mandel Machine .. I wonder how the development is progressing. Botond, could you provide us with a short status update?

Is there any chance you could increase the zoom limit? Pretty please... :spsad:

I'm currently carving my way through using Kalles Fraktaler 2 but if there's another software app comparable to Mandel Machine, I'd like to use that instead. Kalles Fraktaler 2 has a few glaring issues that make it clunky to render finished images. For starters, the aspect ratio seems to be pegged at 16x9 and there doesn't seem to be a way to rotate the image to fit onscreen, especially if it's an oblong shape which as Murphy's law dictates, that the shape wil be vertically aligned instead or horizontal.

seems like precision limits have something to do with it, when I set this from auto to a manual value I could zoom deeper (but encountered other problems)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ILLEGAL_INSTRUCTION (0xc000001d) at pc=0x000007fef25e0eb5, pid=2952, tid=3356
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [mm64.dll+0x40eb5]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x0000000011fe2000):  JavaThread "WorkerThread1" [_thread_in_native, id=3356, stack(0x00000000123b0000,0x00000000124b0000)]

siginfo: ExceptionCode=0xc000001d

Registers:
RAX=0x000007fef25fb8a0, RBX=0x000000000000000c, RCX=0x0000000000000004, RDX=0x00000000000003e8
RSP=0x00000000124aef78, RBP=0x00000007a67b29a8, RSI=0x0000000000000004, RDI=0x00000000000003e8
R8 =0x00000007a67b29a8, R9 =0x0000000000000026, R10=0x000000000000000c, R11=0x000000006e082a70
R12=0x0000000000000000, R13=0x0000000011fe21e8, R14=0x00000000124af0a0, R15=0x0000000011fe2000
RIP=0x000007fef25e0eb5, EFLAGS=0x0000000000010202

Top of Stack: (sp=0x00000000124aef78)
0x00000000124aef78:   000007fef25a208d 00000006e81b2920
0x00000000124aef88:   00000000124af060 0000000000000004
0x00000000124aef98:   0000000002592a39 00000000124af500
0x00000000124aefa8:   0000000011fe2000 00000006e81b2920
0x00000000124aefb8:   0000000002586215 00000006e819be48
0x00000000124aefc8:   0000000002592bb0 00000000ffffff00
0x00000000124aefd8:   00000006e81b2920 00000000124af060
0x00000000124aefe8:   0000000000000000 00000000124af090
0x00000000124aeff8:   000000000000000c 0000006f00000002
0x00000000124af008:   00000007000001d0 0000000011fe2000
0x00000000124af018:   00000000124af160 00000000124af020
0x00000000124af028:   00000006e81b2920 00000000124af0a0
0x00000000124af038:   00000006e8529918 0000000000000000
0x00000000124af048:   00000006e81b2920 0000000000000000
0x00000000124af058:   00000000124af080 00000000124af0e8
0x00000000124af068:   00000000025860f8 00000007a6873ee0

Instructions: (pc=0x000007fef25e0eb5)
0x000007fef25e0e95:   c4 41 15 58 ef 83 c0 04 3b c2 0f 8c 45 ff ff ff
0x000007fef25e0ea5:   c4 41 7d 11 40 20 c4 41 7d 11 48 60 c5 f8 77 c3
0x000007fef25e0eb5:   c4 c1 7d 10 00 c4 c1 7d 10 48 60 c5 fd 28 d0 c5
0x000007fef25e0ec5:   fd 28 d9 c4 41 7d 10 60 20 c4 41 7d 10 a8 80 00


Register to memory mapping:

RAX=0x000007fef25fb8a0 is an unknown value
RBX=0x000000000000000c is an unknown value
RCX=0x0000000000000004 is an unknown value
RDX=0x00000000000003e8 is an unknown value
RSP=0x00000000124aef78 is pointing into the stack for thread: 0x0000000011fe2000
RBP=0x00000007a67b29a8 is an unknown value
RSI=0x0000000000000004 is an unknown value
RDI=0x00000000000003e8 is an unknown value
R8 =0x00000007a67b29a8 is an unknown value
R9 =0x0000000000000026 is an unknown value
R10=0x000000000000000c is an unknown value
R11=0x000000006e082a70 is an unknown value
R12=0x0000000000000000 is an unknown value
R13=0x0000000011fe21e8 is an unknown value
R14=0x00000000124af0a0 is pointing into the stack for thread: 0x0000000011fe2000
R15=0x0000000011fe2000 is a thread


Stack: [0x00000000123b0000,0x00000000124b0000],  sp=0x00000000124aef78,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [mm64.dll+0x40eb5]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  mm.WorkerThread.getIterationsDnative(II[DII)V+0
j  mm.WorkerThread.getIterationsD(III[I[I[I)V+183
j  mm.WorkerThread.getIterations(III[I[I[I)V+72
j  mm.WorkerThread.computeRowInterleaved(IIIII)V+155
j  mm.WorkerThread.compute()V+154
j  mm.WorkerThread.run()V+48
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00000000120bd000 JavaThread "ControlThread" [_thread_blocked, id=3580, stack(0x0000000014400000,0x0000000014500000)]
  0x0000000011f92000 JavaThread "Swing-Shell" daemon [_thread_blocked, id=3500, stack(0x0000000014260000,0x0000000014360000)]
  0x000000001201a000 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=3412, stack(0x0000000013ff0000,0x00000000140f0000)]
  0x0000000011e10000 JavaThread "AWT-Shutdown" [_thread_blocked, id=3404, stack(0x0000000013b70000,0x0000000013c70000)]
  0x00000000120ea000 JavaThread "WorkerThread3" [_thread_in_native, id=3372, stack(0x0000000013cb0000,0x0000000013db0000)]
  0x00000000120e9000 JavaThread "WorkerThread2" [_thread_in_native, id=3368, stack(0x0000000013a50000,0x0000000013b50000)]
=>0x0000000011fe2000 JavaThread "WorkerThread1" [_thread_in_native, id=3356, stack(0x00000000123b0000,0x00000000124b0000)]
  0x0000000011fe1000 JavaThread "WorkerThread0" [_thread_in_native, id=3348, stack(0x00000000138d0000,0x00000000139d0000)]
  0x0000000011fd1800 JavaThread "Image Fetcher 1" daemon [_thread_blocked, id=3340, stack(0x0000000012ee0000,0x0000000012fe0000)]
  0x0000000011e11800 JavaThread "Image Fetcher 0" daemon [_thread_blocked, id=3244, stack(0x0000000012780000,0x0000000012880000)]
  0x0000000011e10800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=3228, stack(0x0000000012190000,0x0000000012290000)]
  0x0000000011e0f000 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=3212, stack(0x00000000122b0000,0x00000000123b0000)]
  0x0000000010411000 JavaThread "Service Thread" daemon [_thread_blocked, id=656, stack(0x0000000011980000,0x0000000011a80000)]
  0x0000000010410800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=1320, stack(0x0000000011ad0000,0x0000000011bd0000)]
  0x0000000010407800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=2912, stack(0x0000000011850000,0x0000000011950000)]
  0x0000000010405800 JavaThread "Attach Listener" daemon [_thread_blocked, id=2908, stack(0x0000000011650000,0x0000000011750000)]
  0x00000000103fe800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2460, stack(0x00000000114d0000,0x00000000115d0000)]
  0x00000000103a6000 JavaThread "Finalizer" daemon [_thread_blocked, id=2896, stack(0x00000000113d0000,0x00000000114d0000)]
  0x000000001039f000 JavaThread "Reference Handler" daemon [_thread_blocked, id=2892, stack(0x00000000112a0000,0x00000000113a0000)]
  0x000000000028d800 JavaThread "main" [_thread_in_native, id=2980, stack(0x00000000023f0000,0x00000000024f0000)]

Other Threads:
  0x0000000010396800 VMThread [stack: 0x0000000011140000,0x0000000011240000] [id=2428]
  0x000000001041b000 WatcherThread [stack: 0x0000000011c40000,0x0000000011d40000] [id=3080]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 38400K, used 9174K [0x00000007a4500000, 0x00000007a6f80000, 0x0000000800000000)
  eden space 33280K, 12% used [0x00000007a4500000,0x00000007a48f5f20,0x00000007a6580000)
  from space 5120K, 99% used [0x00000007a6580000,0x00000007a6a7f970,0x00000007a6a80000)
  to   space 5120K, 0% used [0x00000007a6a80000,0x00000007a6a80000,0x00000007a6f80000)
 ParOldGen       total 86528K, used 11273K [0x00000006ed000000, 0x00000006f2480000, 0x00000007a4500000)
  object space 86528K, 13% used [0x00000006ed000000,0x00000006edb027f0,0x00000006f2480000)
 PSPermGen       total 21504K, used 16891K [0x00000006e7e00000, 0x00000006e9300000, 0x00000006ed000000)
  object space 21504K, 78% used [0x00000006e7e00000,0x00000006e8e7ef98,0x00000006e9300000)

Card table byte_map: [0x0000000005640000,0x0000000005f10000] byte_map_base: 0x0000000001f01000

Polling page: 0x0000000000220000

Code Cache  [0x0000000002580000, 0x00000000027f0000, 0x0000000005580000)
 total_blobs=651 nmethods=120 adapters=484 free_code_cache=48276Kb largest_free_block=49417472

Compilation events (10 events):
Event: 12.208 Thread 0x0000000010407800  114             javax.swing.plaf.nimbus.NimbusStyle::getValues (9 bytes)
Event: 12.208 Thread 0x0000000010410800  115             java.awt.Component::getFont_NoClientCode (29 bytes)
Event: 12.209 Thread 0x0000000010407800 nmethod 114 0x0000000002642650 code [0x00000000026427a0, 0x0000000002642828]
Event: 12.209 Thread 0x0000000010410800 nmethod 115 0x0000000002642390 code [0x00000000026424e0, 0x00000000026425a8]
Event: 12.210 Thread 0x0000000010407800  116             java.awt.Component::getFont (5 bytes)
Event: 12.211 Thread 0x0000000010407800 nmethod 116 0x00000000026420d0 code [0x0000000002642220, 0x00000000026422e8]
Event: 12.217 Thread 0x0000000010410800  117             java.util.HashMap::put (142 bytes)
Event: 12.234 Thread 0x0000000010410800 nmethod 117 0x000000000265c290 code [0x000000000265c4c0, 0x000000000265d070]
Event: 12.395 Thread 0x0000000010407800  118 %           java.util.Arrays::fill @ 10 (28 bytes)
Event: 12.399 Thread 0x0000000010407800 nmethod 118% 0x000000000265afd0 code [0x000000000265b120, 0x000000000265b2f8]

GC Heap History (2 events):
Event: 12.376 GC heap before
{Heap before GC invocations=1 (full 0):
 PSYoungGen      total 38400K, used 33280K [0x00000007a4500000, 0x00000007a6f80000, 0x0000000800000000)
  eden space 33280K, 100% used [0x00000007a4500000,0x00000007a6580000,0x00000007a6580000)
  from space 5120K, 0% used [0x00000007a6a80000,0x00000007a6a80000,0x00000007a6f80000)
  to   space 5120K, 0% used [0x00000007a6580000,0x00000007a6580000,0x00000007a6a80000)
 ParOldGen       total 86528K, used 2400K [0x00000006ed000000, 0x00000006f2480000, 0x00000007a4500000)
  object space 86528K, 2% used [0x00000006ed000000,0x00000006ed258010,0x00000006f2480000)
 PSPermGen       total 21504K, used 16753K [0x00000006e7e00000, 0x00000006e9300000, 0x00000006ed000000)
  object space 21504K, 77% used [0x00000006e7e00000,0x00000006e8e5c468,0x00000006e9300000)
Event: 12.392 GC heap after
Heap after GC invocations=1 (full 0):
 PSYoungGen      total 38400K, used 5118K [0x00000007a4500000, 0x00000007a6f80000, 0x0000000800000000)
  eden space 33280K, 0% used [0x00000007a4500000,0x00000007a4500000,0x00000007a6580000)
  from space 5120K, 99% used [0x00000007a6580000,0x00000007a6a7f970,0x00000007a6a80000)
  to   space 5120K, 0% used [0x00000007a6a80000,0x00000007a6a80000,0x00000007a6f80000)
 ParOldGen       total 86528K, used 11273K [0x00000006ed000000, 0x00000006f2480000, 0x00000007a4500000)
  object space 86528K, 13% used [0x00000006ed000000,0x00000006edb027f0,0x00000006f2480000)
 PSPermGen       total 21504K, used 16753K [0x00000006e7e00000, 0x00000006e9300000, 0x00000006ed000000)
  object space 21504K, 77% used [0x00000006e7e00000,0x00000006e8e5c468,0x00000006e9300000)
}

Deoptimization events (10 events):
Event: 11.762 Thread 0x000000001201a000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x00000000025fb790 method=java.lang.String.equals(Ljava/lang/Object;)Z @ 8
Event: 11.762 Thread 0x000000001201a000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x00000000025fb790 method=java.lang.String.equals(Ljava/lang/Object;)Z @ 8
Event: 12.036 Thread 0x000000001201a000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x000000000262180c method=javax.swing.UIDefaults.getFromHashtable(Ljava/lang/Object;)Ljava/lang/Object; @ 122
Event: 12.069 Thread 0x000000000028d800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002621104 method=javax.swing.UIDefaults.getFromHashtable(Ljava/lang/Object;)Ljava/lang/Object; @ 92
Event: 12.074 Thread 0x000000000028d800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002621104 method=javax.swing.UIDefaults.getFromHashtable(Ljava/lang/Object;)Ljava/lang/Object; @ 92
Event: 12.203 Thread 0x000000000028d800 Uncommon trap: reason=unloaded action=reinterpret pc=0x0000000002659ea0 method=mm.Palette.computeGradient()V @ 853
Event: 12.212 Thread 0x000000000028d800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x00000000025fb790 method=java.lang.String.equals(Ljava/lang/Object;)Z @ 8
Event: 12.216 Thread 0x000000001201a000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x000000000261a3d4 method=javax.swing.UIDefaults.getFromHashtable(Ljava/lang/Object;)Ljava/lang/Object; @ 122
Event: 12.220 Thread 0x000000001201a000 Uncommon trap: reason=unreached action=reinterpret pc=0x0000000002613404 method=javax.swing.JComponent.getClientProperty(Ljava/lang/Object;)Ljava/lang/Object; @ 16
Event: 12.399 Thread 0x000000001201a000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x00000000025fb790 method=java.lang.String.equals(Ljava/lang/Object;)Z @ 8

Internal exceptions (10 events):
Event: 12.368 Thread 0x000000000028d800 Threw 0x00000007a5f5c168 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jvm.cpp:1244
Event: 12.368 Thread 0x000000000028d800 Threw 0x00000007a5f5dcc8 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jvm.cpp:1244
Event: 12.368 Thread 0x000000000028d800 Threw 0x00000007a5f5f530 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jvm.cpp:1244
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a4500340 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a4500508 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a45006a0 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a4500d68 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a4500f30 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.394 Thread 0x00000000120bd000 Threw 0x00000007a45010c8 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jni.cpp:717
Event: 12.400 Thread 0x00000000120ea000 Threw 0x00000007a47d9948 at C:\re\jdk7u67\1368\hotspot\src\share\vm\prims\jvm.cpp:1244

Events (10 events):
Event: 12.404 Executing VM operation: RevokeBias
Event: 12.404 Executing VM operation: RevokeBias done
Event: 12.404 Executing VM operation: RevokeBias
Event: 12.404 Executing VM operation: RevokeBias done
Event: 12.404 Executing VM operation: RevokeBias
Event: 12.404 Executing VM operation: RevokeBias done
Event: 12.408 loading class 0x000000001351e990 done
Event: 12.408 loading class 0x0000000011d96810 done
Event: 12.408 loading class 0x0000000011d967d0
Event: 12.408 loading class 0x0000000011f9fe70


Dynamic libraries:
0x000000013f950000 - 0x000000013f983000    C:\Program Files\Java\jre7\bin\javaw.exe
0x0000000077a40000 - 0x0000000077beb000    C:\Windows\SYSTEM32\ntdll.dll
0x0000000077920000 - 0x0000000077a3f000    C:\Windows\system32\kernel32.dll
0x000007fefdc40000 - 0x000007fefdcab000    C:\Windows\system32\KERNELBASE.dll
0x000007feffa90000 - 0x000007feffb6b000    C:\Windows\system32\ADVAPI32.dll
0x000007fefdd70000 - 0x000007fefde0f000    C:\Windows\system32\msvcrt.dll
0x000007fefe8f0000 - 0x000007fefe90f000    C:\Windows\SYSTEM32\sechost.dll
0x000007fefde10000 - 0x000007fefdf3e000    C:\Windows\system32\RPCRT4.dll
0x0000000077820000 - 0x000000007791a000    C:\Windows\system32\USER32.dll
0x000007feffce0000 - 0x000007feffd47000    C:\Windows\system32\GDI32.dll
0x000007fefec50000 - 0x000007fefec5e000    C:\Windows\system32\LPK.dll
0x000007feffb70000 - 0x000007feffc3a000    C:\Windows\system32\USP10.dll
0x000007fefc190000 - 0x000007fefc384000    C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_fa645303170382f6\COMCTL32.dll
0x000007feff9f0000 - 0x000007feffa61000    C:\Windows\system32\SHLWAPI.dll
0x000007fefdfc0000 - 0x000007fefdfee000    C:\Windows\system32\IMM32.DLL
0x000007fefe6b0000 - 0x000007fefe7b9000    C:\Windows\system32\MSCTF.dll
0x000007fefd960000 - 0x000007fefd9a0000    C:\Windows\system32\nvinitx.dll
0x000000006e680000 - 0x000000006e752000    C:\Program Files\Java\jre7\bin\msvcr100.dll
0x000000006dea0000 - 0x000000006e672000    C:\Program Files\Java\jre7\bin\server\jvm.dll
0x000007fef2600000 - 0x000007fef2609000    C:\Windows\system32\WSOCK32.dll
0x000007fefe5c0000 - 0x000007fefe60d000    C:\Windows\system32\WS2_32.dll
0x000007fefe5b0000 - 0x000007fefe5b8000    C:\Windows\system32\NSI.dll
0x000007fefb090000 - 0x000007fefb0cb000    C:\Windows\system32\WINMM.dll
0x0000000077c10000 - 0x0000000077c17000    C:\Windows\system32\PSAPI.DLL
0x000000006de90000 - 0x000000006de9f000    C:\Program Files\Java\jre7\bin\verify.dll
0x000000006de60000 - 0x000000006de88000    C:\Program Files\Java\jre7\bin\java.dll
0x000000006de40000 - 0x000000006de55000    C:\Program Files\Java\jre7\bin\zip.dll
0x000000006d7b0000 - 0x000000006d945000    C:\Program Files\Java\jre7\bin\awt.dll
0x000007fefe7c0000 - 0x000007fefe897000    C:\Windows\system32\OLEAUT32.dll
0x000007fefea40000 - 0x000007fefec41000    C:\Windows\system32\ole32.dll
0x000007fefc0e0000 - 0x000007fefc136000    C:\Windows\system32\uxtheme.dll
0x000007fef3790000 - 0x000007fef379b000    C:\Program Files (x86)\Yandex\Punto Switcher\PSHook64.dll
0x000007feffa70000 - 0x000007feffa87000    C:\Windows\system32\imagehlp.dll
0x000007fefbd00000 - 0x000007fefbd18000    C:\Windows\system32\dwmapi.dll
0x000007fefd890000 - 0x000007fefd89f000    C:\Windows\system32\CRYPTBASE.dll
0x000007fefec60000 - 0x000007feff9e6000    C:\Windows\system32\SHELL32.dll
0x000007fef25a0000 - 0x000007fef25ff000    D:\SOFT\Mandel Machine\mm64.dll
0x000000006d760000 - 0x000000006d7a7000    C:\Program Files\Java\jre7\bin\fontmanager.dll
0x000000006d750000 - 0x000000006d75b000    C:\Program Files\Java\jre7\bin\management.dll
0x000000006d730000 - 0x000000006d749000    C:\Program Files\Java\jre7\bin\net.dll
0x000007fefd1c0000 - 0x000007fefd214000    C:\Windows\system32\mswsock.dll
0x000007fefd1b0000 - 0x000007fefd1b7000    C:\Windows\System32\wship6.dll
0x000000006d710000 - 0x000000006d721000    C:\Program Files\Java\jre7\bin\nio.dll
0x000000006d6c0000 - 0x000000006d701000    C:\Program Files\Java\jre7\bin\t2k.dll
0x000007fefdcd0000 - 0x000007fefdd70000    C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7600.16385_none_a44af8ec57f961cf\comctl32.dll
0x000007fefe3d0000 - 0x000007fefe5a7000    C:\Windows\system32\SETUPAPI.dll
0x000007fefda50000 - 0x000007fefda86000    C:\Windows\system32\CFGMGR32.dll
0x000007fefdcb0000 - 0x000007fefdcca000    C:\Windows\system32\DEVOBJ.dll
0x000007fefe610000 - 0x000007fefe6a9000    C:\Windows\system32\CLBCatQ.DLL
0x000007fefc6b0000 - 0x000007fefc7dc000    C:\Windows\system32\propsys.dll
0x000007fefbb50000 - 0x000007fefbb7d000    C:\Windows\system32\ntmarta.dll
0x000007fefe8a0000 - 0x000007fefe8f0000    C:\Windows\system32\WLDAP32.dll
0x000007fefd830000 - 0x000007fefd887000    C:\Windows\system32\apphelp.dll
0x000007fef6170000 - 0x000007fef630c000    C:\Windows\system32\NetworkExplorer.dll
0x000007fef8d10000 - 0x000007fef8d43000    C:\Windows\System32\shdocvw.dll
0x000007fefd9a0000 - 0x000007fefd9af000    C:\Windows\system32\profapi.dll
0x000007fef9cd0000 - 0x000007fef9ce8000    C:\Windows\system32\MPR.dll
0x000007fef80f0000 - 0x000007fef80fa000    C:\Windows\System32\drprov.dll
0x000007fefcdb0000 - 0x000007fefcded000    C:\Windows\System32\WINSTA.dll
0x000007fef80c0000 - 0x000007fef80e2000    C:\Windows\System32\ntlanman.dll
0x000007fef7d50000 - 0x000007fef7d6b000    C:\Windows\System32\davclnt.dll
0x000007fef80b0000 - 0x000007fef80ba000    C:\Windows\System32\DAVHLPR.dll
0x000007fefb950000 - 0x000007fefb965000    C:\Windows\system32\wkscli.dll
0x000007fef9180000 - 0x000007fef918f000    C:\Windows\system32\cscapi.dll
0x000007fefb970000 - 0x000007fefb97c000    C:\Windows\system32\netutils.dll
0x000007feef8c0000 - 0x000007feefb31000    C:\Windows\system32\wpdshext.dll
0x000007fefbec0000 - 0x000007fefc0d5000    C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7600.16385_none_2b4f45e87195fcc4\gdiplus.dll
0x000007fef2670000 - 0x000007fef272d000    C:\Windows\system32\PortableDeviceApi.dll
0x000007fefda90000 - 0x000007fefdac9000    C:\Windows\system32\WINTRUST.dll
0x000007fefdad0000 - 0x000007fefdc36000    C:\Windows\system32\CRYPT32.dll
0x000007fefda40000 - 0x000007fefda4f000    C:\Windows\system32\MSASN1.dll
0x000007fef9210000 - 0x000007fef9245000    C:\Windows\system32\EhStorShell.dll
0x000007fef8c40000 - 0x000007fef8c67000    C:\Windows\system32\EhStorAPI.dll
0x000007fef86b0000 - 0x000007fef86bc000    C:\Windows\system32\LINKINFO.dll
0x000007fefbb90000 - 0x000007fefbcba000    C:\Windows\system32\WindowsCodecs.dll
0x000007fef9190000 - 0x000007fef9210000    C:\Windows\system32\ntshrui.dll
0x000007fefd590000 - 0x000007fefd5b3000    C:\Windows\system32\srvcli.dll
0x000007fefb5d0000 - 0x000007fefb5db000    C:\Windows\system32\slc.dll
0x00000000730c0000 - 0x00000000730ea000    C:\Program Files\Java\jre7\bin\dcpr.dll
0x000007fef8a10000 - 0x000007fef8b35000    C:\Windows\system32\dbghelp.dll

VM Arguments:
jvm_args: -Xmx4400m
java_command: D:\SOFT\Mandel Machine\MandelMachine.exe
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\OpenCL SDK\3.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\3.0\bin\x64;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Java\jre7\bin
USERNAME=Сергей
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel



---------------  S Y S T E M  ---------------

OS: Windows 7 , 64 bit Build 7600

CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 60 stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, erms, ht, tsc, tscinvbit

Memory: 4k page, physical 8307240k(6659276k free), swap 16612584k(14336476k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (24.65-b04) for windows-amd64 JRE (1.7.0_67-b01), built on Jul 25 2014 08:55:00 by "java_re" with unknown MS VC++:1600

time: Sun Aug 10 15:45:45 2014
elapsed time: 12 seconds

From the log you posted it seems you have Windows 7 build 7600, with no Service Pack 1 installed. That version of Windows does not support AVX, this might be the case for the crash. MM detects the available CPU instruction sets, but does not check operating system support. Will be fixed in the next release.

Shit! I can't turn on windows7 updates!!! Thanks for information...

Unshit!

Yes, that image was rendered with standard double precision, no perturbation. Did you have all computation parameters in Automatic setting?

SeryZone - Try this page for SP1 and probably grab the ISO: http://www.microsoft.com/en-gb/download/details.aspx?id=5842

So, my proc. intel core i5 2400M support AVX2 but MandelMachine don't use it... Why?

I tried tick-tock, but it looks like it is glitches now?

Also, the attached location, Verstoppertje from Dinkydau, doesn't work at all...

I see no glitches in tick-tock, could you attach an image?
Verstoppertje is completely broken in Mandel Machine, and I don't know the exact reason for it. It renders correctly with perturbation turned off. One of the optimizations might break the image, I'll have to investigate it.

Karl - Verstoppertje really have unsolvable glitches on 2-nd Julia. Mandel Machine don't have glitch solving by new method.

If you encounter crashes on a regular basis, please let me know the details. Also be aware of the known issues described in the changelog, the most important being the application may hang when adjusting a parameter during calculation - always cancel the calculation first with the Esc key before changing a parameter.

I discovered a weird anomaly with disconnected locus at 4551.131 zoom levels. :hurt:

Curious bug (it displays in both versions 1.2.3 and 1.2.4), but fortunately upon zooming in further, the anomaly disappeared allowing me to continue the zoom sequence.

you know guys, if this "glitch" works and doesn't do any harm, PLEASE don't see this as a glitch or a mistake you need to correct!
See it as Evolution! There has been a strange mutation in the formula! creating something new!

You should feature it! Try to push it further! Try to make it repeat and evolve itself!
A really NEW branch of the M-Set. And you want to "correct it"?! Noooooooooooooo!!!! :o

Why always "perfect" things.
zooming into the m-set is so diverse, but in can become boring, as the main patterns always nearly stay the same

THIS is something DIFFERENT.
I see it as EVOLUTION!
By random mutation, just as it happens in the real world.
Mistakes aren't bad, if you make the best out of them and improve on them.
Now Botond, please, make the evolution conscious and don't kill of the first spark! Let it grow!

I found that altering the location of the reference pixel in such a mutated image by just 1 pixel can lead to completely different mutations.

The glitches that stardust4ever posted also occur in the latest version, for example on the attached location. Using fewer terms of series approximation may help. Disabling series approximation always works, but that's much, much slower...

However I cannot start 1.2.6 - nothing happens.
MandelMachine.exe *32 flashes in Windows Task Manager processes and then disappear immediately.
I was just about to ask you if you had accidentally put a 32-bit executable in the zip.
But when I reverted to 1.2.5 again and it starts without problem, there is no MandelMachine.exe in Task Manager, the main window points to the process javaw.exe. So I guess MandelMachine.exe is just some kind of startup program?

Are you "caching" the alignment/normalization of your version of "fixedfloat"? Because I think that is a big reason why it is much more than twice slower than ordinary double (which I think it should be in theory). But that might also be a reason why precision may be limited.

Thanks, now it works :)
Nice to see that its now solving glitches in previously unbelievable speed!  :o

Attached location makes SA crash though.

There are other memory-consuming new features as well, e.g. glitch correction. So the limit of 4400 MB will have to be raised in a future version. Until then you can manually change it in the recently provided mm_start.cmd file. I also have 16 GB and could render a 23000x23000 image successfully by specifying -Xmx10240m instead of -Xmx4400m. You will have to start the application with the cmd, not the exe.

java -showversion -Xmx12288m -jar mm.jar

Before performing the addition, the two ASFloats had to be adjusted to have equal exponents (meaning the smaller exponent was set to equal the larger, and its mantissa was rescaled accordingly).

	static __inline double setExp(double newval,__int64 newexp)
	{
		*((__int64*)&newval) = (*((__int64*)&newval) & 0x800FFFFFFFFFFFFF) | ((newexp+1023)<<52);
		return newval;
	}
	__inline floatexp operator +(const floatexp &a)
	{
		floatexp r;
		__int64 diff;
		if(exp>a.exp){
			diff = exp-a.exp;
			r.exp = exp;
			if(diff>MAX_PREC)
				// If the smaller term is too small, ignore it.
				r.val=val;
			else{
				// Scale the smaller term and do the addition.
				double aval = setExp(a.val,-diff);
				r.val = val+aval;
			}
		}
		else{
			diff = a.exp-exp;
			r.exp = a.exp;
			if(diff>MAX_PREC)
				r.val=a.val;
			else{
				double aval = setExp(val,-diff);
				r.val = a.val+aval;
			}
		}
		_ALIGN_(r.val,r.exp)
		return r;
	}

When I do addition in floatexp, I only change the exponent part in the mantissa of the smaller object. I don't manipulate the mantissa with any double arithmetic...

I tried exactly the same, but it did not result in a significant speedup. Maybe because replacing a floating-point multiplication by an integer addition only saves a few clock cycles per floatexp addition. The nested IF constructs cost much more, especially in the case of a branch misprediction.

I'm not entirely sure how many pixel groupings AMD Bulldozer/Piledriver cores can handle atm. My 8-core Desktop and 4-core laptop (both AMD) give a very slight margin at 12 over 16, only a couple percent on the benchmark.

ne thing I notice while zooming in, is that most frames appear nearly instantly when the 1st orbit is completed, but when approaching areas with high density or a highly advanced Julia formation, the process of rendering pixels suddenly slows down by nearly an order of magnitude, then speeds back up after leaving the area or zooming through it. Kind of ironic that the feature I'm trying to render takes longer than the stuff immediately before or after it. And no, it's not one of those "blobby" areas either. Still strange that the complexity of the image or density of iteration data will have a profound impact on render speed (orbits are still about the same at this depth and iteration count though).

In the AMD Bulldozer architecture each processor module includes two CPU cores and one shared FPU (your 8-core CPU has only 4 FPUs). Inside a module, the two CPU cores already saturate the execution units of the shared FPU at a pixel grouping of 12, so going to 16 results in no further speed improvement. (Btw, the situation is the same on Intel CPUs with HyperThreading.)

Even worse, the Bulldozer modules have only two 128-bit FPU pipelines that can be unified into one 256-bit unit when running AVX code, so theoretically their performance under SSE2 and AVX is the same. By comparison, Intel processors have two 256-bit wide FPU pipelines per core. One Sandy Bridge or newer core has the same floating point throughput as 4 Bulldozer cores under AVX workloads. For more details and measurements see this article at AnandTech: http://www.anandtech.com/show/7711/floating-point-peak-performance-of-kaveri-and-other-recent-amd-and-intel-chips (http://www.anandtech.com/show/7711/floating-point-peak-performance-of-kaveri-and-other-recent-amd-and-intel-chips)

Another small update containing bugfixes. Palette extracted from an image is finally saved correctly in the .mmf file.

It's simple to do, although it's kind of a hassle. You can convert a gradient to an image. I use 4096×10 bmp file because SeryZone's software accepts that too (which is useful). To convert a gradient, you can take a screenshot of it and stretch it in photoshop to the resolution you wish. Use bicubic image resizing for the best result.

I think that you should to make turning on/off history recording. Maybe, It will reduce RAM usage.

=)

Sometimes program is closes automatically (now I have 12gig RAM), when RAM usage is getting more than 4GB. 'Not enough memory!' - and closes =(

I have not used the "IMG from PNG" Feature personally (a bit clunky, but I import palette data from Kalles Fraktaler parameters).

Place thie Huge.bat file in your Mandel Machine directory. It will let you utilize up to 10 Gigs of memory. I open Mandel Machine with it whenever I want to render huge images.

I don't need only little images (10240x5760 - is little)! I need infinite iteration limit too. But with perturbation theory RAM usage grow up due to iteration limit. I need 20-30GB RAM 4 rendering my location 2,000,000,000 iterations! This is very hard but... I must to render it! It is beautiful!

Well, for 2,000,000,000 iterations we need array of 2billions. double. We need (8*2B)=16,000,000,000 bytes =  14.901GB RAM for reference! + 10240x5760 image (10240*5760*4 = 225MB) Totally I need maximum 16GB for rendering final minibrot's image. Botond, Why I can't do this???



Sorry =( My idea works with integer, but doesn't works with float numbers =((( Idea was be @Compressing reference@

Well, for 2,000,000,000 iterations we need array of 2billions. double. We need (8*2B)=16,000,000,000 bytes =  14.901GB RAM for reference!

I'd like to see what you are rendering that takes 2 billion iterations. Good luck rendering whatever it is. Let us know what you find... O0

Very nice, Botond! Thank you!
P.s. What about deep zooming as mouse wheel? Mouse wheel do 1 zoom/sec. Double click 2zooms/second. Can you make deeper zoom using mouse???

Botond, why glitch-correction can't guess mini-brot? I wait 5 minutes for glitch and 38 hours for it's correction! Please, enable guessing!

I can't render large images. For example, 8760x4320, 4xAA. Program is 'ready' everytime, but I can't do something! It hangs out and... And all! Why?

I don't care! I render images less than 500MP but program hangs out! And I render 16:9 images. And memory works on a limit!

LAPTOP:
Intel Processor (4-core + 4 virtual cores = 8 cores) i5, support avx2.0
8GB RAM
1920x1080 screen
HDD
Windows 7
---------------------------------------------------------------------------------------------------------------------------------------------------------->
Personal Computer:
AMD FX8350, 8-Core, 4.0GHz (4.2 in Turbo Mode), support AVX, SSE, 3dNow! Doesn't support only AVX 2.0
12 GB RAM
1920x1080
SSD
Windows 7

Both computers is CAPABLE for using Mandel Machine.

Try to render this in a maximal 16:9 rezolution:

I can't understand, what is going on!

Hi, stardustforever.

Try to render this in a maximal 16:9 rezolution:

I can't understand, what is going on!

One wierd thing, with the latest beta, the resolution window said "1728)" in the bottom instead of 17280. 1.2.9 beta and 1.3.1 exhibited the same behavior.

Which resolution window?