On 3 April 2013 17:53, Gary Verhaegen <gary.verhae...@euranova.eu> wrote: > Do you really need ratios ? > > Intuitively, the management of ratios should be much more of a problem > than the use of BigInts, performance-wise. You did not provide many > details on the calculations you are trying to do, but I would advise > you to really look at floating point numbers and usual ways to limit > their imprecision (avoiding subtractions etc.); that would be much > faster, as Clojure is able, under the right circumstances, to emit > native operations on native primitive types. > > Plus, with the latest version of Leiningen, you can globally set > variables such as *unchecked-math*. Clojure can be *fast* for numerics > : > http://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html > > On 3 April 2013 17:29, Peter Mancini <peter.manc...@gmail.com> wrote: >> Those are good answers and it is acceptable, but what ends up happening is >> that it creates objects. I just used a profiler and that operation inside of >> my code for a typical run is executed 1,500 million times. It makes up the >> lions share of self-time measurements. Each object needs construction, >> destruction and garbage collection even though internally it may be using a >> primitive type. I'm working with large data structures and doing a lot of >> math (mainly matrix math) and so this is where I am getting slaughtered in >> performance. As confirmed by Clojure Programming there is contagion >> afterwards where everything afterward touched by those numbers becomes >> BigInt. >> >> I'm working on rethinking how I am doing the math so that it doesn't produce >> so many objects. I think that doing it in the order that the sane looking >> algebra is laid out makes for readable code but the object contagion is >> robbing my program of speed. Since a true production run will end up being a >> million million of these types of operations I need to reconsider how I am >> going to lay this out. >> >> A couple of ideas come to mind such as delaying the use of division or >> pre-calculating the range of division results since there would only be a >> few of them. It's really interesting looking at performance for something >> simple that is going to be called so many times. >> >> Thanks for the information so far. >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >>
-- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
