flat assembler
Message board for the users of flat assembler.
Index
> High Level Languages > Cmpsb multithread? |
Author |
|
bitRAKE 19 Oct 2020, 19:02
I built it with clang and didn't get a single "*".
Kind of curious what you're running on? Running on a Ryzen 2700, atm. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
19 Oct 2020, 19:02 |
|
l4m2 19 Oct 2020, 19:22
I'm on i7-4790
|
|||
19 Oct 2020, 19:22 |
|
bitRAKE 19 Oct 2020, 22:59
I didn't think it was possible to split the update but tried to catch a problem with multiple threads. Still nothing.
If this program returns zero on your machine then your results are coming from somewhere else. Edit: whoops I didn't change anything, lol. Edit: this one catches it happening - definitely surprised. 17586658 splits out of 15*2^32.
_________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||||||||||
19 Oct 2020, 22:59 |
|
bitRAKE 20 Oct 2020, 01:02
I'm sorry about the subsystem version, but I don't have an old linker on this machine. It doesn't use anything fancy - should probably run fine on XP.
|
|||
20 Oct 2020, 01:02 |
|
revolution 20 Oct 2020, 03:42
What does the addition of lock do?
|
|||
20 Oct 2020, 03:42 |
|
bitRAKE 20 Oct 2020, 05:49
I've added the option to toggle a single byte and added some comments about performance: https://github.com/bitRAKE/fasmg_playground/blob/master/win64.coff/cmpsb_split.g
Adding a lock to the data would obviously prevent the data from changing during another thread access. The downside is that I'd have 15 threads lining up for access to that data and the execution time goes up substantially. The main goal here was to show that the two reads of CMPSB can be split. It's not exactly a practical use-case. If you're inquiring about the LOCK ADD existing in the code - that is to ensure the counts are correct and not to synchronize anything else. My processor can hide the collisions if there is other bus traffic - that is why the threads need to be high-priority to force collisions. I'm impressed with how well it does. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
20 Oct 2020, 05:49 |
|
revolution 20 Oct 2020, 06:05
I think that what is really being tested here is the CPU data access patterns.
I see no reason why the CPU should ensure the two reads by cmpsb are protected from another thread's access. It is always the programmers responsibility to ensure threads don't stomp on other's data. |
|||
20 Oct 2020, 06:05 |
|
bitRAKE 20 Oct 2020, 06:35
I agree. Could even compare it to two basic instructions and see if it has the same profile. Or we could see if all processors perform the two reads in the same order.
|
|||
20 Oct 2020, 06:35 |
|
revolution 20 Oct 2020, 06:45
bitRAKE wrote: Adding a lock to the data would obviously prevent the data from changing during another thread access. |
|||
20 Oct 2020, 06:45 |
|
bitRAKE 20 Oct 2020, 07:17
Illegal instruction.
_________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
20 Oct 2020, 07:17 |
|
l4m2 20 Oct 2020, 16:42
Changed changer loop to
Code: lock incl (x) PS. Why High Level Lang? C++ part only serve putchar and thread |
|||
20 Oct 2020, 16:42 |
|
revolution 20 Oct 2020, 23:13
l4m2 wrote: PS. Why High Level Lang? C++ part only serve putchar and thread |
|||
20 Oct 2020, 23:13 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.