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

Groups > alt.os.linux > #51696 > unrolled thread

Linux 4.20 is Running Slower Than 4.19 On Intel CPUs

Back to article view | Back to alt.os.linux

Contents

  Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <noreply@mixnym.net> - 2018-11-16 20:21 -0600
    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-17 11:10 +0100
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Carlos E.R." <robin_listas@es.invalid> - 2018-11-17 11:26 +0100
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-17 11:53 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Carlos E.R." <robin_listas@es.invalid> - 2018-11-18 21:06 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Paul <nospam@needed.invalid> - 2018-11-18 15:46 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Bud Frede <frede@mouse-potato.com> - 2018-11-24 09:07 -0500
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-18 22:27 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-19 08:27 +0000
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-19 18:33 +0000
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-19 21:02 +0100
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-20 04:46 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-20 06:59 +0100
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs not@telling.you.invalid (Computer Nerd Kev) - 2018-11-19 21:58 +0000
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-11-19 17:27 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-11-19 17:37 -0500
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-20 10:10 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-20 15:51 -0500
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs not@telling.you.invalid (Computer Nerd Kev) - 2018-11-20 21:31 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-20 23:14 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-21 06:50 +0000
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Paul <nospam@needed.invalid> - 2018-11-21 04:24 -0500
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-21 10:56 +0000
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-21 12:22 +0000
                      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-21 13:24 +0000
                        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-21 22:08 +0000
                          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs William Unruh <unruh@invalid.ca> - 2018-11-21 23:53 +0000
                            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-24 11:46 +0000
                              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs William Unruh <unruh@invalid.ca> - 2018-11-24 13:53 +0000
                                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-24 18:39 +0000
                                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-24 15:47 -0500
                                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-25 07:51 +0000
                                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-25 16:08 -0500
                              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-24 15:24 +0000
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Soviet_Mario <SovietMario@CCCP.MIR> - 2018-11-30 11:32 +0100
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-12-01 05:13 +0000
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Anonymous Remailer (austria)" <mixmaster@remailer.privacy.at> - 2018-11-18 06:23 +0100
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-11-19 19:06 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Anonymous <anonymous@hoi-polloi.org> - 2018-11-19 21:44 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <nobody@dizum.com> - 2018-11-20 10:19 +0100
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Dave Froble <davef@tsoft-inc.com> - 2018-11-19 18:44 -0500
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs kludge@panix.com (Scott Dorsey) - 2018-11-19 19:00 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Bobbie Sellers <bliss@mouse-potato.com> - 2018-11-26 20:40 -0800
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <nobody@dizum.com> - 2018-11-20 10:09 +0100
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs fr314159@gmail.com - 2018-11-28 07:26 -0800
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Jasen Betts <jasen@xnet.co.nz> - 2018-11-29 19:45 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Melzzzzz <Melzzzzz@zzzzz.com> - 2018-11-29 20:21 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "F. Russell" <fr@random.info> - 2018-11-29 20:26 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#51754

On 20/11/2018 21:31, Computer Nerd Kev wrote:
> In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> Thse CPU bugs are all about caching.
>>
>> Not quite all. The meltdown class of bugs are about caching, but the
>> spectre class bugs are about speculative execution.
>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>>
>> For maximum safety, disable execution on all but one core/thread. :-(
> 
> I don't think that would do. The Pentium Pro was apparantly the first
> Intel x86 CPU to support speculative execution, and it was only
> available as a single-core CPU. The speculatively executed
> instructions can be done with a single core while it's waiting for
> a memory read or similar.
> 

Intersting that people differentiate between 'speculative execution' and 
'caching'.

Or is caching 'speculative memory access' as opposed to 'speculative 
execution'?


-- 
"When a true genius appears in the world, you may know him by this sign, 
that the dunces are all in confederacy against him."

Jonathan Swift.

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

#51755

The Natural Philosopher wrote:
> On 20/11/2018 21:31, Computer Nerd Kev wrote:
>> In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> 
>> wrote:
>>> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher 
>>> <tnp@invalid.invalid> wrote:
>>>
>>>> Thse CPU bugs are all about caching.
>>>
>>> Not quite all. The meltdown class of bugs are about caching, but the
>>> spectre class bugs are about speculative execution.
>>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>>>
>>> For maximum safety, disable execution on all but one core/thread. :-(
>>
>> I don't think that would do. The Pentium Pro was apparantly the first
>> Intel x86 CPU to support speculative execution, and it was only
>> available as a single-core CPU. The speculatively executed
>> instructions can be done with a single core while it's waiting for
>> a memory read or similar.
>>
> 
> Intersting that people differentiate between 'speculative execution' and 
> 'caching'.
> 
> Or is caching 'speculative memory access' as opposed to 'speculative 
> execution'?
> 
> 

You can find a lot of the buzzwords here.

https://en.wikipedia.org/wiki/Out-of-order_execution

    "out-of-order execution became more common, and was featured in ...
     Intel Pentium Pro (1995) ..."

And this is the level of optimization used when I first
started playing with hardware.

https://en.wikipedia.org/wiki/Delay_slot

    Paul

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

#51756

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 20/11/2018 21:31, Computer Nerd Kev wrote:
>> In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>>> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>> Thse CPU bugs are all about caching.
>>>
>>> Not quite all. The meltdown class of bugs are about caching, but the
>>> spectre class bugs are about speculative execution.
>>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>>>
>>> For maximum safety, disable execution on all but one
>>> core/thread. :-(
>>
>> I don't think that would do. The Pentium Pro was apparantly the first
>> Intel x86 CPU to support speculative execution, and it was only
>> available as a single-core CPU. The speculatively executed
>> instructions can be done with a single core while it's waiting for
>> a memory read or similar.

That would indeed be ineffective against classic Spectre and Meltdown.
There are some microarchitectural attacks that impact hyperthreading,
however, so the paranoid are either disabling that or (more
constructively) attempting to change operating systems and hypervisors
to avoid co-scheduling different security domains on the same core.

As far as I know there are no known variants that depend specifically on
multiple (single-threaded) cores in single system though, i.e. that
would be mitigated by disabling all cores but one.

> Intersting that people differentiate between 'speculative execution'
> and 'caching'.

Yes, they are very different technologies.

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

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

#51757

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 20/11/2018 21:31, Computer Nerd Kev wrote:
>> In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>>> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>
>>>> Thse CPU bugs are all about caching.
>>>
>>> Not quite all. The meltdown class of bugs are about caching, but the
>>> spectre class bugs are about speculative execution.
>>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>>>
>>> For maximum safety, disable execution on all but one core/thread. :-(
>> 
>> I don't think that would do. The Pentium Pro was apparantly the first
>> Intel x86 CPU to support speculative execution, and it was only
>> available as a single-core CPU. The speculatively executed
>> instructions can be done with a single core while it's waiting for
>> a memory read or similar.
>> 
> 
> Intersting that people differentiate between 'speculative execution' and 
> 'caching'.
> 
> Or is caching 'speculative memory access' as opposed to 'speculative 
> execution'?

You could call it (caching) that (speculative memory access).

Caching works on the principal that most programs often access memory 
addresses that are nearby other memory addresses previously accessed by 
the same program.  I.e., consider walking an array (X[0] ... X[100]) 
and doing something.  First access is to X[0], second to X[1], third to 
X[2] and so on.  Caching works because when the program reads X[0] the 
cache actually reads in memory that holds X[0]...X[10].  So now 
accesses to X[1]...X[10] happen from the cache instead of each directly 
from main memory.

So, yes, in a way it is "speculative memory access".  The hardware does 
not know (with certianty) that retreiving X[1] will occur soon in time 
after X[0].  But such patterns happen often enough that the number of 
wins outnumber the number of losses, and the CPU sees an apparent 
increase in speed of access of main memory.

Speculative execution is actually performing program steps ahead of 
time.  I.e., if you had this if statement:
  
  status=compute_status_value();
  if (status == 5) {
     a=a+1;
  } else {
     a=a-1;
  }

Before you arrive at the "if", before the value of "status" is finished 
being computed, the hardware does not know which of a+1 or a-1 will be 
executed.  So it simply performs both, computing an a1=a+1 and a2=a-1.  
Then, a cycle or two later, when the value of status is fully computed, 
it will either keep a1 or keep a2 (depending on status' value) and 
throw the other one away.

If the wait for computing status is 2 cycles, and a+1 and a-1 each take 
one cycle, and two alu's are available, then in the 2 cycles it takes 
to obtain the final value of 'status' the cpu can also compute a+1 and 
a-1, and complete the computation of status and the final one of a+1 or 
a-1 in two cycles.

If instead it waited until status was final (2 cycles) and only then 
performed one of a+1 or a-1 (1 cycle) the complete computation would 
take 3 cycles (2 waiting for status, 1 computing a-1 [assuming status 
was not 5]).

This is the basic idea.  Where Intel went with this basic idea in later 
'i' chips was to run not just two instructions during wait time for 
other data, but hundreds (during waiting times that are otherwise 
thousands of clock cycles long), all while keeping track of the 
temporary answers until it was known which ones were needed, and 
deleting the unnecessary computational output.  Unfortunately for them, 
the step of "deleting the unnecessary computational output" did not 
clean up *all* visible state changes.  And it is the stuff that wasn't 
fully cleaned up that allows the timing side-channel attacks that are 
appearing with great regularity.

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

#51758

Rich <rich@example.invalid> writes:
> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Intersting that people differentiate between 'speculative execution' and 
>> 'caching'.
>> 
>> Or is caching 'speculative memory access' as opposed to 'speculative 
>> execution'?
>
> You could call it (caching) that (speculative memory access).
>
> Caching works on the principal that most programs often access memory 
> addresses that are nearby other memory addresses previously accessed by 
> the same program.  I.e., consider walking an array (X[0] ... X[100]) 
> and doing something.  First access is to X[0], second to X[1], third to 
> X[2] and so on.  Caching works because when the program reads X[0] the 
> cache actually reads in memory that holds X[0]...X[10].  So now 
> accesses to X[1]...X[10] happen from the cache instead of each directly 
> from main memory.

That’s certainly a useful outcome of the way memory access works, but
it’s not inherent to caching. A CPU could (hypothetically) cache
individual words and still get a (smaller) performance improvement from
the cache hits. Moreover in the context of this thread it’s the caching
as such, rather than the bulk reads, that leads to the cache being
usable as a communication channel.

Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
(at a minimum), but when we talk about filesystem caching, we don’t mean
that bulk I/O, we mean the OS keeping large numbers of those blocks in
RAM to avoid having to read them again in the near future.

At any rate conflating caching with speculative execution is a
non-starter.

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

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

#51763

On 21/11/2018 13:24, Richard Kettlewell wrote:
> Rich <rich@example.invalid> writes:
>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> Intersting that people differentiate between 'speculative execution' and
>>> 'caching'.
>>>
>>> Or is caching 'speculative memory access' as opposed to 'speculative
>>> execution'?
>>
>> You could call it (caching) that (speculative memory access).
>>
>> Caching works on the principal that most programs often access memory
>> addresses that are nearby other memory addresses previously accessed by
>> the same program.  I.e., consider walking an array (X[0] ... X[100])
>> and doing something.  First access is to X[0], second to X[1], third to
>> X[2] and so on.  Caching works because when the program reads X[0] the
>> cache actually reads in memory that holds X[0]...X[10].  So now
>> accesses to X[1]...X[10] happen from the cache instead of each directly
>> from main memory.
> 
> That’s certainly a useful outcome of the way memory access works, but
> it’s not inherent to caching. A CPU could (hypothetically) cache
> individual words and still get a (smaller) performance improvement from
> the cache hits. Moreover in the context of this thread it’s the caching
> as such, rather than the bulk reads, that leads to the cache being
> usable as a communication channel.
> 
> Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
> (at a minimum), but when we talk about filesystem caching, we don’t mean
> that bulk I/O, we mean the OS keeping large numbers of those blocks in
> RAM to avoid having to read them again in the near future.
> 
> At any rate conflating caching with speculative execution is a
> non-starter.
> 
My statement was more semantic than technical


-- 
Climate Change: Socialism wearing a lab coat.

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

#51764

On 2018-11-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 21/11/2018 13:24, Richard Kettlewell wrote:
>> Rich <rich@example.invalid> writes:
>>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> Intersting that people differentiate between 'speculative execution' and
>>>> 'caching'.
>>>>
>>>> Or is caching 'speculative memory access' as opposed to 'speculative
>>>> execution'?
>>>
>>> You could call it (caching) that (speculative memory access).
>>>
>>> Caching works on the principal that most programs often access memory
>>> addresses that are nearby other memory addresses previously accessed by
>>> the same program.  I.e., consider walking an array (X[0] ... X[100])
>>> and doing something.  First access is to X[0], second to X[1], third to
>>> X[2] and so on.  Caching works because when the program reads X[0] the
>>> cache actually reads in memory that holds X[0]...X[10].  So now
>>> accesses to X[1]...X[10] happen from the cache instead of each directly
>>> from main memory.
>> 
>> That’s certainly a useful outcome of the way memory access works, but
>> it’s not inherent to caching. A CPU could (hypothetically) cache
>> individual words and still get a (smaller) performance improvement from
>> the cache hits. Moreover in the context of this thread it’s the caching
>> as such, rather than the bulk reads, that leads to the cache being
>> usable as a communication channel.
>> 
>> Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
>> (at a minimum), but when we talk about filesystem caching, we don’t mean
>> that bulk I/O, we mean the OS keeping large numbers of those blocks in
>> RAM to avoid having to read them again in the near future.
>> 
>> At any rate conflating caching with speculative execution is a
>> non-starter.
>> 
> My statement was more semantic than technical

???? It is not correct sematically (whatever you mean by that) either. 
>
>

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

#51785

On 21/11/2018 23:53, William Unruh wrote:
> On 2018-11-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 21/11/2018 13:24, Richard Kettlewell wrote:
>>> Rich <rich@example.invalid> writes:
>>>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>> Intersting that people differentiate between 'speculative execution' and
>>>>> 'caching'.
>>>>>
>>>>> Or is caching 'speculative memory access' as opposed to 'speculative
>>>>> execution'?
>>>>
>>>> You could call it (caching) that (speculative memory access).
>>>>
>>>> Caching works on the principal that most programs often access memory
>>>> addresses that are nearby other memory addresses previously accessed by
>>>> the same program.  I.e., consider walking an array (X[0] ... X[100])
>>>> and doing something.  First access is to X[0], second to X[1], third to
>>>> X[2] and so on.  Caching works because when the program reads X[0] the
>>>> cache actually reads in memory that holds X[0]...X[10].  So now
>>>> accesses to X[1]...X[10] happen from the cache instead of each directly
>>>> from main memory.
>>>
>>> That’s certainly a useful outcome of the way memory access works, but
>>> it’s not inherent to caching. A CPU could (hypothetically) cache
>>> individual words and still get a (smaller) performance improvement from
>>> the cache hits. Moreover in the context of this thread it’s the caching
>>> as such, rather than the bulk reads, that leads to the cache being
>>> usable as a communication channel.
>>>
>>> Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
>>> (at a minimum), but when we talk about filesystem caching, we don’t mean
>>> that bulk I/O, we mean the OS keeping large numbers of those blocks in
>>> RAM to avoid having to read them again in the near future.
>>>
>>> At any rate conflating caching with speculative execution is a
>>> non-starter.
>>>
>> My statement was more semantic than technical
> 
> ???? It is not correct sematically (whatever you mean by that) either.

Oh it is.

Speculative executins get stored - cached in case trhey are needed
Memory contents get strored - cached - in case they are needed
Disc sectors get stored - cached - ion case they are needed

speculative execution/speculative memory read/speculative disc read.

I dont see any difference philosophicallyu - just at implementation level.


>>
>>


-- 
  “A leader is best When people barely know he exists. Of a good leader, 
who talks little,When his work is done, his aim fulfilled,They will say, 
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

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

#51787

On 2018-11-24, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 21/11/2018 23:53, William Unruh wrote:
>> On 2018-11-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 21/11/2018 13:24, Richard Kettlewell wrote:
>>>> Rich <rich@example.invalid> writes:
>>>>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>> Intersting that people differentiate between 'speculative execution' and
>>>>>> 'caching'.
>>>>>>
>>>>>> Or is caching 'speculative memory access' as opposed to 'speculative
>>>>>> execution'?
>>>>>
>>>>> You could call it (caching) that (speculative memory access).
>>>>>
>>>>> Caching works on the principal that most programs often access memory
>>>>> addresses that are nearby other memory addresses previously accessed by
>>>>> the same program.  I.e., consider walking an array (X[0] ... X[100])
>>>>> and doing something.  First access is to X[0], second to X[1], third to
>>>>> X[2] and so on.  Caching works because when the program reads X[0] the
>>>>> cache actually reads in memory that holds X[0]...X[10].  So now
>>>>> accesses to X[1]...X[10] happen from the cache instead of each directly
>>>>> from main memory.
>>>>
>>>> That’s certainly a useful outcome of the way memory access works, but
>>>> it’s not inherent to caching. A CPU could (hypothetically) cache
>>>> individual words and still get a (smaller) performance improvement from
>>>> the cache hits. Moreover in the context of this thread it’s the caching
>>>> as such, rather than the bulk reads, that leads to the cache being
>>>> usable as a communication channel.
>>>>
>>>> Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
>>>> (at a minimum), but when we talk about filesystem caching, we don’t mean
>>>> that bulk I/O, we mean the OS keeping large numbers of those blocks in
>>>> RAM to avoid having to read them again in the near future.
>>>>
>>>> At any rate conflating caching with speculative execution is a
>>>> non-starter.
>>>>
>>> My statement was more semantic than technical
>> 
>> ???? It is not correct sematically (whatever you mean by that) either.
>
> Oh it is.
>
> Speculative executins get stored - cached in case trhey are needed

The point of speculative execution is not storage, but execution. Yes,
the result gets stored in the cpu but that storage is not the purpose.
The purpose is the exectution of the instructions that are not yet
called for. 


> Memory contents get strored - cached - in case they are needed
> Disc sectors get stored - cached - ion case they are needed
>
> speculative execution/speculative memory read/speculative disc read.
>
> I dont see any difference philosophicallyu - just at implementation level.

An example of why "Philosophical"  often gets such a bad rap.
>
>
>>>
>>>
>
>

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

#51792

On 24/11/2018 13:53, William Unruh wrote:
> On 2018-11-24, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 21/11/2018 23:53, William Unruh wrote:
>>> On 2018-11-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 21/11/2018 13:24, Richard Kettlewell wrote:
>>>>> Rich <rich@example.invalid> writes:
>>>>>> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>> Intersting that people differentiate between 'speculative execution' and
>>>>>>> 'caching'.
>>>>>>>
>>>>>>> Or is caching 'speculative memory access' as opposed to 'speculative
>>>>>>> execution'?
>>>>>>
>>>>>> You could call it (caching) that (speculative memory access).
>>>>>>
>>>>>> Caching works on the principal that most programs often access memory
>>>>>> addresses that are nearby other memory addresses previously accessed by
>>>>>> the same program.  I.e., consider walking an array (X[0] ... X[100])
>>>>>> and doing something.  First access is to X[0], second to X[1], third to
>>>>>> X[2] and so on.  Caching works because when the program reads X[0] the
>>>>>> cache actually reads in memory that holds X[0]...X[10].  So now
>>>>>> accesses to X[1]...X[10] happen from the cache instead of each directly
>>>>>> from main memory.
>>>>>
>>>>> That’s certainly a useful outcome of the way memory access works, but
>>>>> it’s not inherent to caching. A CPU could (hypothetically) cache
>>>>> individual words and still get a (smaller) performance improvement from
>>>>> the cache hits. Moreover in the context of this thread it’s the caching
>>>>> as such, rather than the bulk reads, that leads to the cache being
>>>>> usable as a communication channel.
>>>>>
>>>>> Analogously, disk reads typically happen in 512-byte or 4096-byte blocks
>>>>> (at a minimum), but when we talk about filesystem caching, we don’t mean
>>>>> that bulk I/O, we mean the OS keeping large numbers of those blocks in
>>>>> RAM to avoid having to read them again in the near future.
>>>>>
>>>>> At any rate conflating caching with speculative execution is a
>>>>> non-starter.
>>>>>
>>>> My statement was more semantic than technical
>>>
>>> ???? It is not correct sematically (whatever you mean by that) either.
>>
>> Oh it is.
>>
>> Speculative executins get stored - cached in case trhey are needed
> 
> The point of speculative execution is not storage, but execution. Yes,
> the result gets stored in the cpu but that storage is not the purpose.
> The purpose is the exectution of the instructions that are not yet
> called for.
> 
> 
>> Memory contents get strored - cached - in case they are needed
>> Disc sectors get stored - cached - ion case they are needed
>>
>> speculative execution/speculative memory read/speculative disc read.
>>
>> I dont see any difference philosophicallyu - just at implementation level.
> 
> An example of why "Philosophical"  often gets such a bad rap.
>>
Wj example of why tekky pedants get such a bad rap

>>
>>>>
>>>>
>>
>>


-- 
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah 
puts mah heel on um jess the same if'n I catches him around mah chillun".

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

#51793

On Sat, 24 Nov 2018 13:53:48 -0000 (UTC), William Unruh wrote:
>
>> Speculative executins get stored - cached in case trhey are needed
>
> The point of speculative execution is not storage, but execution. Yes,
> the result gets stored in the cpu but that storage is not the purpose.
> The purpose is the exectution of the instructions that are not yet
> called for. 

Suppose that's (cached [in CPU]) was meant.

[...]

Could you both trim the quote a little? Your readers have it easier .
-- 
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

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

#51797

On 24/11/2018 20:47, Andreas Kohlbach wrote:
> On Sat, 24 Nov 2018 13:53:48 -0000 (UTC), William Unruh wrote:
>>
>>> Speculative executins get stored - cached in case trhey are needed
>>
>> The point of speculative execution is not storage, but execution. Yes,
>> the result gets stored in the cpu but that storage is not the purpose.
>> The purpose is the exectution of the instructions that are not yet
>> called for.
> 
> Suppose that's (cached [in CPU]) was meant.
> 
thank you.

Looking from a remoter perspective all these flaws are down to the 
system trying to second guess now what will in fact be the case later.

and the answers are stored *in case* they prove useful.




-- 
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

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

#51800

On Sun, 25 Nov 2018 07:51:31 +0000, The Natural Philosopher wrote:
>
> Looking from a remoter perspective all these flaws are down to the
> system trying to second guess now what will in fact be the case later.
>
> and the answers are stored *in case* they prove useful.

Not the by me mentioned Portshmash (no one here seems to want to talk
about), "listening" on other threads to skim data from there.
-- 
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

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

#51790

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 21/11/2018 23:53, William Unruh wrote:
>> On 2018-11-21, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> My statement was more semantic than technical
>> 
>> ???? It is not correct sematically (whatever you mean by that) either.
> 
> Oh it is.
> 
> Speculative executins get stored - cached in case trhey are needed
> Memory contents get strored - cached - in case they are needed
> Disc sectors get stored - cached - ion case they are needed
> 
> speculative execution/speculative memory read/speculative disc read.
> 
> I dont see any difference philosophicallyu - just at implementation 
> level.

Then you are utilizing a definition of cache that is too generic and is 
at odds with what computer artichitects use for the definition of 
cache.

Caching is not "storage until needed".

Rather caching is maintaining a *copy* of slow "storage" in a faster 
"storage" upon first access to slow storage for the purpose of making 
subsequent access (accesses 2...n) to the same storage area faster.  
The copy aspect is somewhat critical to grasp here.

For both memory contents and disk contents, this is what happens.  The 
cache stores a second *copy* of memory (or a second *copy* of disk) in 
a storage until that is faster to access than the master copy.

This also means (assuming that the cache is write through) that the 
contents of cache can be deleted at any time, with no effect on the 
state of the computer (only an effect on the net performance).

Speculative execution results are "stored" yes, but not as a *copy* of 
another memory, and not for accelerating access to the stored data for 
*subsequent accesses to that same data*.  Speculative execution results 
are are not a copy of any other storage while they are stored, and they 
are utilized exactly once, when the decision is made that the results 
should be used, else they are simply thrown away.

And, deletion of speculative execution results before they would 
otherwise be utilized would result in a different program state, 
because the only copy of the pre-computed state would have been 
deleted.

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

#51808

On 18/11/18 21:06, Carlos E.R. wrote:
> On 17/11/2018 12.53, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 17/11/2018 11.10, J.O. Aho wrote:
>>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>>>
>>>>
>>>> And it will run slower in the future as more and more serious security
>>>> vulnerabilities are found in intel hardware which then has to be fixed
>>>> in software.
>>>>
>>>> The only CPU which seems to have been safe to use has been RISC-V, just
>>>> hope we will see desktop grade CPU's soon.
>>
>> Lots of other older CPUs are also immune to this attack class, they’re
>> just very slow by modern standards.
>>
>>> Well, possibly the smaller the instruction set, the less danger of
>>> fucking up.
>>
>> It’s not really anything to do with the size of the instruction set. The
>> microarchitectural attacks are essentially about how the instruction set
>> is implemented efficiently (mostly in time terms although the AVX warmup
>> sidechannel depends on a power usage optimization).
> 
> I don't mean exactly that the size is involved, but that fewer
> instructions and less complex instructions probably produce less
> complexity of the chip itself and fewer chances of errors. The
> complexity goes to the kernel and applications instead, 

I was having the same idea but with no clue of the reason of 
this ... could you delve a bit deeper in this aspect (= why 
hw simplification would necessarily imply sw complication ?) ?
I mean, I'm quite convinced that LONGER sw (in binary 
outline) is a result of RISC instead of CISC, but I'm unsure 
about the greater complexity (as I don't have a suitable 
definition of complexity, or at least not a quantitative one)

Another thing complicates my view (and this even from an HW 
point of view) : some times simplified layers imply more 
layers to get an high level task out of the "iron".

So I'm wondering whether a reduced set of instructions is 
just a mean of MOVING complexity elsewhere and distribute it 
differently (where with "elsewhere" I don't necessarily mean 
from HW -> to SW, but maybe also from the CPU to other 
features of the overall architecture).

P.S. I'm not questioning about the proved less vulnerable 
risc architecture, just trying to understand why



> but these can be
> corrected, whereas the cpu itself can't (some parts can, firmware updates).
> 
> Just an educated guess :-)
> 
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#51813

On 30/11/2018 10:32, Soviet_Mario wrote:
> On 18/11/18 21:06, Carlos E.R. wrote:
>> On 17/11/2018 12.53, Richard Kettlewell wrote:
>>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>>> On 17/11/2018 11.10, J.O. Aho wrote:
>>>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1> 
>>>>>>
>>>>>>
>>>>>
>>>>> And it will run slower in the future as more and more serious security
>>>>> vulnerabilities are found in intel hardware which then has to be fixed
>>>>> in software.
>>>>>
>>>>> The only CPU which seems to have been safe to use has been RISC-V, 
>>>>> just
>>>>> hope we will see desktop grade CPU's soon.
>>>
>>> Lots of other older CPUs are also immune to this attack class, they’re
>>> just very slow by modern standards.
>>>
>>>> Well, possibly the smaller the instruction set, the less danger of
>>>> fucking up.
>>>
>>> It’s not really anything to do with the size of the instruction set. The
>>> microarchitectural attacks are essentially about how the instruction set
>>> is implemented efficiently (mostly in time terms although the AVX warmup
>>> sidechannel depends on a power usage optimization).
>>
>> I don't mean exactly that the size is involved, but that fewer
>> instructions and less complex instructions probably produce less
>> complexity of the chip itself and fewer chances of errors. The
>> complexity goes to the kernel and applications instead, 
> 
> I was having the same idea but with no clue of the reason of this ... 
> could you delve a bit deeper in this aspect (= why hw simplification 
> would necessarily imply sw complication ?) ?
> I mean, I'm quite convinced that LONGER sw (in binary outline) is a 
> result of RISC instead of CISC, but I'm unsure about the greater 
> complexity (as I don't have a suitable definition of complexity, or at 
> least not a quantitative one)
> 
> Another thing complicates my view (and this even from an HW point of 
> view) : some times simplified layers imply more layers to get an high 
> level task out of the "iron".
> 
> So I'm wondering whether a reduced set of instructions is just a mean of 
> MOVING complexity elsewhere and distribute it differently (where with 
> "elsewhere" I don't necessarily mean from HW -> to SW, but maybe also 
> from the CPU to other features of the overall architecture).
> 
> P.S. I'm not questioning about the proved less vulnerable risc 
> architecture, just trying to understand why
> 
> 
AIUI which isnt so much these days all CISC  chips are at core RISC and 
they INTERPRET the instruction sets via microcode .


> 
>> but these can be
>> corrected, whereas the cpu itself can't (some parts can, firmware 
>> updates).
>>
>> Just an educated guess :-)
>>
>>
> 
> 


-- 
Climate Change: Socialism wearing a lab coat.

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

#51716

In article <g5a7ouFjvp8U1@mid.individual.net>
"J.O. Aho" <user@example.net> wrote:
>
> On 11/17/18 3:21 AM, Nomen Nescio wrote:
> > <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
> >
>
> And it will run slower in the future as more and more serious security
> vulnerabilities are found in intel hardware which then has to be fixed
> in software.
>
> The only CPU which seems to have been safe to use has been RISC-V, just
> hope we will see desktop grade CPU's soon.

And to think Intel was responsible for killing Alpha, then 
helping foist that piece of shit IA64 on us.

Nice to see Intel taking it up the ass finally.

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

#51729

On Sun, 18 Nov 2018 06:23:08 +0100, Anonymous Remailer (austria) wrote:

> And to think Intel was responsible for killing Alpha, then helping foist
> that piece of shit IA64 on us.

	You might like to learn that IA64 is immune to all these attacks 
that are plaguing the x86 architecture.

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

#51733

> 
> On Sun, 18 Nov 2018 06:23:08 +0100, Anonymous Remailer (austria) wrote:
> 
> 
>> And to think Intel was responsible for killing Alpha, then helping foist
>> that piece of shit IA64 on us.
> 
> You might like to learn that IA64 is immune to all these attacks
> that are plaguing the x86 architecture.

  Unfortunately, the IA64 was developed by a joint partnership between Intel and Hewlett-Packard.  So you probably can't get an IA64 unless you but an HP.  I am personally through with HPs because the HP laptops I have owned only lasted 2 to 3 years.  I am still using my last one for a security camera system, but its screen died after only two years of use.

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

#51746

In article <e3dcf1fef90f2c710e09598f70534a67@hoi-polloi.org>
Anonymous <anonymous@hoi-polloi.org> wrote:
>
> >
>>
>> On Sun, 18 Nov 2018 06:23:08 +0100, Anonymous Remailer 
(austria)
>> wrote:
>>
>>
>>> And to think Intel was responsible for killing Alpha, then 
helping
>>> foist that piece of shit IA64 on us.
>>
>> You might like to learn that IA64 is immune to all these 
attacks
>> that are plaguing the x86 architecture.
>
>   Unfortunately, the IA64 was developed by a joint partnership between
>   Intel and Hewlett-Packard.  So you probably can't get an IA64 unless
>   you but an HP.  I am personally through with HPs because the HP
>   laptops I have owned only lasted 2 to 3 years.  I am still using my
>   last one for a security camera system, but its screen died after
>   only two years of use.

We eventually moved off HP because they slowly locked us out of 
our own equipment with firmware restrictions and AHS.

When you spend over $35K per server in basically disposable 
hardware alone, then add another $50-100K each in software / 
licensing, you'd like to believe you'll get more than one year's 
access to firmware and unrestricted access to logging to 
reassure your hardware runs reliably.  HP seems to feel you as a 
customer are just incompetents in need of assistance from idiots 
in India.

We went with 240 Intel blade servers and 20 chassis plus some 
NetApps.  The Intel has been very good.  The jury is still out 
if the NetApp buy was a good decision.  They have been okay, but 
they break way more frequently than IBM or HP storage.  We have 
some old IBM DS4300 and HP P2000G3s that still chug along eating 
the occasional disk.  The NetApps have eaten SFPs, disks, power 
supplies, memory, power cords, etc.. There's a NetApp guy in the 
break room a couple times a week.  If their storage is so good, 
why do they need clusters?  Or is it because it's so bad, they 
need them?

We had an old Vaxcluster at one time that was always up and 
running.  I think it still is somewhere on some kind of software 
emulators.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web