ah, no windows binary release of GMP, need to build from source.. MingW where are you again...
On 25 March 2010 19:34, Matthew Kerle <[email protected]> wrote: > thanks! that looks really cool. not sure how it'll go with the iterative > nature of our calc's but will give it a benchmark this weekend. only thing > I'm worried about is the perf hit of making a native calls on every > operation (mul, add, compare)...? I thought JNI was really slow? mind you > it's only got to be faster than BigDecimal, if we get really serious I > suppose we can write a C wrapper to handle iterating over the complex array > so there would be one native call per render... > > anyone have experience with JNI performance on Java 6u16+? I remember it > used to be painful slow, but that's like 4 major releases ago, and > apparently <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5086424> it's > been upgraded since then... > > > I've written a little perf tester (attached) that runs a sample loop > through and prints out some times. as expected double and float kick ass. > I'd heard that this Apfloat class was pretty good but it turns out to be > even slower than BigDecimal!!! and they call themselves high performance.. > > output: > Float: 7ms > double: 8ms > BigDecimal: 1881ms > ApFloat: 4293ms > > now I just need GMP-J in here... > > > On 25 March 2010 16:05, mikeb01 <[email protected]> wrote: > >> While I don't have first hand experience I have heard good things >> about the performance of the GMP library for arbitrary precision >> math. It's C based so you will need JNI. There is a wrapper here: >> >> http://bitbucket.org/dfdeshom/gmp-java/src/ >> >> On Mar 25, 3:15 am, Matthew Kerle <[email protected]> wrote: >> > TL;DR we're writing a Mandelbrot set viewer and need to dive deeper. >> > BigDecimal sucks. help! >> > >> > So... My friend wrote a mandelbrot set viewer in Java (with Netbeans =D >> ) >> > using floats, it's pretty nice and lets you pan around and zoom and the >> > performance is not too bad, but after a while you hit the precision >> limit of >> > float (image pixellates out) so we swapped over to double and got a bit >> > deeper. >> > >> > The problem is now we want to go deeper than double lets us (step 6 >> > here< >> http://en.wikipedia.org/wiki/Mandelbrot_set#Image_gallery_of_a_zoom_s.. >> .>). >> > We tried implementing with BigDecimal but the performance absolutely >> crapped >> > out, like 100x worse, you die waiting for a single frame to render even >> with >> > precision turned way down (God help if you don't set a MathContext!!). >> After >> > googling around it looks like the problem is BigDecimal, it's optimised >> for >> > precision over speed. we don't care very much about precision, we just >> need >> > enough to get our pretty colours :-) Speed is more of a concern, >> although >> > obviously we're not realistically expecting float/double type speed from >> > arbitrary-precision arithmetic, but a slowdown of 2-5x would be fine, >> 10x + >> > starts getting depressing though... >> > >> > Other methods of performance tuning we're looking at: >> > - firstly progressive rendering (eg, do 100 iterations, draw an image, >> then >> > next 100 and so on to limit) >> > - scale-dependant implementation (eg go from float to double to ? as you >> > zoom in) >> > - multi-threading (split the image up and hand each portion off to a >> core, >> > not sure best way to configure this, thread per core?) >> > - caching (not sure best strategy for this, store result for each point >> with >> > iteration count or image directly? cache would get HUGE, but don't >> care...) >> > >> > I've found the ApFloat library <http://www.apfloat.org/apfloat_java/> >> which >> > looks pretty cool. but haven't had a chance to run some comparison runs >> with >> > it against BD yet (darn day job!!). >> > >> > Just wondering if anyone else has any experience with this domain or any >> > pointers? it's been a few years since uni and my number theory is a bit >> > rusty (one of the reasons we're playing with this...). mandelbrot uses >> > T(n+1) = n^2 + first term, so maybe we can do some optimisations by >> using >> > operating on integers and storing the precision separately? (obviously >> this >> > is what BD does already, but we only want a narrow slice of what it >> does...) >> > >> > incidentally, found Fast Fractal, it's a closed-source >> > windows-only<http://www.fastfractal.com/>program which purports to >> > have GPU acceleration for fractal viewing. I tried >> > it out and wasn't impressed, but then it couldn't detect my graphics >> card so >> > GPU acceleration wasn't enabled (low-rung Toshiba Satellite laptop). Any >> > decent GPU accelerated mandelbrot viewers out there for linux? >> > >> > cheers! >> > matt. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
