Is that the case? I've never profiled it actually. I always just assumed that basic operations (float and int) were all single cycle since there is such a huge incentive to optimize those on the CPU.
Random tangent: a while ago I was working on a project where we used a big fancy MCMC algorithm to do some computer vision task. One issue we ran into was that double types didn't have enough precision to compute the partition function. We spent along while trying to figure out a way around having to compute it, and put in 10-20k lines of C++ code to make it happen. Really complicated. Took forever. One day I had the rather silly idea to just use an arbitrary precision floating point library. It was a silly idea because we profiled it and found that it was 20x slower for all floating point computations which seemed to be the bulk of the algorithm (and performance REALLY mattered here.) I decided to try it out on the theory that 90% of the CPU time was spent on memory access, looping, and program jumps, and that even though we had a ton of floating point operations, they were basically free. So I implemented it, and as it turned out we did indeed get a 20x slowdown on our floating point computations. But the overall algorithm only lost about 1% or so, because the floating points stuff only constituted a tiny fraction of the total cost. Since then I just ignore the cost of arithmetic and focus 100% on optimizing program flow. Almost seems obvious in retrospect, but I still see code where people jump through hoops to save a few multiplications, even though in the end it usually costs them more due to cache misses inherent in loops and program jumps.