Also, though good compilers won't set aside storage for const objects of integer types...
A slightly more correct statement would be that compilers wouldn't set aside data memory for const objects of integer type: they would trade it for program memory. There is no difference between the two under Von Neumann architecture, but in other architectures, such as Harvard, the distinction is rather important.
To fully understand what's going on, you need to recall how assembly language loads data for processing. There are two fundamental ways to load the data - read a memory from a specific location (so called direct addressing mode), or set a constant specified as part of the instruction itself (so called immediate addressing mode). When compiler sees a const int x = 5
declaration followed by int a = x+x
, it has two options:
- Put 5 in a data memory, as if it were a variable, and generate direct load instructions; treat writes to x as errors
- Each time the
x
is referenced, generate an immediate load instruction of the value 5
In the first case you will see a read from x
into the accumulator register, an addition of the value at the location of x
to accumulator, and a store into the location of a
. In the second case you will see a load immediate of five, an add immediate of five, followed by a store into the location of a
. Some compilers may figure out that you are adding a constant to itself, optimize a = x+x
into a = 10
, and generate a single instruction that stores ten at the location of a
.
How is it possible to reduce an image by 90% without losing quality?
Formats and compression options
There are three popular image storage formats for web (not counting the promising WebP), and each format has its own compression options.
A clueless coder may pick the wrong format and use wrong options, resulting in less-than-optimal image quality and huge size. An experienced graphical designer is expected to know which format and options should be used, resulting in high quality images with low bandwidth footprint.
Let's see how it works.
Example 1: 90% reduction
The first example is a photo. Nearly every photograph is stored in JPEG, but an inexperienced coder may hear somewhere that PNG is the best format, and prefer using PNG. This is what happens:
Open image in new tab to see the full-size 2470×1636 version.
The size of this PNG image is 5 992 591 bytes—nearly 6 MB, enough to make both the server bandwidth and your customers unhappy.
Open image in new tab to see the full-size 2470×1636 version.
Here is the same image exported as JPEG. The JPEG compression level was thoughtfully adjusted to avoid losing visual quality: watching the images side by side, you normally can't tell which one is which.
The size of the JPEG image is 700 283 bytes, that is 683 KB: 11.7% compared to the PNG variant. We indeed achieved nearly 90% compression without affecting the quality of the image.
Example 2: 80% reduction
Now the clueless coder is convinced that JPEG images are much smaller than PNG ones, so he's using JPEG for everything. When he needs to store a logo, he chooses JPEG.
Open image in new tab to see the full-size 1300×850 version.
Since lower compression levels make JPEG artifacts noticeable, he should push the levels up to 100—lowest compression, highest file size. He obtains a 68 348 bytes file (67 KB).
A more experienced graphical designer prefers PNG. Here's the result.
Open image in new tab to see the full-size 1300×850 version.
By carefully adjusting the options, i.e. using a 8-bit PNG with 128 colors, he obtains the same visual result in a file which weights only 13 930 bytes (14 KB), that is 20.4% of the JPEG variant, that is a compression of approximately 80%.
Important notes about the examples
Although those examples show a difference of 80% to 90%, a really clueless coder may do worse. I knew people who were storing images in BMP format and were actually paid to create websites. There is always a way to screw things up and to achieve unnecessarily huge sizes without any visible gain in quality.
Having said that, both examples illustrate exactly what can actually happen when the website is done by inexperienced web designer or web developer.
The fact that many persons are using wrong tools makes things even worse. In those examples, I've used Photoshop to export the images in both formats. I would expect that different applications may perform differently when it comes to rendering final images, resulting eventually in poor quality coupled with excessive file size.
Why isn't such a practice more popular in web development?
Who is Smush.It actually for?
Since we now understand how formats and compression options work and how are they enabling us to reduce the size of an image by 80% or 90% without losing quality, let's see what is the actual value of Smush.It and who should use it.
Is it:
For large projects made by teams of highly specialized and skillful persons?
Probably not. Those persons can afford buying a Photoshop license and know what formats and options should they use for different images. They won't need Smush.It, because the size of their images is already as small as possible.
From there, either Smush.It will make some changes resulting in the loss of quality—something those persons want to avoid at all costs, or it will have no impact.
This is confirmed by the website itself, which is very unfriendly. As a developer, I don't want my images to be magically changed: I want to know what were the changes and all the magic which happened under the hood. I don't want to use voodoo services: I need to know exactly what happens with my images, especially in order to learn from that.
There might be some information on their FAQ page, but since it doesn't work, we'll never know.
Blogs are not helpful either. There is one blog which mentions a gain of 4.79%, but this would be practically unnoticeable on most websites. The only mention of what actually happened under the hood is that Smush.It switched from GIF to PNG—something the developers should have be doing on their own if only they knew formats and compression options.
For small projects made by inexperienced coders?
Indeed, those coders don't know how to store images in the first place and don't care about the magic under the hood.
But it's not for them either. Chances are, they simply don't care, and they have more important issues, such as the lack of client-side caching, the lack of CSS/JavaScript minification or the lack of Gzip compression.
The only two cases I can think of are:
An inexperienced programmer who wants to impress his boss. He doesn't know how to store images properly, but he knows that there is a tool which does all the voodoo magic for him. Result: he can make himself valuable in a company as a guy who was able to reduce the bandwidth because of his deep knowledge of online tools.
A boss who learned about a new tool and wants to use it everywhere.
Best Answer
Nearly all CPUs have a single instruction that will return the modulus of a value. For instance, consider this program:
If I compile this on my Intel OS X machine using g++ -S, the result will be some boilerplate and this:
The actual modulus happens with this instruction:
idivl %ecx
. When this instruction executes, the quotient will be placed in in%eax
and the remainder will be placed in in%edx
.Since really, this means the
%
operation is only going to take a few clock cycles, the bulk of which is actually moving the data into the right register. Also note that with Intel at least, the same operation finds both the quotient and the remainder, so in reference to your comment,/
and%
take exactly the same time. It is the same operation. The only thing that changes is what register the compiler gets the results from.With any CPU made in the last couple decades, you can assume that any basic mathematical operation (including things that look like library functions like
sqrt
orcos
) is actually a single machine instruction and generally only take a few clock cycles at most.[UPDATE]
As people have noted in the comments, to see something approaching a correct timing, you need to remove the output from the timed section like this:
But even that is likely not accurate as the actual granularity of the timings may exceed what you are trying to time. Instead, you might want to do this:
Then divide your timing by 1,000,000. (This will be slightly high as it includes the time taken for an assignment, a comparison and an increment.) On my machine, this gives a time of 5 nanoseconds.