Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #13378 > unrolled thread

how much computers can do in one second

Back to article view | Back to comp.misc

Contents

  how much computers can do in one second RS Wood <rsw@therandymon.com> - 2017-03-27 14:43 +0300
    Re: how much computers can do in one second Marko Rauhamaa <marko@pacujo.net> - 2017-03-27 15:06 +0300
      Re: how much computers can do in one second Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-29 01:55 +0100
        Re: how much computers can do in one second Marko Rauhamaa <marko@pacujo.net> - 2017-03-29 10:25 +0300
        Re: how much computers can do in one second Richard Kettlewell <invalid@invalid.invalid> - 2017-03-29 08:52 +0100
          Re: how much computers can do in one second Marko Rauhamaa <marko@pacujo.net> - 2017-03-29 12:43 +0300
            Re: how much computers can do in one second Caecilius <nospam@spamless.invalid> - 2017-03-30 16:07 +0100
              Re: how much computers can do in one second Marko Rauhamaa <marko@pacujo.net> - 2017-03-30 19:09 +0300
                Re: how much computers can do in one second Bob Eager <news0006@eager.cx> - 2017-03-30 21:36 +0000
                  Re: how much computers can do in one second Marko Rauhamaa <marko@pacujo.net> - 2017-03-31 09:56 +0300
    Re: how much computers can do in one second Huge <Huge@nowhere.much.invalid> - 2017-03-27 13:51 +0000
    Re: how much computers can do in one second Sylvia Else <sylvia@not.at.this.address> - 2017-03-28 11:57 +1100
      Re: how much computers can do in one second Huge <Huge@nowhere.much.invalid> - 2017-03-28 09:51 +0000
        Re: how much computers can do in one second Bob Eager <news0006@eager.cx> - 2017-03-28 11:12 +0000

#13378 — how much computers can do in one second

http://computers-are-fast.github.io/

Interesting website: they provide sample code and you have to guess how
many iterations a computer can complete in a second.  Example:

#include <stdlib.h>

// Number to guess: How many iterations of
// this loop can we go through in a second?

int main(int argc, char **argv) {
    int NUMBER, i, s;
    NUMBER = atoi(argv[1]);

    for (s = i = 0; i < NUMBER; ++i) {
        s += 1;
    }

    return 0;
}

I underestimated all of them.  There's some good, related discussion on
HackerNews at https://news.ycombinator.com/item?id=13960183.  This stood
out in particular:

	
realo 19 hours ago [-]

Yes, modern computers are fast. How fast?

The speed of light is about 300,000 km/s. That translates to roughly 1
ns per foot (yeah, I mix up my units... I'm Canadian...)

THUS, a computer with a clock speed of 2 GHz will be able to execute, on
a single core/thread, about 4 (four !) single-clock instructions between
the moment photons leave your screen, and the moment they arrive into
your eye 2 feet (roughly) later.

_That_ should give you an idea of how fast modern computers really are.

And I _still_ wait quite a bit when starting up Microsoft Word.

[toc] | [next] | [standalone]

#13379

RS Wood <rsw@therandymon.com>:

> Interesting website: they provide sample code and you have to guess how
> many iterations a computer can complete in a second.  Example:
>
> #include <stdlib.h>
>
> // Number to guess: How many iterations of
> // this loop can we go through in a second?
>
> int main(int argc, char **argv) {
>     int NUMBER, i, s;
>     NUMBER = atoi(argv[1]);
>
>     for (s = i = 0; i < NUMBER; ++i) {
>         s += 1;
>     }
>
>     return 0;
> }

Somewhat related. Here's a similar program to measure how fast the CPU's
32-bit integers wrap around:


========================================================================
#include <stdlib.h>

int main(int argc, char **argv)
{
    int i;
    for (i = 0; i < i + 1; i++)
        ;
    return 0;
}
========================================================================

Without optimization:

    $ cc -o test test.c
    $ time ./test

    real   0m4.880s
    user   0m4.873s
    sys    0m0.001s

With optimization:

    $ cc -O3 -o test test.c
    $ time ./test
    [stuck forever...]

> The speed of light is about 300,000 km/s. That translates to roughly 1
> ns per foot (yeah, I mix up my units... I'm Canadian...)
>
> THUS, a computer with a clock speed of 2 GHz will be able to execute,
> on a single core/thread, about 4 (four !) single-clock instructions
> between the moment photons leave your screen, and the moment they
> arrive into your eye 2 feet (roughly) later.
>
> _That_ should give you an idea of how fast modern computers really
> are.

It's even more impressive when you consider the speed of sound: 340 m/s
(or 256,000 miles per fortnight for you Canadians).

Your computer will be able to execute over 4 million (!) single-clock
instructions between the moment the beep leaves your speaker and the
moment it arrives into your ear 2 feet later.


BTW, is your 2-gigahertz processor executing two instructions per cycle?


Marko

[toc] | [prev] | [next] | [standalone]

#13386

Marko Rauhamaa <marko@pacujo.net> writes:
<snip>
> Somewhat related. Here's a similar program to measure how fast the CPU's
> 32-bit integers wrap around:
>
>
> ========================================================================
> #include <stdlib.h>
>
> int main(int argc, char **argv)
> {
>     int i;
>     for (i = 0; i < i + 1; i++)
>         ;
>     return 0;
> }
> ========================================================================

(You can write this as

  int main(void)
  {
      for (int i = 0; i < i + 1; i++)
          ;
  }

in modern C.)

<snip>
> BTW, is your 2-gigahertz processor executing two instructions per cycle?

Modern machines don't work as simply as that (as I'm sure you know).
The above compiles to an inner loop of 5 instructions and takes (on my
machine) 4.34s for 2^31 iterations.  That's a bit more than 2.4
instructions per ns.  If I simplify the loop to

  for (int i = 0; i >= 0; i++);

it compiles to 3 instructions but takes almost the same time (4.32s).
The lack of optimisation means that i is not in a register so cache
accesses are probably a limiting factor.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13388

Ben Bacarisse <ben.usenet@bsb.me.uk>:

> If I simplify the loop to
>
>   for (int i = 0; i >= 0; i++);

You will likely not trigger the optimization in my code snippet, which
simply replaces

   i < i + 1

with:

   1

> The lack of optimisation means that i is not in a register so cache
> accesses are probably a limiting factor.

The optimized version of my code hangs.


Marko

[toc] | [prev] | [next] | [standalone]

#13389

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Marko Rauhamaa <marko@pacujo.net> writes:
>> Somewhat related. Here's a similar program to measure how fast the CPU's
>> 32-bit integers wrap around:
>>
>>
>> ========================================================================
>> #include <stdlib.h>
>>
>> int main(int argc, char **argv)
>> {
>>     int i;
>>     for (i = 0; i < i + 1; i++)
>>         ;
>>     return 0;
>> }
>> ========================================================================
>
> (You can write this as
>
>   int main(void)
>   {
>       for (int i = 0; i < i + 1; i++)
>           ;
>   }
>
> in modern C.)
>
> <snip>
>> BTW, is your 2-gigahertz processor executing two instructions per cycle?
>
> Modern machines don't work as simply as that (as I'm sure you know).
> The above compiles to an inner loop of 5 instructions and takes (on my
> machine) 4.34s for 2^31 iterations.  That's a bit more than 2.4
> instructions per ns.  If I simplify the loop to
>
>   for (int i = 0; i >= 0; i++);
>
> it compiles to 3 instructions but takes almost the same time (4.32s).
> The lack of optimisation means that i is not in a register so cache
> accesses are probably a limiting factor.

There is very little point analyzing the performance of the programs
quoted above since none of them have well-defined semantics...

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#13390

Richard Kettlewell <invalid@invalid.invalid>:
> There is very little point analyzing the performance of the programs
> quoted above since none of them have well-defined semantics...

The way signed-integer semantics got to be defined in standard C was a
crime against common decency. It keeps on tripping up developers.

Mental note: never do signed-integer arithmetics in C. Do your
calculations unsigned and just cast the final result to a signed type.


Marko

[toc] | [prev] | [next] | [standalone]

#13392

On Wed, 29 Mar 2017 12:43:07 +0300, Marko Rauhamaa <marko@pacujo.net>
wrote:

>Richard Kettlewell <invalid@invalid.invalid>:
>> There is very little point analyzing the performance of the programs
>> quoted above since none of them have well-defined semantics...
>
>The way signed-integer semantics got to be defined in standard C was a
>crime against common decency. It keeps on tripping up developers.
>
>Mental note: never do signed-integer arithmetics in C. Do your
>calculations unsigned and just cast the final result to a signed type.
>
>
>Marko

I've found the opposite: it's easy to get tripped up by unsigned
arithmetic in C because of the wraparound behaviour for negative
numbers.  I've been caught out by this once or twice when I was sure
the end result would always be positive, but an intermediate result
was negative which made the final result a huge and completely
incorrect answer.

[toc] | [prev] | [next] | [standalone]

#13393

Caecilius <nospam@spamless.invalid>:

> On Wed, 29 Mar 2017 12:43:07 +0300, Marko Rauhamaa <marko@pacujo.net>
> wrote:
>>Mental note: never do signed-integer arithmetics in C. Do your
>>calculations unsigned and just cast the final result to a signed type.
>
> I've found the opposite: it's easy to get tripped up by unsigned
> arithmetic in C because of the wraparound behaviour for negative
> numbers. I've been caught out by this once or twice when I was sure
> the end result would always be positive, but an intermediate result
> was negative which made the final result a huge and completely
> incorrect answer.

I think a C programmer needs to be very comfortable with 2's-complement
arithmetics.

In a nutshell, addition, subtraction and multiplication are well-behaved
under 2's-complement arithmetics. IOW, there's no difference between
signed and unsigned operations. (Division is another story.)

A C programmer also needs to regularly depend on the benign wrapping
behavior of (unsigned) integers. For example, you can safely implement a
ring buffer by incrementing the read index and the write index as long
as the size of the ring buffer is a power of 2. Similarly, you can
derive the number of open connections from the ever-increasing open and
close counts with a simple subtraction.


Marko

[toc] | [prev] | [next] | [standalone]

#13394

On Thu, 30 Mar 2017 19:09:47 +0300, Marko Rauhamaa wrote:

> A C programmer also needs to regularly depend on the benign wrapping
> behavior of (unsigned) integers. For example, you can safely implement a
> ring buffer by incrementing the read index and the write index as long
> as the size of the ring buffer is a power of 2.

Bad programming style though. Use the modulus operator or just test the 
value.


-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#13395

Bob Eager <news0006@eager.cx>:

> On Thu, 30 Mar 2017 19:09:47 +0300, Marko Rauhamaa wrote:
>
>> A C programmer also needs to regularly depend on the benign wrapping
>> behavior of (unsigned) integers. For example, you can safely
>> implement a ring buffer by incrementing the read index and the write
>> index as long as the size of the ring buffer is a power of 2.
>
> Bad programming style though. Use the modulus operator or just test
> the value.

Disagree.

The situation is remotely analogous to solving the roots of the cubic
function (<URL: https://en.wikipedia.org/wiki/Cubic_function#Derivat
ion_of_the_roots>). In the 16th century, people were uneasy about the
fact that Cardano's formula yielded the correct (real) results but
involved taking square roots of negative numbers.

Later, this blemish was found to be a great feature. You couldn't have
modern mathematics without complex numbers.

Similarly, you couldn't have C programming without 2's complement modulo
arithmetics.

I once reported a bug in LXPanel (<URL:
https://wiki.lxde.org/en/LXPanel>). Its CPU monitor would stop working
after a few months of use on a 32-bit machine. The root cause was the
behavior of sscanf("%u"). LXPanel would read two numbers from a /proc
file and take the difference. After some time, the ever-increasing
numbers would overflow the 32-bit range. Unfortunately, the sscanf()
function chooses to return UINT_MAX in that situation, which results in
a zero difference between the values.

If sscanf() had just calculated the number naïvely:

    while (...) {
        number = number * 10 + c - '0';
        c = next(...);
    }

the overflow would have behaved gracefully under the difference.


Marko

[toc] | [prev] | [next] | [standalone]

#13380

On 2017-03-27, RS Wood <rsw@therandymon.com> wrote:

[33 lines snipped]

> THUS, a computer with a clock speed of 2 GHz will be able to execute, on
> a single core/thread, about 4 (four !) single-clock instructions between
> the moment photons leave your screen, and the moment they arrive into
> your eye 2 feet (roughly) later.

:oO

-- 
Today is Sweetmorn, the 13th day of Discord in the YOLD 3183
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#13382

On 27/03/2017 10:43 PM, RS Wood wrote:
>
> http://computers-are-fast.github.io/
>
> Interesting website: they provide sample code and you have to guess how
> many iterations a computer can complete in a second.  Example:
>
> #include <stdlib.h>
>
> // Number to guess: How many iterations of
> // this loop can we go through in a second?
>
> int main(int argc, char **argv) {
>      int NUMBER, i, s;
>      NUMBER = atoi(argv[1]);
>
>      for (s = i = 0; i < NUMBER; ++i) {
>          s += 1;
>      }
>
>      return 0;
> }
>
> I underestimated all of them.  There's some good, related discussion on
> HackerNews at https://news.ycombinator.com/item?id=13960183.  This stood
> out in particular:
>
> 	
> realo 19 hours ago [-]
>
> Yes, modern computers are fast. How fast?
>
> The speed of light is about 300,000 km/s. That translates to roughly 1
> ns per foot (yeah, I mix up my units... I'm Canadian...)
>
> THUS, a computer with a clock speed of 2 GHz will be able to execute, on
> a single core/thread, about 4 (four !) single-clock instructions between
> the moment photons leave your screen, and the moment they arrive into
> your eye 2 feet (roughly) later.
>
> _That_ should give you an idea of how fast modern computers really are.

A lot of that power goes into O(n^2) or worse algorithms when O(1), or 
at worst O(n) algorithms exist.

Let me coin "Sylvia's" law - the level of programmer incompetence is 
proportional to the speed of the CPU.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#13383

On 2017-03-28, Sylvia Else <sylvia@not.at.this.address> wrote:

[44 lines snipped]

> Let me coin "Sylvia's" law - the level of programmer incompetence is 
> proportional to the speed of the CPU.

It's a sub-clause of Parkinson's Law; tasks expand to consume the resources
allocated to perform them.


-- 
Today is Boomtime, the 14th day of Discord in the YOLD 3183
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#13384

On Tue, 28 Mar 2017 09:51:23 +0000, Huge wrote:

> On 2017-03-28, Sylvia Else <sylvia@not.at.this.address> wrote:
> 
> [44 lines snipped]
> 
>> Let me coin "Sylvia's" law - the level of programmer incompetence is
>> proportional to the speed of the CPU.
> 
> It's a sub-clause of Parkinson's Law; tasks expand to consume the
> resources allocated to perform them.

Yes, I've used that in lectures for many years, although I tend to say 
"corollary"! Not sure which is more appropriate.

(I used to dine with Parkinson, but don't think I ever mentioned it to 
him)

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web