Randomize Overlaid Circles

[Mike Lobanovsky]

Problem either with JavaScript itself or me and Peter ...

And you say that you  have no problems. ... Once again - I can't understand your problem.

No, so what's your problem guys?

Tomaaz, who's having obvious problems if not you -- alone?

In fact, we all liked your code snippet and the effect that it produced in a very special browser -- the Firefox. We just wanted to point out that it wasn't JavaScript's merit (let it draw on a GDI canvas and see what it's worth), but rather the merit of people who were able to turn it on the fly into highly efficient assembly/machine code coupled with a WebGL canvas. That's exactly what we're discussing with JJ and Peter, just in case you haven't yet guessed for yourself.

[ScriptBasic]

I have been playing with the Emscripten C/C++ to JavaScript translator with a asm.js twist and have come to the conclusion that it generates way too much code to be usable. (for me) The silver lining is that it does generate advanced JavaScript functions and routines I can cheery pick and may use in my projects.

[Mike Lobanovsky]

Peter,

Judging by the looks of it, -fomit-frame-pointer and -ffast-math should be the ones that did the trick, especially if you formulated your drawing routine as a subprocedure. The other ones seem to be enabled in any -On except for -Os on default. My (almost) unoptimizing DynC yields (almost) twice slower speed in my GDI canvas on my PC that's also objectively slower than yours by perhaps some 20 or 25%.


[UPD] I've taken that last step and got rid of direct Canvas drawing functions altogether. Now all Canvas methods simply modify the contents of pixel array that's assigned to the Canvas DIB (device independent bitmap) once per Refresh() call. That's roughly what Tomaaz' canvasData.data[] does. Also, I chose the variable data types more carefully to avoid unnecessary casts. Got me almost 40% extra speed even though I can't enjoy the benefits of -O3 & Co. (yet something's telling me JJ can still do it at half the time and twice the speed tho... )

Can I ask you to run the attached executable in your Wine, if at all possible? I'd like to get an idea of speed differences between our HW.

Code: [Select]

#AppType Console
#Include "Canvas.inc"

With Canvas
  .Window("Mandelbrot Zoom", 240, 160) // (c)Tomaaz 09/27/2016
  While .hWnd And Also Rysuj(.Pixels)
    .Refresh()
  WEnd
End With

DynC Rysuj(%pxs)
  #define RGB(r, g, b) (r) << 16 | (g) << 8 | (b)
 
  int main(int* pxs)
  {
    static double powiekszenie = 1.0, przesx = 14.17799995, przesy = 79.999904;
    double a, a2, b, b2, x2, x3, y2, y3;
    int x, y, z, idx;
    unsigned char c, k, l;
   
    double przelx = 3 / (240 * powiekszenie);
    double przely = 2 / (160 * powiekszenie);
   
    for (x = 0; x < 240; x++) {
      x3 = x - 120;
      for (y = 0; y < 160; y++) {
        idx = x + y * 240;
        y3 = y - 80;
        c = a = b = z = 0;
        x2 = przelx * (x3 + przesx * powiekszenie) - 2;
        y2 = przely * (y3 + przesy * powiekszenie) - 1;
        while (c < 255 && z < 4) {
          a2 = a * a - b * b;
          b2 = 2 * a * b;
          a = a2 + x2;
          b = b2 + y2;
          z = a * a + b * b;
          c++;
        }
        if (c == 255)
          c = k = l = 0;
        else {
          k = (c % 50) * 5;
          l = 255 - c;
        }
        pxs[idx] = RGB(c, k, l);
      }
    }
    if (powiekszenie < 1562550000000) {
      powiekszenie += powiekszenie * 0.1;
      return 1;
    }
    return 0;
  }
End DynC

[Mike Lobanovsky]

John,

Frankly I don't see much point in C++/C-to-JS translation. I can hardly imagine myself allowing some third party proggy to translate my DynC or DynAsm routines to LB/LBB. It should be the other way round to make any sense at all.

[ScriptBasic]

It should be the other way round to make any sense at all.

The closes I've come is making C look like BASIC is with my C BASIC effort. (now a Script BASIC extension module standard)

[Tomaaz]

Problem either with JavaScript itself or me and Peter ...

And you say that you  have no problems. ... Once again - I can't understand your problem.

No, so what's your problem guys?

Tomaaz, who's having obvious problems if not you -- alone?

In fact, we all liked your code snippet and the effect that it produced in a very special browser -- the Firefox. We just wanted to point out that it wasn't JavaScript's merit (let it draw on a GDI canvas and see what it's worth), but rather the merit of people who were able to turn it on the fly into highly efficient assembly/machine code coupled with a WebGL canvas. That's exactly what we're discussing with JJ and Peter, just in case you haven't yet guessed for yourself.

1. When rendering Mandelbrot, calculations take majority of time and power, not drawing.
2. This example doesn't use WebGL.
3. You can disable hardware acceleration and it will be working with the same speed.

And of course, it works that fast only in Firefox. I pointed it out several times, so could you please stop acting like I didn't? Unlike other languages (Perl, Python, Ruby, Lua...) JavaScript doesn't have a standard/official interpreter. Yes, you can say that Luajit is faster than standard Lua or that PyPy is faster than official Python interpreter, but the same doesn't apply to JavaScript. So, Firefox "is cheating, trying to fool inexperienced users" as opposed to what? Also, what do you mean by "JavaScrip's merits" in terms of performance? As I said, it doesn't have an official distribution, so it's is as good, as its the best implementation.

Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL

[Peter]

Can I ask you to run the attached executable in your Wine, if at all possible? I'd like to get an idea of speed differences between our HW.

No problem, your program runs fine in Wine 1.6.2, and even then the performance is slightly better than my GL canvas (see screenshot) 

On my system I noticed that the -flto flag (Link Time Optimization) also made a big difference.

Regards
Peter

[Mike Lobanovsky]

No problem, your program runs fine in Wine 1.6.2

You're very nice Peter, thanks a lot!

... and even then the performance is slightly better than my GL canvas (see screenshot) 

That's very flattering too!

Seriously, I don't know how exactly your PIXEL() call is implemented but at least under Windows (probably your Mesa is also capable of doing that) OpenGL would allow us to manipulate Canvas texel data via glTexSubImage2D() and its associated buffers, i.e. to perform the exact same trick of canvasData.data[idx]=/ctx.putImageData(canvasData) used by Tomaaz in his JS and pxs[idx]=/SetDIBitsToDevice(pxs) used by me in my C code. On a 240x160 px canvas, it would spare you some 38,400 (presumably) primitive function calls fast as they may be in a HW assisted OpenGL implementation.

On my system I noticed that the -flto flag (Link Time Optimization) also made a big difference.

I can't comment exhaustively on that one because the early TDM GCC 4.3.3 I'm still using for FBSL compilation doesn't perform such an optimization yet. From what I know theoretically LTO uses some form of internal IL (intermediate language) to allow for inter-module inlining of functions. GCC 4.3.3 can only inline functions within the scope of .o module they are defined in while later GCC versions can also do it at the application global level. Probably something in your language implementation can benefit substantially from that particular optimization too.

[Mike Lobanovsky]

Tomaaz,

You don't have to lecture me on fractal rendering. I've been drawing all sorts of GDI/OpenGL/GLSL Mandel/Julia/Buddha/brots/boxes in multiple dimensions

in FBSL:






in thinBasic:





in OxygenBasic and other languages suitable for the purpose:

1. When rendering Mandelbrot, calculations take majority of time and power, not drawing.

Nope. In 256 iterations per pixel, the pixel draw call will take probably 70% of the time. In 1024 iterations, as ZXDunny once claimed, it's probably gonna be a 50/50 deal, but if you subside to a couple dozen iterations and integer maths, you'll get a blazing fast Mandelbrot whose speed will only be limited to how fast your PRINT works:

2. This example doesn't use WebGL.

Let me decide what does and what doesn't, OK Tomaaz? I'm perfectly suited for the task of determining the underlying technologies by the looks of them. I've got enough personal experience for that, from assembly up to GLSL, if you haven't yet noticed it:

3. You can disable hardware acceleration and it will be working with the same speed.

That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation. There's nothing to accelerate any further, Tomaaz. The devs had already done everything for you before you even formulated the task.

And of course, it works that fast only in Firefox.

Nope. It works exactly as fast in my FBSL GDI canvas as well as in Peter's BaCon OpenGL/Mesa canvas. And I'm stressing again, Jochen's hand written assembly may easily beat the whole bunch of us probably by a factor of two, should he so wish.

Also, what do you mean by "JavaScrip's merits" in terms of performance? As I said, it doesn't have an official distribution, so it's is as good, as its the best implementation.

Exactly. JS isn't a language implementation, it's only a definition of a specific set of grammar rules to be followed adding web interop to your applications. Just like OpenGL isn't a specific .dll or .lib file but rather a specification of the user-side functionality of a unified set of HW assisted APIs to be built into the low level drivers that graphics accelerator vendors supply their GPUs with.

Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL

Hmm, what should I do with this one? I guess I'd rather leave it here just in case someone might find it useful, just like you did.

[Tomaaz]

That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation.

Exactly! That's why this example represents pure JavaScript speed. It would be even better if we reduced interacting with DOM to an absolute minimum or even removed it completely (but, of course, it's nice to see the result on the screen, isn't it? ).

There's nothing to accelerate any further, Tomaaz. The devs had already done everything for you before you even formulated the task.

Yes. The devs of the JavaScript engine did a great job, indeed. Thanks to them I can enjoy JavaScript scripts that runs faster than FreeBASIC compiled code. I'm pretty happy about it. Do you finally get what I mean? I know JavaScript. I can write a script in it. I can run it in Firefox and it runs faster than FreeBASIC programs. I like the situation very much and I salute people who made it possible. If they decided to employ Lord Vader and use The Force to make their engine faster, that's absolutely fine for me. Simply as that.

And of course, it works that fast only in Firefox.

Nope. It works exactly as fast in my FBSL GDI canvas as well as in Peter's BaCon OpenGL/Mesa canvas. And I'm stressing again, Jochen's hand written assembly may easily beat the whole bunch of us probably by a factor of two, should he so wish.

This part shows either that you really can't understand what I'm saying or that you just trying to manipulate my words to prove your point. Because, well... it wasn't very difficult to figure it out that I was talking about my JavaScript code and the fact that it runs that fast in Firefox only and the animation is significantly slower when run in Chromium, IE and Edge. I've never said that this is the fastest Mandelbrot animation possible or that code written in Assembly or C (or anything) wouldn't be able to beat it. All I said it was that I was impressed by what I saw on the screen (Peter kind of agreed with me, so why do you keep bringing his name here?) and that it was faster than the same algorithm compiled with FreeBASIC. The rest is all your imagination.

Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL

Hmm, what should I do with this one?

Read it? 

Let me decide what does and what doesn't, OK Tomaaz?

That explains it all. It's pointless to argue with a God. There is no chance to win, so let's end this farse, here. 

More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)

900x600 example in JavaScript takes on my computer (in Firefox) 120ms to render (almost 6 million iterations). Your example takes 80ms for about the same number of iterations. You win, but don't tell me that Firefox's result isn't impressive. Well, if you worship that God I had discussion with, I will understand that you must obey your master and cannot agree with me.

[jj2007]

900x600 example in JavaScript takes on my computer (in Firefox) 120ms to render (almost 6 million iterations). Your example takes 80ms for about the same number of iterations. You win, but don't tell me that Firefox's result isn't impressive.

That is indeed impressive. I think the Mozilla guys try to distract from their other sins

Well, if you worship that God I had discussion with, I will understand that you must obey your master

Reminds me of an old joke about a guy whose 80th birthday is today: "What's the difference between God and Berlusconi?" - "God doesn't believe he's Berlusconi..." ;-)

[ZXDunny]

That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation.

You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?

I mean, SpecBAS doesn't make use of any Dynarec or JIT whatsoever so can't compete with the speed you guys can achieve and I have to test each pixel plotted by the user for out-of-bounds and such - and a bunch of other things given that you can apply coordinate scaling, clipping and pixel effects - but even so, directly writing pixels out seems like it's an obvious thing to avoid

[Tomaaz]

That is indeed impressive. I think the Mozilla guys try to distract from their other sins

Thank you! And yes - Firefox is not perfect. I use it on Windows and Android, but just took a break from it on Linux. It freezes, crashes and becomes very unresponsive. My main browser on Linux is, at the moment, Chromium.

You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?

Do you mean "host system's"? It sounds a bit confusing to me, but I may be wrong, of course.

[Mike Lobanovsky]

I think the Mozilla guys try to distract from their other sins

If you had the nerve to read the article to the bottom, you surely noticed Update #1 that accuses Chrome of the exact same sin done on twice as large a scope -- 24GB of trash data written to your disk every passing day. I wiped off that piece of bloatware way back when I noticed it wouldn't allow the user to switch off those annoying automatic updates I was seeing three or four times a day 24/7/365, and I never regretted what I did.

You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really? ... directly writing pixels out seems like it's an obvious thing to avoid

Why not? Take Ruben for instance... or TOY... The late Bob Zale was correct saying people may use PowerBASIC to develop other languages (re: thinBasic) but they expressly may not just wrap PB's own design solutions to achieve the same functionality in their derivations.

OTOH there's nothing wrong with using ready-made SetPixelV, MoveTo, LineTo, Rectangle, BitBlt, StretchBlt and other Windows system APIs from time to time to resolve immediate tasks -- they've been especially provided for that purpose by the OS developers -- for as long as you aren't attempting to populate a 900x600 px large canvas with psets alone.

It's pointless to argue with a God. There is no chance to win, so let's end this farse, here.

Absolutely. And if there's anyone who's got to be the first to put an end to the flood you stirred up around my simple phrase "is not JavaScript's merit", so let it be me. See you next time around, Tomaaz.

[ZXDunny]

You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?

Do you mean "host system's"? It sounds a bit confusing to me, but I may be wrong, of course.

Well, no - there's not many interpreters out there that run on bare metal and most are written in C or somesuch language which usually provide (or have access through a third party library) graphical primitives like pset, line etc. As mike says, they're all well and good for the occasional UI element or whatever, but are hardly suited to shoving large amounts of image pixels around.