On Thu, Dec 16, 2010 at 12:13 PM, Stuart Halloway <stuart.hallo...@gmail.com> wrote: >>>> Worse, from the sounds of it the new + isn't exactly the old >>>> unchecked-+; it still checks for overflow rather than allowing >>>> wrapping. That's going to add a compare-and-branch to every add >>>> instruction and halve the speed of those operators on typical >>>> hardware. Compare-and-throw-exception is hardly superior to >>>> compare-and-box-in-BigInteger, since it's still slow AND now some >>>> arithmetic code that used to work but be slow will now explode in your >>>> face. >>> >>> This argument is based on the (provably wrong) presumption that "still >>> slow" means "equally slow". The difference is percentage points vs. order >>> of magnitude. Test it for yourself. >> >> That does not make sense, since the implementations in both cases have >> to test for overflow and branch. In the "overflowed" branch further >> expensive actions are taken -- in both cases the creation of a Java >> object, for instance (an exception or a boxed numeric). These branches >> might differ in other ways in speed, but they're the rare case. The >> common case is test and accept the result, returning it, in both >> cases; so the common case should have comparable execution speed given >> both implementations. If not, something is wrong someplace else with >> at least one of the implementations (or, much less likely, with the >> JVM/JIT). > > It will make sense once you understand
I don't care for your condescending tone. If you have a personal problem with me, please take it up in personal email rather than posting it to the list. Thank you. Now, as I understand it, + and the like, being normal Clojure functions (rather than, say, special forms or interop calls), take and return boxed values. So boxing overhead is unaffected by all this. We have a function that, say, takes two Integers, sees if the result overflows, and if not adds them and returns the boxed result, and if it does overflow, either throws an exception or returns a BigInteger rather than an Integer. The check should be about the same speed in either case. Now, BigInteger contagion could slow things down, but it would only do so in the case where the proposed changes result in exceptions being thrown (= breakage, in the case of old code that assumes BigInteger promotion will happen instead). So, some code won't slow down or speed up appreciably; other code would speed up if the behavior was to wrap the value but will instead simply not work now. I still confess I don't see a big advantage here. -- 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
