-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparisons #1
Comments
Hi @tbreloff, Part of Plots: Cool :). Targeted application I find that being able to quickly/easily pan/zoom into your data is essential to figuring out what's going on during the design process. This helps in quickly isolating the condition where undesired behaviour is happening. Did I do any benchmarks? The reason for this slowness varies from tool-to-tool:
With my sample plots, I found InspectDR to have roughly the same performance of GR.jl... though a proper apples-to-apples experiment has not yet been set up. Interactivity
More on load times I find pre-compiled modules don't help much here. I believe it is because many of the functions are not of concrete types... and so don't precompile until actually used. Even Gtk/Cairo seems a bit slow to load up with the functions I use in InspectDR. I found the best solution is to not depend on too many modules. Issues with GR Writing to PNG is slow, for some reason (much faster to write to SVG). This is very uncharacteristic of GR. At the end of the day, I decided the current GR architecture to be impractical for me to write a GUI wrapper around GR in an attempt to make it more interactive. MA |
This is really great. Thanks for writing it up! I might link to this from On Friday, May 20, 2016, ma-laforge notifications@github.com wrote:
|
I have no problem with that, but also feel free to write it in your own words. I like your section on backends - expecially the table "For the impatient". Choosing a plotting backend would have been more pleasant a few months ago if I had this information. MA |
Just FYI, GtkUtilities.jl contains generic panning and zooming facilities, and Immerse.jl offers some Gadfly-based interactivity. Seems like you already have what you want here, but if not, just FYI. |
Hi @timholy GtkUtilities I have not yet implemented a "minpixels" on my box zoom... so I am contemplating switching over to GtkUtilities when I improve it. Reservations Gadfly After re-testing with a recent version of Immerse, I am not sure it is as bad as I remember it - at least not any more. Immerse+InspectDR At the end of the day, I wanted to get InspectDR built up as quickly as possible, so I opted for a solution where I did not have to figure out how to integrate with Immerse. Immerse+Gadfly I like that you can double-click instead of scrambling for the "1" button every time you need to zoom out to full. However, after using 3D tools like HFSS/EMPro/Sketchup/..., I don't understand why we can't use efficient/"standard" pan/zoom methodologies with 2D plots. Ex:
Immerse Bug? Immerse compile time Immerse load up time
Comparing user experience My (admittedly coarse) benchmarks indicate that InspectDR has comperable performance to GR.jl. I don't know if you have experience with GR - but I think @tbreloff can confirm that it is quite atypical! For a simple apples-to-apples comparison with InspectDR, you can use the following code:
Regards, MA |
Interesting. If one can actually put numbers on that, it could be quite an interesting discovery. It's a bit of a subtle question because there are really two issues: one is precompiling for specific types, and the other is caching the lowered code. For the latter, I can't think of a reason why splitting things into two packages should make it slower to load (unless there is a bug, which perhaps there is). For the former, there is indeed an issue: julia won't save machine-compiled code that spans modules. However, this should not affect load time, only latency to first execution.
I don't recommend trying to integrate with Immerse; Immerse is tightly interwoven with Gadfly, but current Gadfly is going through some growing pains due to apparent loss of maintainer. Unless the Gadfly situation changes, Immerse may have to change course someday or just rust away. So you may have been very wise to strike out on your own.
Hmm, that's strange. You zoomed in first, right?
Yep. These are basically problems with Gadfly---Immerse is just an interactivity wrapper around Gadfly. |
Tim: Can you expand on this comment (or point to existing docs/issues): For the former, there is indeed an issue: julia won't save On Saturday, May 21, 2016, Tim Holy notifications@github.com wrote:
|
Unfortunately, this is beyond my understanding of Julia's internals at this time. I do not think I can add much here.
Agreed. Poor choice of words.
Yes. Using Linux / Julia v0.4.2 / Immerse 0.0.11
I figured that might be the case. |
@tbreloff, to clarify, I'm only talking about what happens if you have explicit Now, Gadfly happens to contain a file that issues a really large number of Hope that helps clarify the situation. Of course, the joy of open source means that things could be changed, but this is how things work now. |
Thanks for writing that out Tim... I certainly learned something today! On Sunday, May 22, 2016, Tim Holy notifications@github.com wrote:
|
Thanks for the crash course. I will try to comment now.
Really? Not even when the types are concrete? That might affect how I code in the future.
I will have to learn how to use this soon.
Could this issue not be circumvented by defining a local function
This potentially adds a level of indirection in Julia, but should be acceptable for a large class of applications. As for the original discussion
Agreed (at least not a direct reason). Rather, I believe what happens is that packages builders intrinsically try to provide generic functions (which is good) - and might not want to precompile too many specializations so as to not hinder load times. This leads the module user (client module) without machine code for its required specializations... unless there is a way for the client module to induce precompilation of the functions from the "service module".
Ok, but you still have to compile that code if it is in your own module... Sure, but you often build much simpler structures, and Julia has to pick from much fewer function signatures... not to mention it no longer has to resolve all the indirect function calls (which can only be determined once the types are known). Another observation That means that when I am building "complex" software composed of multiple modules, precompilation significantly slows down the development process: Editing one of the base (i.e. "service") modules triggers a very slow chain of pre-compilation. Testing moves alot faster when precompilation is disabled on all modules under development... but then I forget to re-enable precompilation. |
Right. It won't generate native code unless you make it. You can check this with __precompile__()
module CC
bar(x::Float64) = 2x
precompile(bar, (Float64,))
end and then look at the
What do you mean by "demanding"? The algorithm won't run any faster; the only issue is whether you have to wait for it to compile the first time you use it. The second time you use it, it will be the same whether it was precompiled or not. If your local
Yes. On julia-0.5, you can run it as |
Excellent. Thanks for showing me this. I wonder: why doesn't Julia automatically precompile functions with concrete signatures? Is the idea to anticipate people leaving dead code in their modules?
I meant any function that will take noticeable time to compile downto machine code... as opposed to the trivial compilation of I must admit, though: Many implementations of
Excellent. That is good to know. |
How does it compare to GLVisualize? |
When I first developped InspectDR, I might have been unaware that GLVisualize existed (but I believe I was unable to get it running at that time). Here are the differences as far as I can tell right now:
Caveat: I should probably give GLVisualize another try some time soon. I am not fully aware of all of its capabilities. |
Hi @ma-laforge welcome to the plotting club. 😎 I'm curious what sort of work you focus on that something like GR didn't work for you. Have you done any benchmarks of speed/response? I'd love to hear your take on the current plotting selections.
I think it's great to solve real-time, time-based, interactive plotting. I'll keep an eye on the package, and maybe it might make sense at some point to think about adding it as a Plots backend. Best of luck!
The text was updated successfully, but these errors were encountered: