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

Groups > linux.debian.user > #201657 > unrolled thread

which program can test cpu speed

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  which program can test cpu speed Long Wind <longwind2@yahoo.com> - 2018-10-26 05:10 +0200
    Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 08:00 +0200
      Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 10:30 +0200
        Re: which program can test cpu speed arne <sp113438@telfort.nl> - 2018-10-26 10:50 +0200
          Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 11:00 +0200
            Re: which program can test cpu speed arne <sp113438@telfort.nl> - 2018-10-26 11:10 +0200
      Re: which program can test cpu speed Long Wind <longwind2@yahoo.com> - 2018-10-26 10:30 +0200
      Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 16:00 +0200
        Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 16:40 +0200
          Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 17:10 +0200
            Re: which program can test cpu speed David Wright <deblis@lionunicorn.co.uk> - 2018-10-26 20:50 +0200
              Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 21:20 +0200
          Re: which program can test cpu speed Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-10-26 20:00 +0200
            Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 20:20 +0200
              Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 22:20 +0200
      Re: which program can test cpu speed mick crane <mick.crane@gmail.com> - 2018-10-26 16:30 +0200
        Re: which program can test cpu speed Reco <recoverym4n@enotuniq.net> - 2018-10-26 16:40 +0200
    Re: which program can test cpu speed Jörg-Volker Peetz <jvpeetz@web.de> - 2018-10-26 10:40 +0200
    Re: which program can test cpu speed Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-26 14:40 +0200
      Re: which program can test cpu speed Long Wind <longwind2@yahoo.com> - 2018-10-26 19:30 +0200
        Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 20:10 +0200
          Re: which program can test cpu speed Michael Stone <mstone@debian.org> - 2018-10-26 20:50 +0200

Page 1 of 2  [1] 2  Next page →

#201657 — which program can test cpu speed

[Multipart message — attachments visible in raw view] — view raw

any package that test cpu/system speed and report benchmark?
i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think they're about same speed

[toc] | [next] | [standalone]

#201659

	Hi.

On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
> any package that test cpu/system speed and report benchmark?
> i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think they're about same speed

Why would you need a *program* to do that then you have Linux kernel
already?

grep bogomips /proc/cpuinfo

Reco

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

#201662

	Hi.

On Fri, Oct 26, 2018 at 08:17:31AM +0000, Long Wind wrote:
> Thank Reco!

You're welcome.


> intel get higher mark than amd

That's expected. You need raw CPU power - you buy Intel.


> but could you explain a little about your command and bogomips?
> i can't find manual about such info.

I feel uneasy for doing this, but - [1].

Reco

[1] https://en.wikipedia.org/wiki/BogoMips

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

#201665

On Fri, 26 Oct 2018 11:26:13 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Fri, Oct 26, 2018 at 08:17:31AM +0000, Long Wind wrote:
> > Thank Reco!  
> 
> You're welcome.
> 
> 
> > intel get higher mark than amd  
> 
> That's expected. You need raw CPU power - you buy Intel.
> 

You need power buy AMD threadripper: 64 threads

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

#201667

	Hi.

On Fri, Oct 26, 2018 at 10:42:53AM +0200, arne wrote:
> On Fri, 26 Oct 2018 11:26:13 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > 	Hi.
> > 
> > On Fri, Oct 26, 2018 at 08:17:31AM +0000, Long Wind wrote:
> > > Thank Reco!  
> > 
> > You're welcome.
> > 
> > 
> > > intel get higher mark than amd  
> > 
> > That's expected. You need raw CPU power - you buy Intel.
> > 
> 
> You need power buy AMD threadripper: 64 threads

If I ever need many threads, I'll buy Xeon.
If I ever need enormous amount of threads, I'll buy UltraSPARC.
If I ever need good single CPU - there's IBM's Power for that.
If I need low TDP - there are ARM and MIPS.

AMD just does not fit anywhere.

Reco

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

#201668

On Fri, 26 Oct 2018 11:54:26 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Fri, Oct 26, 2018 at 10:42:53AM +0200, arne wrote:
> > On Fri, 26 Oct 2018 11:26:13 +0300
> > Reco <recoverym4n@enotuniq.net> wrote:
> >   
> > > 	Hi.
> > > 
> > > On Fri, Oct 26, 2018 at 08:17:31AM +0000, Long Wind wrote:  
> > > > Thank Reco!    
> > > 
> > > You're welcome.
> > > 
> > >   
> > > > intel get higher mark than amd    
> > > 
> > > That's expected. You need raw CPU power - you buy Intel.
> > >   
> > 
> > You need power buy AMD threadripper: 64 threads  
> 
> If I ever need many threads, I'll buy Xeon.

You can compare:

https://img.purch.com/r/711x457/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9ILzAvNzkxMTcyL29yaWdpbmFsL2ltYWdlMDA0LnBuZw==

> If I ever need enormous amount of threads, I'll buy UltraSPARC.
> If I ever need good single CPU - there's IBM's Power for that.
> If I need low TDP - there are ARM and MIPS.
> 
> AMD just does not fit anywhere.
> 
> Reco
> 

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

#201663

[Multipart message — attachments visible in raw view] — view raw

 Thank Reco!

intel get higher mark than amd
but could you explain a little about your command and bogomips?
i can't find manual about such info.

    On Friday, October 26, 2018, 1:57:55 PM GMT+8, Reco <recoverym4n@enotuniq.net> wrote:  
 
     Hi.

On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
> any package that test cpu/system speed and report benchmark?
> i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think they're about same speed

Why would you need a *program* to do that then you have Linux kernel
already?

grep bogomips /proc/cpuinfo

Reco

  

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

#201678

On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
>Why would you need a *program* to do that then you have Linux kernel
>already?
>
>grep bogomips /proc/cpuinfo

Anyone reading that advice: ignore it. You cannot use bogomips to 
meaningfully compare processors.

Mike Stone

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

#201684

	Hi.

On Fri, Oct 26, 2018 at 09:59:16AM -0400, Michael Stone wrote:
> On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
> > Why would you need a *program* to do that then you have Linux kernel
> > already?
> > 
> > grep bogomips /proc/cpuinfo
> 
> Anyone reading that advice: ignore it. You cannot use bogomips to meaningfully compare processors.

The reason being?
The kernel uses it just fine for the clock calibration.

Reco

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

#201689

On Fri, Oct 26, 2018 at 05:34:26PM +0300, Reco wrote:
>On Fri, Oct 26, 2018 at 09:59:16AM -0400, Michael Stone wrote:
>> On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
>> > Why would you need a *program* to do that then you have Linux kernel
>> > already?
>> >
>> > grep bogomips /proc/cpuinfo
>>
>> Anyone reading that advice: ignore it. You cannot use bogomips to meaningfully compare processors.
>
>The reason being?

As it says in the link you posted, "It is not usable for performance 
comparisons among different CPUs".

>The kernel uses it just fine for the clock calibration.

I suppose if you want to use the system exclusively for busy loops, you 
can use the bogomips number to see which cpu will wait the fastest and 
choose based on that.

FWIW, even the kernel doesn't use naive busy loops anymore on newer 
hardware. (TSC or MWAIT is used, depending on what the processor 
supports.)

Mike Stone

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

#201706

On Fri 26 Oct 2018 at 11:04:48 (-0400), Michael Stone wrote:
> On Fri, Oct 26, 2018 at 05:34:26PM +0300, Reco wrote:
> > On Fri, Oct 26, 2018 at 09:59:16AM -0400, Michael Stone wrote:
> > > On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
> > > > Why would you need a *program* to do that then you have Linux kernel
> > > > already?
> > > >
> > > > grep bogomips /proc/cpuinfo
> > > 
> > > Anyone reading that advice: ignore it. You cannot use bogomips to meaningfully compare processors.
> > 
> > The reason being?
> 
> As it says in the link you posted, "It is not usable for performance
> comparisons among different CPUs".
> 
> > The kernel uses it just fine for the clock calibration.
> 
> I suppose if you want to use the system exclusively for busy loops,
> you can use the bogomips number to see which cpu will wait the fastest
> and choose based on that.
> 
> FWIW, even the kernel doesn't use naive busy loops anymore on newer
> hardware. (TSC or MWAIT is used, depending on what the processor
> supports.)

I've programmed a "busy loop" in the past and found that linux
bogomips tracked the loop speed quite closely on a variety of machines
from 486DX to 650MHz Pentium III (Coppermine). Nothing multiprocessor.

When I say busy loop, I mean a loop like
   FOR J=1 TO T
     X=X+1
   NEXT J
where X is floating point and the language is an HP Basic clone on MSDOS.

Cheers,
David.

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

#201707

On Fri, Oct 26, 2018 at 01:47:19PM -0500, David Wright wrote:
>On Fri 26 Oct 2018 at 11:04:48 (-0400), Michael Stone wrote:
>> FWIW, even the kernel doesn't use naive busy loops anymore on newer
>> hardware. (TSC or MWAIT is used, depending on what the processor
>> supports.)
>
>I've programmed a "busy loop" in the past and found that linux
>bogomips tracked the loop speed quite closely on a variety of machines
>from 486DX to 650MHz Pentium III (Coppermine). Nothing multiprocessor.
>
>When I say busy loop, I mean a loop like
>   FOR J=1 TO T
>     X=X+1
>   NEXT J
>where X is floating point and the language is an HP Basic clone on MSDOS.

That's basically all bogomips is:
		"	test %0,%0	\n"
		"	jz 3f		\n"
		"	jmp 1f		\n"

		".align 16		\n"
		"1:	jmp 2f		\n"

		".align 16		\n"
		"2:	dec %0		\n"
		"	jnz 2b		\n"
		"3:	dec %0		\n"
in a loop. (From https://github.com/torvalds/linux/blob/master/arch/x86/lib/delay.c)
(Note that other architectures are completely different and don't use 
the x86 assembly--one more way the bogomips numbers are meaningless. :) )

For a given CPU family there's a de-facto multiplier (essentially, how 
many instructions can be issued per cycle) and then within that family 
bogomips is directly proportional to clock speed. None of that works 
particularly well in the face of CPUs that change speed, and it's not 
particularly efficient given current desires to minimizing power 
consumption. So, current CPUs use the TSC (which, again for current 
CPUs, increments at a constant rate regardless of reduced clock speeds 
in power saving modes) possibly in concert with MWAIT (which lets the 
CPU idle for a bit to save power). In those cases the loop frequency 
calibration is just determining how the TSC counter relates to wall 
clock time, and has nothing at all to do with CPU performance--even the 
minimal "how fast can the CPU run these 5 instructions" 'benchmark' of 
classic bogomips.

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

#201698

Le 26/10/2018 à 16:34, Reco a écrit :
> 
> On Fri, Oct 26, 2018 at 09:59:16AM -0400, Michael Stone wrote:
>> On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
>>>
>>> grep bogomips /proc/cpuinfo
>>
>> Anyone reading that advice: ignore it. You cannot use bogomips to meaningfully compare processors.
> 
> The reason being?
> The kernel uses it just fine for the clock calibration.

As far as I remember, the bogomips number has consistently been twice 
the current clock frequency on any x86 PCU I have ever run Linux on.
How can you measure and compare processor performance from the mere 
clock frequency ?

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

#201702

On Fri, Oct 26, 2018 at 07:51:16PM +0200, Pascal Hambourg wrote:
> Le 26/10/2018 à 16:34, Reco a écrit :
> > 
> > On Fri, Oct 26, 2018 at 09:59:16AM -0400, Michael Stone wrote:
> > > On Fri, Oct 26, 2018 at 08:57:29AM +0300, Reco wrote:
> > > > 
> > > > grep bogomips /proc/cpuinfo
> > > 
> > > Anyone reading that advice: ignore it. You cannot use bogomips to meaningfully compare processors.
> > 
> > The reason being?
> > The kernel uses it just fine for the clock calibration.
> 
> As far as I remember, the bogomips number has consistently been twice the current clock frequency on any x86 PCU I have ever run Linux on.

Either your math is off, or they've changed it.

$ lscpu | egrep '(Vendor|MHz|MIPS)' # This PC
Vendor ID:             GenuineIntel
CPU MHz:               1599.975
CPU max MHz:           3800.0000
CPU min MHz:           1600.0000
BogoMIPS:              6800.59

$ lscpu | egrep '(Vendor|MHz|MIPS)' # Certain VPS
Vendor ID:             GenuineIntel
CPU MHz:               2099.996
BogoMIPS:              4199.99

And,

$ lscpu | egrep '(Vendor|MHz|MIPS)' # Xeon X5675
Vendor ID:             GenuineIntel
CPU MHz:               1600.000
BogoMIPS:              6117.70

> How can you measure and compare processor performance from the mere clock frequency ?

That's I agree with.

REco

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

#201713

On Fri, Oct 26, 2018 at 09:16:47PM +0300, Reco wrote:
>> As far as I remember, the bogomips number has consistently been twice the current clock frequency on any x86 PCU I have ever run Linux on.

>Either your math is off, or they've changed it.
>
>$ lscpu | egrep '(Vendor|MHz|MIPS)' # This PC
>Vendor ID:             GenuineIntel
>CPU MHz:               1599.975
>CPU max MHz:           3800.0000
>CPU min MHz:           1600.0000
>BogoMIPS:              6800.59

Who knows what "this pc" is. In this case bogomips is a little less than 
double, may be the system is configured to never exceed 3.4GHz (derated) 
or may be the difference between core and turbo or who knows what else. 
Would help to see CPU model. (In future, "Model name" is much more 
usefule than "Vendor".)

>$ lscpu | egrep '(Vendor|MHz|MIPS)' # Certain VPS
>Vendor ID:             GenuineIntel
>CPU MHz:               2099.996
>BogoMIPS:              4199.99

About double.

>And,
>
>$ lscpu | egrep '(Vendor|MHz|MIPS)' # Xeon X5675
>Vendor ID:             GenuineIntel
>CPU MHz:               1600.000
>BogoMIPS:              6117.70

x5675 is a 3.06GHz CPU that turbos to 3.46GHz, so bogomips is indeed about 
double the core frequency here. Older CPUs don't show min/max in lscpu 
output, only current frequency.

I spot checked a few systems here, found bogomips consistently about 2x 
max clock on skylake, haswell, xen+, silvermont, braswell and a couple 
of others. Heck, even the oldest thing I have that boots (a 200MHz 
pentium MMX) has a bogomips of 399.77 -- about double the MHz. The 
pentium pro family (+ ii & iii) got roughly the same bogomips as MHz. 
You have to go all the way back to the original pentiums, 486s, and 386s 
before you see major differences in the multipliers between CPUs. 
Anyway, the point remains--this is not useful as a benchmark.

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

#201680

On 2018-10-26 06:57, Reco wrote:
> Hi.
> 
> On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
>> any package that test cpu/system speed and report benchmark?
>> i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought 
>> them from 2nd hand dealers for about same priceso i think they're 
>> about same speed
> 
> Why would you need a *program* to do that then you have Linux kernel
> already?
> 
> grep bogomips /proc/cpuinfo
> 
> Reco

Just saying I really appreciate the responses you are giving.
Not things that particularly trouble me at present but learning stuff 
with each one.

thanks

mick



-- 
Key ID    4BFEBB31

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

#201682

	Hi.

On Fri, Oct 26, 2018 at 03:21:41PM +0100, mick crane wrote:
> On 2018-10-26 06:57, Reco wrote:
> > Hi.
> > 
> > On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
> > > any package that test cpu/system speed and report benchmark?
> > > i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think
> > > they're about same speed
> > 
> > Why would you need a *program* to do that then you have Linux kernel
> > already?
> > 
> > grep bogomips /proc/cpuinfo
> > 
> > Reco
> 
> Just saying I really appreciate the responses you are giving.
> Not things that particularly trouble me at present but learning stuff with each one.

I always appreciate kind words, good sir. Thank you.

Reco

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

#201664

There is a "perf" package complementing the linux kernel package, for example if
the kernel package is linux-image-4.17.0-3-amd64 the perf package is
linux-perf-4.17. Also, take a look at this web page
http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html about profiling by
Brendan Gregg.

Regards,
Jörg.

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

#201672

On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
> any package that test cpu/system speed and report benchmark?
> i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think they're about same speed

The performance of a given system depends on the task.  Some systems
are better at single-threaded integer calculations, some have more
cores so they're better in a multitasking environment, some have better
floating point optimizations, some have more cache and therefore perform
better when code jumps all over the place, etc.

You need to benchmark the systems for whatever task YOU actually care
about.  Whatever program you're using that makes you think "gosh, I
really wish this system could be faster" -- that's the one you use to
benchmark.  It could be compiling the Linux kernel, or transcoding
video and audio, or calculating prime factors of large numbers, or
first-person shooter video games, or whatever it is that you do.

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

#201696

[Multipart message — attachments visible in raw view] — view raw

Thank Greg!
is there any general-purpose testing utility? i remember in  early days some program for DOS can report benchmark, (maybe made by nordon?) .  and intel 486 always seems faster than 386. 

    On Friday, October 26, 2018 8:40 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
 

 On Fri, Oct 26, 2018 at 03:05:36AM +0000, Long Wind wrote:
> any package that test cpu/system speed and report benchmark?
> i have 2 old pc: intel pentium D 2.8 G and amd athlon 64 3800i bought them from 2nd hand dealers for about same priceso i think they're about same speed

The performance of a given system depends on the task.  Some systems
are better at single-threaded integer calculations, some have more
cores so they're better in a multitasking environment, some have better
floating point optimizations, some have more cache and therefore perform
better when code jumps all over the place, etc.

You need to benchmark the systems for whatever task YOU actually care
about.  Whatever program you're using that makes you think "gosh, I
really wish this system could be faster" -- that's the one you use to
benchmark.  It could be compiling the Linux kernel, or transcoding
video and audio, or calculating prime factors of large numbers, or
first-person shooter video games, or whatever it is that you do.



   

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web