I have quite a few bits of code where a bad branch predictor in a tight inner loops makes code 10x slower.
you are welcome to do your own experimentation so that you too can learn by branches are bad in tight loops. (even if the branch predictor is doing its job, there will be a measurable slow down, albeit less than 10x)
Please shift this conversation to the libraries list if you want to actually make a concrete libraries change proposal. Otherwise I don't understand your contentions. Int is "native register sized integer" not "integer that i need to exception handle because I used int instead of integer because of premature optimization in my web app or project euler codes"
My opinions are based upon spending all of my time over the past year working on writing robustly performant numerical codes. Some of them are actually faster than the standard fortran ones.
My point being: as mentioned above, by others much more articulate than I, unless you have performance related reasons, always use Integer instead of Int. There is never a good reason to use Int instead of Integer unless it will change the performance characteristics of your code. Asking for Int to pretend to be Integer because you wanted to do premature optimization and then it didn't behave like Integer is a no go.
I am happy to direct you towards further reading if you'd like to learn about writing performance sensitive software:
the
intel optimization manual has many good ideas (eg Structure of Arrays, which is essentially used by the haskell Vector lib) that are actually realized by the more performant haskell libraries.
Likewise, for an informative idea of the cost models for various operations on the CPU, the
agner fog manuals are actually very educational.
merry hacking
-Carter