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


Groups > comp.os.linux.advocacy > #448017 > unrolled thread

Gentoo is *BEST* GNU/Linux

Started by"F. Russell" <fr@random.info>
First post2018-04-08 15:29 +0000
Last post2018-04-11 13:14 +0000
Articles 10 on this page of 30 — 5 participants

Back to article view | Back to comp.os.linux.advocacy


Contents

  Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-08 15:29 +0000
    Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 10:51 -0700
    Re: Gentoo is *BEST* GNU/Linux Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-08 19:36 +0000
      Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 12:41 -0700
      Re: Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-08 20:03 +0000
        Re: Gentoo is *BEST* GNU/Linux Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-08 20:22 +0000
          Re: Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-08 21:06 +0000
        Re: Gentoo is *BEST* GNU/Linux owl <owl@rooftop.invalid> - 2018-04-08 21:02 +0000
          Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 14:31 -0700
          Re: Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-08 22:03 +0000
            Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 15:18 -0700
              Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 20:00 -0700
            Re: Gentoo is *BEST* GNU/Linux owl <owl@rooftop.invalid> - 2018-04-08 23:47 +0000
              Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 17:09 -0700
    Re: Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-10 15:23 +0000
      Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-10 11:35 -0700
      Re: Gentoo is *BEST* GNU/Linux owl <owl@rooftop.invalid> - 2018-04-10 20:31 +0000
        Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-10 21:53 -0700
        Re: Gentoo is *BEST* GNU/Linux "F. Russell" <fr@random.info> - 2018-04-11 09:29 +0000
          Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-11 03:35 -0700
          Re: Gentoo is *BEST* GNU/Linux owl <owl@rooftop.invalid> - 2018-04-11 12:21 +0000
            Re: Gentoo is *BEST* GNU/Linux Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-11 06:43 -0700
            A page fault can cost ONE MILLION CLOCK CYCLES. Jeff-Relf.Me  @. - 2018-04-11 12:09 -0700
              Re: A page fault can cost ONE MILLION CLOCK CYCLES. Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-11 19:25 +0000
                Re: A page fault can cost ONE MILLION CLOCK CYCLES. Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-12 02:24 -0700
                Re: A page fault can cost ONE MILLION CLOCK CYCLES. Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-12 06:51 -0700
                365 Million L3 Misses. Jeff-Relf.Me  @. - 2018-04-14 07:58 -0700
                  Re: 365 Million L3 Misses. Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-14 08:48 -0700
              Re: A page fault can cost ONE MILLION CLOCK CYCLES. Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-11 21:59 -0700
          Re: Gentoo is *BEST* GNU/Linux owl <owl@rooftop.invalid> - 2018-04-11 13:14 +0000

Page 2 of 2 — ← Prev page 1 [2]


#448127

Fromowl <owl@rooftop.invalid>
Date2018-04-11 12:21 +0000
Message-ID<9a0b80tr.ahu34@rooftop.invalid>
In reply to#448122
F. Russell <fr@random.info> wrote:
> On Tue, 10 Apr 2018 20:31:10 +0000, owl wrote:
> 
>> 
>> 6144.  Matches L3.
>>
> 
> There is virtually NO documentation on this.
> 
> I'll have to go to the gcc mailing lists for some
> answers.
> 

My guess is that the option predates L3 cache and refers
to highest level cache, whatever it might be called.  Some
CPUs have l4 cache now, and in that case the l2 param might
refer to l4.

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


#448133

FromSteven Petruzzellis <frelwizzen@gmail.com>
Date2018-04-11 06:43 -0700
Message-ID<5a4e2124-e4b9-4794-9139-48da59d31016@googlegroups.com>
In reply to#448127
On Wednesday, April 11, 2018 at 5:21:59 AM UTC-7, owl wrote:
> F. Russell <fr@random.info> wrote:
> > On Tue, 10 Apr 2018 20:31:10 +0000, owl wrote:
> > 
> >> 
> >> 6144.  Matches L3.
> >>
> > 
> > There is virtually NO documentation on this.
> > 
> > I'll have to go to the gcc mailing lists for some
> > answers.
> > 
> 
> My guess is that the option predates L3 cache and refers
> to highest level cache, whatever it might be called.  Some
> CPUs have l4 cache now, and in that case the l2 param might
> refer to l4.

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


#448151 — A page fault can cost ONE MILLION CLOCK CYCLES.

FromJeff-Relf.Me @.
Date2018-04-11 12:09 -0700
SubjectA page fault can cost ONE MILLION CLOCK CYCLES.
Message-ID<Jeff-Relf.Me@Apr.11--0.09pm.Seattle.2018>
In reply to#448127
> My guess is that the option predates L3 cache and refers
> to highest level cache, whatever it might be called.  
> 
> Some CPUs have l4 cache now, and in that case the l2 param
> might refer to l4.

My CPU, the i7-5775c, has a 128 MegaByte L-4 cache, 
a.k.a. "Crystal Well" ( 1.8 GigaHz eDRAM ).

Fabian got ( pa92ch01sun@news1.newsguy.com ):

  Loop 1: 3.01377 seconds
  Loop 2:  .11461 seconds

I get:

  Loop 1: 2.434 seconds      
  Loop 2:  .089 seconds   ( 2.434 / .089 =  27 )

Owl got ( 9a0b773q.u9b@rooftop.invalid ):

  Loop 1: 4.64766 seconds  Minor page faults: 262,211
  Loop 2:  .32333 seconds  Minor page faults: 262,215  [ Why more ? ]

Quoting "Docs.MicroSoft.COM/en-us/cpp/build/reference/Tips-for-Improving-Time-Critical-Code"

  A CPU cache hit can cost your program 10 to 20 clock cycles. 
  An external cache hit can cost 20 to 40 clock cycles.
  A page fault can cost ONE MILLION CLOCK CYCLES. 

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


#448152 — Re: A page fault can cost ONE MILLION CLOCK CYCLES.

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2018-04-11 19:25 +0000
SubjectRe: A page fault can cost ONE MILLION CLOCK CYCLES.
Message-ID<SitzC.428549$qo7.321660@fx04.am4>
In reply to#448151
On 2018-04-11, Jeff-Relf.Me  @. <Jeff-Relf.Me@> wrote:
>> My guess is that the option predates L3 cache and refers
>> to highest level cache, whatever it might be called.  
>> 
>> Some CPUs have l4 cache now, and in that case the l2 param
>> might refer to l4.
>
> My CPU, the i7-5775c, has a 128 MegaByte L-4 cache, 
> a.k.a. "Crystal Well" ( 1.8 GigaHz eDRAM ).
>
> Fabian got ( pa92ch01sun@news1.newsguy.com ):
>
>   Loop 1: 3.01377 seconds
>   Loop 2:  .11461 seconds
>
> I get:
>
>   Loop 1: 2.434 seconds      
>   Loop 2:  .089 seconds   ( 2.434 / .089 =  27 )
>
> Owl got ( 9a0b773q.u9b@rooftop.invalid ):
>
>   Loop 1: 4.64766 seconds  Minor page faults: 262,211
>   Loop 2:  .32333 seconds  Minor page faults: 262,215  [ Why more ? ]
>
> Quoting "Docs.MicroSoft.COM/en-us/cpp/build/reference/Tips-for-Improving-Time-Critical-Code"
>
>   A CPU cache hit can cost your program 10 to 20 clock cycles. 
>   An external cache hit can cost 20 to 40 clock cycles.
>   A page fault can cost ONE MILLION CLOCK CYCLES. 

Here's mine:  

~/News >>> perf stat -d ./fabtard1                                                                                                                                                                   
Run Time Loop 2: 0.32717 seconds                                                                                                                                                                     
                                                                                                                                                                                                     
                                                                                                                                                                                                     
 Performance counter stats for './fabtard1':                                                                                                                                                         
                                                                                                                                                                                                     
        359.808366      task-clock:u (msec)       #    0.999 CPUs utilized                                                                                                                           
                 0      context-switches:u        #    0.000 K/sec                                                                                                                                   
                 0      cpu-migrations:u          #    0.000 K/sec                                                                                                                                   
           262,193      page-faults:u             #    0.729 M/sec                                                                                                                                   
       465,102,033      cycles:u                  #    1.293 GHz                      (49.98%)                                                                                                       
     1,073,726,594      instructions:u            #    2.31  insn per cycle           (62.48%)                                                                                                       
       269,666,155      branches:u                #  749.472 M/sec                    (62.48%)                                                                                                       
            23,418      branch-misses:u           #    0.01% of all branches          (62.49%)                                                                                                       
           532,483      L1-dcache-loads:u         #    1.480 M/sec                    (61.79%)
            75,502      L1-dcache-load-misses:u   #   14.18% of all L1-dcache hits    (25.02%)
            27,150      LLC-loads:u               #    0.075 M/sec                    (25.01%)
            20,763      LLC-load-misses:u         #   76.48% of all LL-cache hits     (37.51%)

       0.360062742 seconds time elapsed

~/News >>> perf stat -d ./fabtard2                                                                                                                                                                  


Run Time Loop 1: 3.65935 seconds


 Performance counter stats for './fabtard2':

       3727.861715      task-clock:u (msec)       #    1.000 CPUs utilized
                 0      context-switches:u        #    0.000 K/sec
                 0      cpu-migrations:u          #    0.000 K/sec
           262,193      page-faults:u             #    0.070 M/sec
    13,282,524,905      cycles:u                  #    3.563 GHz                      (50.00%)
     1,073,185,437      instructions:u            #    0.08  insn per cycle           (62.50%)
       268,571,803      branches:u                #   72.044 M/sec                    (62.50%)
            24,326      branch-misses:u           #    0.01% of all branches          (62.50%)
           548,175      L1-dcache-loads:u         #    0.147 M/sec                    (62.43%)
       538,498,716      L1-dcache-load-misses:u   # 98234.82% of all L1-dcache hits   (25.00%)
       152,304,851      LLC-loads:u               #   40.856 M/sec                    (25.00%)
         4,648,176      LLC-load-misses:u         #    3.05% of all LL-cache hits     (37.50%)

       3.728265590 seconds time elapsed

-- 
press any key to continue or any other to quit...

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


#448161 — Re: A page fault can cost ONE MILLION CLOCK CYCLES.

FromSteven Petruzzellis <frelwizzen@gmail.com>
Date2018-04-12 02:24 -0700
SubjectRe: A page fault can cost ONE MILLION CLOCK CYCLES.
Message-ID<1008913c-8dcc-405a-8186-77e24610b183@googlegroups.com>
In reply to#448152
On Wednesday, April 11, 2018 at 12:25:41 PM UTC-7, Melzzzzz wrote:
> On 2018-04-11, Jeff-Relf.Me  @. <Jeff-Relf.Me@> wrote:
> >> My guess is that the option predates L3 cache and refers
> >> to highest level cache, whatever it might be called.  
> >> 
> >> Some CPUs have l4 cache now, and in that case the l2 param
> >> might refer to l4.
> >
> > My CPU, the i7-5775c, has a 128 MegaByte L-4 cache, 
> > a.k.a. "Crystal Well" ( 1.8 GigaHz eDRAM ).
> >
> > Fabian got ( pa92ch01sun@news1.newsguy.com ):
> >
> >   Loop 1: 3.01377 seconds
> >   Loop 2:  .11461 seconds
> >
> > I get:
> >
> >   Loop 1: 2.434 seconds      
> >   Loop 2:  .089 seconds   ( 2.434 / .089 =  27 )
> >
> > Owl got ( 9a0b773q.u9b@rooftop.invalid ):
> >
> >   Loop 1: 4.64766 seconds  Minor page faults: 262,211
> >   Loop 2:  .32333 seconds  Minor page faults: 262,215  [ Why more ? ]
> >
> > Quoting "Docs.MicroSoft.COM/en-us/cpp/build/reference/Tips-for-Improving-Time-Critical-Code"
> >
> >   A CPU cache hit can cost your program 10 to 20 clock cycles. 
> >   An external cache hit can cost 20 to 40 clock cycles.
> >   A page fault can cost ONE MILLION CLOCK CYCLES. 
> 
> Here's mine:  
> 
> ~/News >>> perf stat -d ./fabtard1                                                                                                                                                                   
> Run Time Loop 2: 0.32717 seconds                                                                                                                                                                     
>                                                                                                                                                                                                      
>                                                                                                                                                                                                      
>  Performance counter stats for './fabtard1':                                                                                                                                                         
>                                                                                                                                                                                                      
>         359.808366      task-clock:u (msec)       #    0.999 CPUs utilized                                                                                                                           
>                  0      context-switches:u        #    0.000 K/sec                                                                                                                                   
>                  0      cpu-migrations:u          #    0.000 K/sec                                                                                                                                   
>            262,193      page-faults:u             #    0.729 M/sec                                                                                                                                   
>        465,102,033      cycles:u                  #    1.293 GHz                      (49.98%)                                                                                                       
>      1,073,726,594      instructions:u            #    2.31  insn per cycle           (62.48%)                                                                                                       
>        269,666,155      branches:u                #  749.472 M/sec                    (62.48%)                                                                                                       
>             23,418      branch-misses:u           #    0.01% of all branches          (62.49%)                                                                                                       
>            532,483      L1-dcache-loads:u         #    1.480 M/sec                    (61.79%)
>             75,502      L1-dcache-load-misses:u   #   14.18% of all L1-dcache hits    (25.02%)
>             27,150      LLC-loads:u               #    0.075 M/sec                    (25.01%)
>             20,763      LLC-load-misses:u         #   76.48% of all LL-cache hits     (37.51%)
> 
>        0.360062742 seconds time elapsed
> 
> ~/News >>> perf stat -d ./fabtard2                                                                                                                                                                  
> 
> 
> Run Time Loop 1: 3.65935 seconds
> 
> 
>  Performance counter stats for './fabtard2':
> 
>        3727.861715      task-clock:u (msec)       #    1.000 CPUs utilized
>                  0      context-switches:u        #    0.000 K/sec
>                  0      cpu-migrations:u          #    0.000 K/sec
>            262,193      page-faults:u             #    0.070 M/sec
>     13,282,524,905      cycles:u                  #    3.563 GHz                      (50.00%)
>      1,073,185,437      instructions:u            #    0.08  insn per cycle           (62.50%)
>        268,571,803      branches:u                #   72.044 M/sec                    (62.50%)
>             24,326      branch-misses:u           #    0.01% of all branches          (62.50%)
>            548,175      L1-dcache-loads:u         #    0.147 M/sec                    (62.43%)
>        538,498,716      L1-dcache-load-misses:u   # 98234.82% of all L1-dcache hits   (25.00%)
>        152,304,851      LLC-loads:u               #   40.856 M/sec                    (25.00%)
>          4,648,176      LLC-load-misses:u         #    3.05% of all LL-cache hits     (37.50%)
> 
>        3.728265590 seconds time elapsed
> 
> -- 
> press any key to continue or any other to quit...



After yesterday's update I no longer want to gouge out my eyeballs from the flicker of the screen. 

Translation of benj speak: benj's "diagnostic expertise" distracted him from a component he wants that is already built into this software. 

It was benj who stated that he and his hired winos used to troll grade school kids all the time and it was just fun, not even worth worrying about. Too much glue for you, Gluehead. 

At times, fantasy is more valuable than reality. 



--
Eight things to never feed your cat
https://prescottareapsychopaths.wordpress.com/mark-bilk-psychopath/
Jonas Eklundh Communication

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


#448169 — Re: A page fault can cost ONE MILLION CLOCK CYCLES.

FromSteven Petruzzellis <frelwizzen@gmail.com>
Date2018-04-12 06:51 -0700
SubjectRe: A page fault can cost ONE MILLION CLOCK CYCLES.
Message-ID<f6de4eca-2107-4672-a1ad-70b146fa0f6e@googlegroups.com>
In reply to#448152
On Wednesday, April 11, 2018 at 12:25:41 PM UTC-7, Melzzzzz wrote:
> On 2018-04-11, Jeff-Relf.Me  @. <Jeff-Relf.Me@> wrote:
> >> My guess is that the option predates L3 cache and refers
> >> to highest level cache, whatever it might be called.  
> >> 
> >> Some CPUs have l4 cache now, and in that case the l2 param
> >> might refer to l4.
> >
> > My CPU, the i7-5775c, has a 128 MegaByte L-4 cache, 
> > a.k.a. "Crystal Well" ( 1.8 GigaHz eDRAM ).
> >
> > Fabian got ( pa92ch01sun@news1.newsguy.com ):
> >
> >   Loop 1: 3.01377 seconds
> >   Loop 2:  .11461 seconds
> >
> > I get:
> >
> >   Loop 1: 2.434 seconds      
> >   Loop 2:  .089 seconds   ( 2.434 / .089 =  27 )
> >
> > Owl got ( 9a0b773q.u9b@rooftop.invalid ):
> >
> >   Loop 1: 4.64766 seconds  Minor page faults: 262,211
> >   Loop 2:  .32333 seconds  Minor page faults: 262,215  [ Why more ? ]
> >
> > Quoting "Docs.MicroSoft.COM/en-us/cpp/build/reference/Tips-for-Improving-Time-Critical-Code"
> >
> >   A CPU cache hit can cost your program 10 to 20 clock cycles. 
> >   An external cache hit can cost 20 to 40 clock cycles.
> >   A page fault can cost ONE MILLION CLOCK CYCLES. 
> 
> Here's mine:  
> 
> ~/News >>> perf stat -d ./fabtard1                                                                                                                                                                   
> Run Time Loop 2: 0.32717 seconds                                                                                                                                                                     
>                                                                                                                                                                                                      
>                                                                                                                                                                                                      
>  Performance counter stats for './fabtard1':                                                                                                                                                         
>                                                                                                                                                                                                      
>         359.808366      task-clock:u (msec)       #    0.999 CPUs utilized                                                                                                                           
>                  0      context-switches:u        #    0.000 K/sec                                                                                                                                   
>                  0      cpu-migrations:u          #    0.000 K/sec                                                                                                                                   
>            262,193      page-faults:u             #    0.729 M/sec                                                                                                                                   
>        465,102,033      cycles:u                  #    1.293 GHz                      (49.98%)                                                                                                       
>      1,073,726,594      instructions:u            #    2.31  insn per cycle           (62.48%)                                                                                                       
>        269,666,155      branches:u                #  749.472 M/sec                    (62.48%)                                                                                                       
>             23,418      branch-misses:u           #    0.01% of all branches          (62.49%)                                                                                                       
>            532,483      L1-dcache-loads:u         #    1.480 M/sec                    (61.79%)
>             75,502      L1-dcache-load-misses:u   #   14.18% of all L1-dcache hits    (25.02%)
>             27,150      LLC-loads:u               #    0.075 M/sec                    (25.01%)
>             20,763      LLC-load-misses:u         #   76.48% of all LL-cache hits     (37.51%)
> 
>        0.360062742 seconds time elapsed
> 
> ~/News >>> perf stat -d ./fabtard2                                                                                                                                                                  
> 
> 
> Run Time Loop 1: 3.65935 seconds
> 
> 
>  Performance counter stats for './fabtard2':
> 
>        3727.861715      task-clock:u (msec)       #    1.000 CPUs utilized
>                  0      context-switches:u        #    0.000 K/sec
>                  0      cpu-migrations:u          #    0.000 K/sec
>            262,193      page-faults:u             #    0.070 M/sec
>     13,282,524,905      cycles:u                  #    3.563 GHz                      (50.00%)
>      1,073,185,437      instructions:u            #    0.08  insn per cycle           (62.50%)
>        268,571,803      branches:u                #   72.044 M/sec                    (62.50%)
>             24,326      branch-misses:u           #    0.01% of all branches          (62.50%)
>            548,175      L1-dcache-loads:u         #    0.147 M/sec                    (62.43%)
>        538,498,716      L1-dcache-load-misses:u   # 98234.82% of all L1-dcache hits   (25.00%)
>        152,304,851      LLC-loads:u               #   40.856 M/sec                    (25.00%)
>          4,648,176      LLC-load-misses:u         #    3.05% of all LL-cache hits     (37.50%)
> 
>        3.728265590 seconds time elapsed
> 
> -- 
> press any key to continue or any other to quit...



I've worked in the VAR industry for more than 45 years. I have worked for Fortune 500 corporations selling to government agencies and the health industry. Never, not one single time, was I at any point instructed to not load any version of Linux. We sold OS/2, DUnix, System V, and so forth as well as Microsoft OSs with no issues. 

At times, an inner world is more valuable than faithful descriptions of reality. 

What did Bit Twister assume from the lying imbecile? That Desk Rabbit mouth-breather has nothing to squander but time. He has nothing else. Especially not a caring family. It was Desk Rabbit who forged me (and Bit Twister) and admitted to having done so. 



-- 
Curious how these posts are made? Email: frelwizzen@gmail.com

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


#448261 — 365 Million L3 Misses.

FromJeff-Relf.Me @.
Date2018-04-14 07:58 -0700
Subject365 Million L3 Misses.
Message-ID<Jeff-Relf.Me@Apr.14--7.58am.Seattle.2018>
In reply to#448152
BranimirMaksimovic replied:
> for( i = 0; i < _16k; ++i ) for( j = 0; j < _16k; ++j ) mat[ j*_16k + i ] = 42 ;
> Loop1:  3.659 Seconds     5  Million L3 Misses
> Loop2:   .327 Seconds

  Loop1:  2.485 Seconds   365  Million L3 Misses  ( 430 - 65 )
  Loop2:   .080 Seconds

I've no way of knowing L4 misses; my L4 is 128 MegaBytes.

I had to compile GitHub's "Performance Counter Monitor"
as I couldn't find "PCM.EXE", Googling.
WinRing0x64.DLL/.SYS had to be downloaded, as they must be signed.

I sample for 11 seconds because it takes me at least 5 seconds
to (manually) start the Loop1 test;  65 Million Misses is normal
for this amount of time ( 11 seconds, 430 - 65  = 365 ).

    PCM  11 -i=1 -ns -nsys -nc

A ReSet ( -r ) might be required, if there's a conflict.
I ran it -many- times, to be sure that I got the right averages.

To compile it, I had to add a "#include" and
change some compiler/linker switches.  Also:

    Visual Studio -> Solution Explorer -> RightClick Solution
    -> ReTarget Solution -> to pick a "Windows SDK".

    Put my "Include", "Lib" paths in my "Microsoft.Cpp.Win32.user.props.TXT";
    Copied it too "%LocalAppData%\Microsoft\MSBuild\v4.0\";
    Removed the ".TXT" extension and ReSarted Visual Studio;
    so the CodeEditor knows where my Includes are.

    Also, I put them in:  Solution Explorer -> Select all projects
      -> Settings -> Configuration Properties -> VC++ Directories.

Jeff-Relf.Me/Microsoft.Cpp.Win32.user.props.TXT

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


#448262 — Re: 365 Million L3 Misses.

FromSteven Petruzzellis <frelwizzen@gmail.com>
Date2018-04-14 08:48 -0700
SubjectRe: 365 Million L3 Misses.
Message-ID<a83265b2-327b-43c7-9d43-e0e5864fbaeb@googlegroups.com>
In reply to#448261
On Saturday, April 14, 2018 at 7:58:59 AM UTC-7, Jeff-Relf.Me wrote:
> BranimirMaksimovic replied:
> > for( i = 0; i < _16k; ++i ) for( j = 0; j < _16k; ++j ) mat[ j*_16k + i ] = 42 ;
> > Loop1:  3.659 Seconds     5  Million L3 Misses
> > Loop2:   .327 Seconds
> 
>   Loop1:  2.485 Seconds   365  Million L3 Misses  ( 430 - 65 )
>   Loop2:   .080 Seconds
> 
> I've no way of knowing L4 misses; my L4 is 128 MegaBytes.
> 
> I had to compile GitHub's "Performance Counter Monitor"
> as I couldn't find "PCM.EXE", Googling.
> WinRing0x64.DLL/.SYS had to be downloaded, as they must be signed.
> 
> I sample for 11 seconds because it takes me at least 5 seconds
> to (manually) start the Loop1 test;  65 Million Misses is normal
> for this amount of time ( 11 seconds, 430 - 65  = 365 ).
> 
>     PCM  11 -i=1 -ns -nsys -nc
> 
> A ReSet ( -r ) might be required, if there's a conflict.
> I ran it -many- times, to be sure that I got the right averages.
> 
> To compile it, I had to add a "#include" and
> change some compiler/linker switches.  Also:
> 
>     Visual Studio -> Solution Explorer -> RightClick Solution
>     -> ReTarget Solution -> to pick a "Windows SDK".
> 
>     Put my "Include", "Lib" paths in my "Microsoft.Cpp.Win32.user.props.TXT";
>     Copied it too "%LocalAppData%\Microsoft\MSBuild\v4.0\";
>     Removed the ".TXT" extension and ReSarted Visual Studio;
>     so the CodeEditor knows where my Includes are.
> 
>     Also, I put them in:  Solution Explorer -> Select all projects
>       -> Settings -> Configuration Properties -> VC++ Directories.
> 
> Jeff-Relf.Me/Microsoft.Cpp.Win32.user.props.TXT



And in retaliation you have nothing but an attempt to start something. Do you have a high school diploma? 

Just some names Steve Carroll has used
    "Evil" John *
    "Evil" Snit *
    Big Crotch on a Small Fish
    Cornelius Munshower
    CSMA Moderator
    Edward Stanfield
    Fretwiz *
    Hitman Hero
    Measles
    Petruzzellis Kids
    Sigmond
    Slaveen
    Smit
    Steve C *
    Steve Camoll *
    Steve Carroll <noone@xxxxxxxxxxx> *
    Steve Carroll <stevecarroll@xxxxxxxxxxx> *
    Steve Carroll <trollkiller@xxxxxx> *
    Steve Carroll's Dog *
    Steve Carrolll *
    Steve Carrroll *
    Yevette Owens
    Yobo_Obyo


Takuya 'The Flooder' Saitoh and Alex Ding both lie constantly and flagrantly and continue to do so. So no sense in showing any further kindness or restraint. But when the stats were run, it turns out beyond any doubt, Takuya 'The Flooder' Saitoh was far more "obsessive" than anybody else. I am an obsessed groupie of LibreOffice, because that's where all the exciting programming is happening. You are quick as a tuna on ice. His desire is to see me frustrated by nonstop flooding. And hey, that could kill this group. 

-- 
I Left My Husband & Daughter At Home And THIS happened!!
http://www.5z8.info/dont-just-drizzle_y8q4ut_5waystokillwithamelon
Jonas Eklundh Communication

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


#448158 — Re: A page fault can cost ONE MILLION CLOCK CYCLES.

FromSteven Petruzzellis <frelwizzen@gmail.com>
Date2018-04-11 21:59 -0700
SubjectRe: A page fault can cost ONE MILLION CLOCK CYCLES.
Message-ID<a7a78a1b-ab9d-448a-ae5a-a56dcfca808c@googlegroups.com>
In reply to#448151
On Wednesday, April 11, 2018 at 12:09:19 PM UTC-7, Jeff-Relf.Me wrote:
> > My guess is that the option predates L3 cache and refers
> > to highest level cache, whatever it might be called.  
> > 
> > Some CPUs have l4 cache now, and in that case the l2 param
> > might refer to l4.
> 
> My CPU, the i7-5775c, has a 128 MegaByte L-4 cache, 
> a.k.a. "Crystal Well" ( 1.8 GigaHz eDRAM ).
> 
> Fabian got ( pa92ch01sun@news1.newsguy.com ):
> 
>   Loop 1: 3.01377 seconds
>   Loop 2:  .11461 seconds
> 
> I get:
> 
>   Loop 1: 2.434 seconds      
>   Loop 2:  .089 seconds   ( 2.434 / .089 =  27 )
> 
> Owl got ( 9a0b773q.u9b@rooftop.invalid ):
> 
>   Loop 1: 4.64766 seconds  Minor page faults: 262,211
>   Loop 2:  .32333 seconds  Minor page faults: 262,215  [ Why more ? ]
> 
> Quoting "Docs.MicroSoft.COM/en-us/cpp/build/reference/Tips-for-Improving-Time-Critical-Code"
> 
>   A CPU cache hit can cost your program 10 to 20 clock cycles. 
>   An external cache hit can cost 20 to 40 clock cycles.
>   A page fault can cost ONE MILLION CLOCK CYCLES.



Carroll, 4/10/2015 4:04 PM:
    -----
    Cute trick... To the guy who hacked my Google account.
    -----
No details. Seems to treat it as a joke.

Carroll, 4/10/2015 5:02 PM, <https://goo.gl/51rsmZ>:
    -----
    Email Hacking Is A Serious Crime
    -----    
No longer "cute"... now it is a serious crime. OK.

Carroll, 4/10/2015 5:07 PM:
By now he is posting more links to how serious this crime against him is.

Carroll, 4/10/2015 7:25 PM:
    -----
    I didn't write that.
    -----
Now he is denying the posts from his own account. OK, he was "hacked". Someone else posted this. Hard to hack a gmail account given how they use two-step authentication and someone would need access to his phone or the like... but at least POSSIBLE. 

Even then, though, if someone tries to guess your password Google alerts you and lets you know what IP address and other info. I know because someone in a Denver internet cafe has tried mine on several occasions.

Google even forces you to change your password when this happens. Very hard to hack these days. 

So already Carroll's story is unlikely. 

But let us accept it... someone somehow hacked his account bypassing the two step verification. This person did not, however, change his password and Carroll posted within an hour of the "hacker". Before that, unless he is an idiot, he changed his password and the "hacker" was locked out. The "hacker" got one post in. 

But Carroll could not leave his story there.

Carroll, 4/10/2015 8:36 PM, <https://goo.gl/NJ2bMH>:
    -----
    Someone hacked my fretwizzer gmail acct so, for the time being,
    don't trust anything from it.
    -----
Wait. What? Even after Carroll figured out this "hacker" who was too stupid to change his password had broken into his account and Carroll *surely* must have changed his own password, he is saying the "hacker" might still have access. Might be able to break Google's two-step verification process *again*. 

This is *very* unlikely... to the point of being unbelievable. 

Even worse for him: he notes which of his accounts he is claiming was hacked - but in the past he has denied even using the other accounts! LOL! He screwed up and made it very clear he has multiple accounts and felt the need to note which one. He made the same mistake in the next quote where he speaks of WHICH of his gmail accounts he is claiming was hacked. Oops! If he only posts with one there would be no need to specify which one!

He has completely screwed up in his game to pretend he posts with only one gmail account. Completely idiotic of him, too!

Carroll, 4/10/2015 8:38 PM, <https://goo.gl/YA7gMO>:
    -----
    Some mentally deficient child hacked my 'fretwizzer' gmail account
    so I may have to kill it. For the time being, don't assume
    anything that's coming from it was written by me.
    -----
He is still saying that he may have to kill the account instead of just changing the password which anyone with half a brain would have already done (and Google *forces* you to do when someone even tries to hack your account... I know because someone in the Denver area has tried to hack mine multiple times... likely Carroll but I have no proof of this). And he specifies WHICH of his accounts! He is directly admitting he uses more than one account! His claim of being "forged" with his second account is a lie. Proved.

Carroll, 4/10/2015 8:40 PM, <https://goo.gl/j6yCuV>:
    -----
    Looks like it's still being hacked despite me taking precautions,
    I may have to kill the account.
    -----
What makes it look like its still being hacked? And what precautions other than changing the two-step verification options does he need? And how would someone bypass this... is he really on the NSA watch list? Seems you would need someone at that level to be doing this. He watches too much TV where they computer hackers spend thirty seconds and bypass all security.

Just nonsense.

Carroll, 4/11/2015 12:05 PM:
    -----
    Apparently Google is having issues with their accounts to the
    point where they're ready to undertake some additional measures.
    -----
But, of course, no evidence of this... and what measures? They already alert users if someone else tries to guess your password and use two-step authentication and even force you to make a new password if it seems someone is trying to hack you.
    -----
    They're now involving several federal agencies in things they
    didn't bother with previously in an effort to deal with people who
    hack into accounts. They've asked me to leave the account open.
    -----
So now Google is letting Carroll know how they are handling these things - and asking him to leave a *hacked* account open... one someone can be using to steal his identity. No. This does not pass the sniff test in any way. Even if they were doing this for some bizarre sting operation, which is in itself far fetched, they would have told Carroll to not make it public information so the hacker would not know.

Just insanity. His own story is so idiotic and full of idiotic claims it simply cannot be true. Carroll uses his secondary Google account - the one he accesses via Tor and is referred to as his Tor account - to have plausible deniability for things he says there. Now he is working to do the same thing with his main account. Maybe Carroll read a report like this: <http://cnnmon.ie/111QeT8> [money.com]. If so he missed the part where they note if you are *really* hacked, which is rare, the hackers change your password and lock you out. Why would they not?
    -----
    There's some new legislation that will help them deal with this
    issue... which probably means more BS for us ;)
    -----
Yes, new legislation to make sure Carroll does not have to deal with "hackers" and "forgers" which do not even exist. 

The funny part is, this happened shortly after someone in the Denver area, likely Carroll, tried to guess *my* passwords and they did it from an Internet café (Google tells you the IP and that can be used to trace back). 

My guess: Carroll is the one who was working to guess my password and figured this new lie of his was a good way to deny his own words even more than he does with his Tor account *and* a way to make it so if I had talked about him trying to hack my account he could say I was just copying his comments. "Proving" I read his posts... which for now I am to see how absurd his lies are. :)

Carroll, 4/11/2015 12:25 PM:
    -----
    The person who hacked into my Gmail acct. changed the wording on
    this post. I've removed the others but Google asked me to leave
    one standing for some odd reason. 
    -----
Here Carroll claims the hacker changed the wording on a post of his from *before* he had even claimed he was hacked. So this hacker not only can *post* for him but edit his old Usenet posts.

I call utter bullshit on this. Out and out lie from Carroll. And then Carroll says Google asked him to not delete these "hacked" posts... this is nonsense. Why would Google want him to leave forged posts in the public and why would Google not just keep their own copy? Even Carroll notes it is for "some odd reason" - yeah, because Carroll is telling stories that make *no* sense at all.

Carroll is lying. Maybe there is some kernel of truth to his stories? Even if so - and frankly it is unlikely he will ever show any evidence to back his claims - the details he is posting are absurd.

Carroll, 4/11/2015 2:10 PM:
    -----
    And he's so high he thinks people still have to manually enter all
    their passwords in whenever they want to use anything that's been
    password protected ;)
    -----
Nobody had suggested, hinted, implied, or said anything like what Carroll says they did.

Maybe his story will be someone stole his laptop (or mobile device) and he had his passwords saved? If so why not have the device deactivated remotely? Why has he not said anything about this? 

My guess: he realizes he screwed up when trying to guess my passwords and is now building a story so he can say his computer was stolen and it was not him. Or, LOL, maybe someone broke into his house and did it. 

This unknown hacker knew he was obsessed with me and carried on acting like him. Makes complete sense, eh?

Carroll, 4/12/2015 8:45 AM, <https://goo.gl/KMf4pa>:
    -----
    The first one, that has since been deleted. My bad for having such
    a feeble password on this account.
    -----
Now he suggests it was merely from someone guessing his password - which contradicts his above insinuations that it could have been from a saved password on a device he had.

His story changes with the telling.

But as noted, when someone tries to guess your password Google has ways to deal with it. I know - Carroll or someone in his neck of the woods recently tried it with me.

Carroll, 4/12/2015 9:29 AM:
    -----
    The account in question here is a gmail account. Contrary to
    Snit's delusions, I have no idea what a TOR account looks like but
    it's a good bet it doesn't bear much of a resemblance to a gmail
    account. 
    -----
Here Carroll plays stupid and pretends that if when he or anyone uses the Tor browser *Carroll* pointed to this somehow changes the way the gmail interface looks. Um, no. Worse it might do is make Google think you are in another country and you would have to set it back to English. But the basic look stays the same.

He is playing stupid and pretending to not know how the Tor browser he pointed to works. Just idiotic of him.
    -----
    That idiocy aside, I love how Snit has repeatedly, for years, 
    feigned ignorance about gmail accounts, yet, he keeps disclosing
    info that proves he knows about them. Some fools do stuff like
    this when they believe people are as stupid as the fool needs them
    to be ;)
    -----
I do not think Google would allow you to edit your Usenet / groups posts but I do not use it much and do not know for sure. Seems absurd that they would... and others have now said they do not. But given how I do not use Google Groups for posting why would I know the details of their system for certain? 

Carroll, 6/16/2015 8:47 PM:
    -----
    Your obsession with me is insane. Working with Google I now have
    proof you and ebot worked together to hack me. Clever. If I press
    charges against you I have to also include her so you remain safe
    for now.

    Do not think this is over.
    -----
    
No evidence of working with Google on this (and all out and out lies). Carroll is making public threats based on lies. 

Carroll, 6/16/2015 8:50 PM:
    -----
    I promised COLA your trolling days were over so you contacted ebot
    and worked with her to hack my account. I might not be able to get
    your ass handed to you in court over this but wait until your boss
    at Yavapai College contacts you.

    Maybe you should make that call first. Ask about your comments on
    incest.

    See if those can not be quoted.
    -----
    
Direct lies and threats by Carroll.

Carroll, 6/16/2015 8:51 PM:
    -----
    You went too far this time Snit. We have trolled each other for
    years but to contact ebot and get her to help you hack my account
    was over a line.
    -----
    
A complete and utter lie from Carroll. 

Carroll, 6/16/2015 8:52 PM:
    -----
    The above post is Snit hacking my account.
    -----
A complete and utter lie... more false accusations from him.

Carroll, 6/16/2015 8:53 PM:
    -----
    You edited those posts when you hacked my account. Do not trust
    anything from my fretwizzer account now that Snit and ebot have
    access to it.
    -----
More unsupported claims and attacks by Carroll.

Carroll, 4/16/2015 8:56 PM:
    -----
    Working with Google I now have proof Snit and ebot hacked the
    account. Many of the older posts were edited. You can see evidence
    of this by Snit pointing to "old" posts which have been modified to
    say I claimed I was his "personal newsgroup rapist", a phrase I
    have never used.
    -----
    
No evidence of Carroll working with Google. No evidence of any older posts being edited.

- 
Curious how these posts are made? Email: mr@sandman.net

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


#448132

Fromowl <owl@rooftop.invalid>
Date2018-04-11 13:14 +0000
Message-ID<9a09b79a.bahoi3@rooftop.invalid>
In reply to#448122
F. Russell <fr@random.info> wrote:
> On Tue, 10 Apr 2018 20:31:10 +0000, owl wrote:
> 
>> 
>> 6144.  Matches L3.
>>
> 
> There is virtually NO documentation on this.
> 
> I'll have to go to the gcc mailing lists for some
> answers.
> 

from anon@lowtide:~/gcc-4.8-4.8.4/gcc-4.8.4/gcc/config/i386/driver-i386.c:

static const char *
detect_caches_intel (bool xeon_mp, unsigned max_level,
                     unsigned max_ext_level, unsigned *l2sizekb)
{

...

  /* Let the L3 replace the L2. This assumes inclusive caches
     and single threaded program for now. */
  if (level3.sizekb)
    level2 = level3;

...

  return describe_cache (level1, level2);
}


static char *
describe_cache (struct cache_desc level1, struct cache_desc level2)
{

...


  snprintf (size2, sizeof (size2),
            "--param l2-cache-size=%u ", level2.sizekb);
...

}


[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.advocacy


csiph-web