Errors, bugs, questions - page 2506

New comment
 
Vict:
Justify

Registers are measured in bits, not bytes. Therefore this line is used incorrectly in the rest of the code:

#define  CACHE_LINE_SIZE 64
 
Francuz:

Registers are measured in bits, not bytes. Therefore this line is used incorrectly in the rest of the code:

No, you are saying something strange. I'm not going to prove it. Look at the documentation on the processor, read here https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

On x86 cache lines are 64 bytes

I don't need registers, I'm not talking about them at all.

Aligning to cache line and knowing the cache line size
Aligning to cache line and knowing the cache line size
  • 2011.09.02
  • MetallicPriestMetallicPriest 12.1k2929 gold badges135135 silver badges259259 bronze badges
  • stackoverflow.com
To prevent false sharing, I want to align each element of an array to a cache line. So first I need to know the size of a cache line, so I assign each element that amount of bytes. Secondly I want the start of the array to be aligned to a cache line. I am using Linux and 8-core x86 platform...
 
Vict:

No, you are saying something strange. I'm not going to prove it. Look at the documentation for the processor, read here https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

I don't need registers, I'm not talking about them at all.

Hmm... Okay. (clears throat) Anyway, the cache varies from model to model. There's no way to know its size from the software. That's why it's silly to take it as a guide. But all the processors have two types of registers and it is the size of registers that skilled programmers focus on. And even this register-orientation is not always successful because between the program and the processor there are a compiler and an operating system.

Besides this line is calculated incorrectly and without registers:

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);
 
Francuz:

Hmm... Okay. Anyway, the cache varies from processor to processor. And there's no way to know its size from the software. That's why it's silly to be guided by it. But all the processors have two types of registers and it is the size of registers that skilled programmers focus on. And even register-size targeting does not always save you because the compiler and operating system are situated between the program and the processor.

Again, things are evolving, more and more emphasis is placed on multithreading, and here's a cross std library to tell you all about it

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Besides, this line is calculated incorrectly and doesn't take registers into account:
Maybe, but so far you haven't convinced me.
std::hardware_destructive_interference_size, std::hardware_constructive_interference_size - cppreference.com
  • en.cppreference.com
These constants provide a portable way to access the L1 data cache line size.
 
Vict:

Again no, things are evolving, more and more emphasis is placed on multithreading, and here you go - the cross std library will tell you everything

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Maybe, but so far you haven't convinced me.

It won't tell you, it will tell you. Read the specification carefully.


Although I'm not quite sure what shift you wanted, but it's easy to understand: an absolute address is completely useless in calculations. Have you forgotten that the reference point for memory is the address of the structure? And you probably wanted to get the offset of an array in a block of structure memory? And that turns out to be the difference of addresses of the structure and the zero element of the array.

 
Artyom Trishkin:

If there is no value in the buffer on the bar, it should be explicitly written in the buffer. I.e., if the calculated value should be output to the buffer - we write it to the buffer, otherwise - we write an empty value.

Thank you, Artem.

 
Francuz:

Although I'm not quite sure what offset you wanted, it's easy to understand the bug: an absolute address is completely useless in calculations. Have you forgotten that the memory reference point is the structure address? And you probably wanted to get the offset of an array in a block of structure memory? And that's the difference between the addresses of the structure and the zero element of the array.

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);
                                3        1                    2                  4

Actions in order:

1 - get the address of the first ar[] element in the current data structure.

2. find out its offsets from the beginning of cache line

3. find out how many bytes from it to the end of cache line

4. find out how many bytes will fit into this space till the end of the cache line.


Did you run it on your computer? Is there a difference in speed? Or is it just me?

 
Vict:

2. find out its offsets from the start of the cache line

What makes you think that's any way to find out its offset?

 
What is causing this slowdown?

Forum on trading, automated trading systems and trading strategy testing

Bugs, bugs, questions

fxsaber, 2019.07.09 11:13

   Data data[];
   
   ArrayResize(data, 32768);

There is a 6x slowdown happening!

 
fxsaber:
What are these brakes for?
A dynamic array has more checks, Renat once wrote, I can't find the post, just talking about index access, why it is significantly slower than pluses
1...249925002501250225032504250525062507250825092510251125122513...3189
New comment
Reason: