On 3 Apr., 13:35, mabshoff <[EMAIL PROTECTED]> wrote: > On Apr 2, 10:58 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: > > > This is very interesting. I actually implemented something along these > > lines (but not near as complete) before implementing the fast_float > > stuff. Clearly nothing is going to beat custom-crafted C, but you've > > given me some motivation to speed up my fast-float code some more :). > > > One reason I gave up on the invoke-the-compiler method is it just > > seemed too heavy-weight for the task, both in terms of dependancies > > (gcc, cython, at writeable temporary directory, getting all the > > compile-time flags right) > > Yep, and since there are also a bunch of Sympy users on Windows some > of the assumptions about the presence of gcc might not hold. Sage is > getting ported to MSVC and not having to need a compiler for fast_eval > is a big plus since the presence of MSVC cannot be assumed. That will > also break Cython, but if one is using Cython one should be aware of > the fact that you need a compiler :)
I'll try to port it to Windows/MinGW during the next weeks (my free time is currently quite limited). MSVC is not really an option, but it could be possible somehow... Well, and I wrote it actually for sympy (which as no fast_float), not for sage (of course it can be used there, but it's not really necessary imo). Replacing fast_float was never my intention. I did not even know of it when I wrote my code. :) > > > and also, in terms of overhead (at 2 > > microseconds savings/eval, one has to evaluate the function 500,000 > > times to break even with the 1 second lag, and it falls behind if I'm > > only evaluating tens of thousand of points). Another advantage is that > > other functions (for example integration and plotting) can use the > > _call_c C method which avoids all python overhead (which can be a > > substantial savings). > > I also agree with Robert here that in most cases [at least for the > usage pattern we see] it seems hardly worth it due to compile time > overhead. But it is nice work nonetheless. Cython + gcc are taking about 0.4 s (relatievly independent of the function's complexity), the rest is Python's/SymPy's fault. And functions are only compiled once. They rest in your temporary directory and can be reused unless you change the function or your system gets rid of them. Think of them as a kind of module you have to import (like from numpy import * which is taking much more than 1 s). Disk usage is bad, but on Linux it's at least cached. On Windows we could use a RAM disk (natively supported since 95) ;). Anyway, I spent no time on optimzing anything, so we'll see. BTW: Defining a function in sage, which is complex enough to take about 1 s to compile, lags. This eats the speed advantage of fast_float (or can it be used with strings instead of sage expressions?). There are some other bottlenecks... Not to mention the "root of all evil" ;). > > I'm not trying to dissuade you from using this code, it looks good and > > is really fast, but figured I'd throw my thoughts on the topic out > > there. > > > - Robert > > Cheers, > > Michael Thoughts are quite welcome, including disagreement of course. :) Indeed, thank you! Cheers, Vinzent --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
