Am 11.02.2015 um 13:09 schrieb Felix Winkelmann: >>>> Personally I'd be more than happy to take the performance >>>> hit on this so long as I can rely on fx operations and/or >>>> (declare fixnum-arithmetic) to recover the original performance. >>> >>> You can; I didn't change any of those. The "fixnum mode" probably >>> still works, too (as in "(declare fixnum)"), but I didn't test it. >> > > I recommend to get rid of "fixnum-mode" - this brings up serious > problems in code that uses external libraries, similar to the case > when non-numbers code uses libraries that use numbers (and vice > versa). Fixnum-mode will assume that all numbers are fixnums (without > checking for this). It is seldom used
Uhm. I'm using it a lot. Together with type annotations. Can't recall any related problems in around ~80KLOC single project. Seems not that dangerous to me. > accordingly, so nothing is won, because the speed advantage of fixnum > math is that we can avoid the CPS calls and cram more numerical > operations into a single CPS-converted function. That's why I'm using it so much. > Personally, I find the performance impact Peter reported unacceptable, > and something has to be done about it before we commit on > numbers-integration. But that's just _my_ opinion. I'd regret loosing so much performance too. At worst it might leave me stuck with the 4.0 branch. But if fixnum-mode is such a burden to keep avail, I'm short of any recommendations. Best /Jörg _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
