1 hour ago, mrueedi said:

Sorry, this is rubbish. Here is some education from 2005 for you. This guy ran 54965 threads on a Windows machine. The blogpost is so old, that it only exists on the wayback machine. 

https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160

Quote

The  /std options are available in Visual Studio 2017 and later. 

std:c11
The /std:c11 option enables ISO C11 conformance. It's available starting in Visual Studio 2019 version 16.8.

std:thread is C++11, which is pthreads on mac/linux dating back to the 90s and MSVC++2018 for windows.

prior to that windows threading required a third party library like boost, or writing at a very low level similar to that for the PS3 cell processors.

Microsoft held out adopting the standard until they had no developers left and Windows Phone was completely dead, its implementation is still weak at best, with very naive thread scheduling, slightly better if you go for an enterprise or server version of windows.

1 hour ago, mrueedi said:

have programmed capable multi threading solutions with VS98/MFC6.

for what processor?

1 hour ago, mrueedi said:

You are anyway mixing multithreading with multiprocessing. The former is not applied to increase overall performance, only the latter does.

I'm talking about this stuff.

https://digital.library.unt.edu/ark:/67531/metadc619313/m2/1/high_res_d/12124.pdf

And yes, that windows didn't and mostly doesnt.

Which is why Windows [Enterprise] starts getting on the list at the 39th page of

https://browser.geekbench.com/v5/cpu/multicore

(coming to a steam deck near you for $500)

Edited October 21, 20214 yr by mSparks

@mSparks

I must join @mrueedi and tell you're probably mixing up a few things, if I read you right.

I won't comment on the actual Kernel support for threads and whether it is better on Linux or Windows.

On the API side of it, you're right C++11 compliant implementation came only late in Visual Studio, but this is just a semantic wrapper over the underlying low level Win API. The only language support for threading which is not part of the Kernel implementation is the C++11 memory model which is enforced at the compilation level. Clang/LLVM did implement C++11 threading model before VS though.

However Win API offers all the low level API needed to support multi-threading including the C++11 memory model (but you're on your own without a C++11 compiler). Intel TBB has been offering a solid foundation for multi-threading and multi-tasking for a decade (IIRC).

Besides, when implementing core multi-threading support inside a program like this, you might prefer using a task scheduler instead of threads. When you do, you don't have to bother much about the Kernel thread scheduling much: you pin a thread per CPU core, and you dispatch tasks over the continuously running threads (until the task queue empties - I just keep it simple here but of course I'm certain you know about this). I've been even implementing my own task-scheduler with continuation support and work stealing a decade ago with VS2010 (no full C++11 in this version).

In the case of the task-scheduler, I've no knowledge whatsoever whether the Linux kernel is running better than the Windows kernel, but maybe there are some Intel TBB papers/study about this somewhere?

 

1 hour ago, mSparks said:

std:thread is C++11, which is pthreads on mac/linux dating back to the 90s and MSVC++2018 for windows.

std:thread is just another multi threading api. Do you honestly believe there were no native multi threading apis in Windows before 2018? No wonder, you are drawing wrong conclusions.

 

1 hour ago, mSparks said:

prior to that windows threading required a third party library like boost, or writing at a very low level similar to that for the PS3 cell processors.

Do you have any evidence to substantiate that claim? This api e.g. is from 1998 and is the one I used in 2003:
CWinThread | Microsoft Docs

 

1 hour ago, mSparks said:

I'm talking about this stuff.

https://digital.library.unt.edu/ark:/67531/metadc619313/m2/1/high_res_d/12124.pdf

Sorry, this document only talks about the added cost of a threading library vs not using threading at all. Its good, if these tasks are done quickly. It means, the multi threaded app is only a bit slower than a single threaded one. Performance on the other hand you only gain by distributing threads to multiple cores. Which is called parallel processing. What you see on slide 3 here is this stuff....

30 minutes ago, RXP said:

When you do, you don't have to bother much about the Kernel thread scheduling much: you pin a thread per CPU core

Except when you are building an actual highly threaded application (pretty much anything real world) when you have many more threads than cores, and you need to rely on the scheduler to make the most efficient use of the cpu cores.

This is what the M1 upgraded, what pthreads has done for decades, and what MS is still mostly taking a "round robin" approach to. that makes a huge difference to the performance you get.

https://superuser.com/questions/414604/difference-between-the-windows-and-linux-thread-scheduler

30 minutes ago, mrueedi said:

Do you have any evidence to substantiate that claim? This api e.g. is from 1998 and is the one I used in 2003:
CWinThread | Microsoft Docs

Well, MFC is pretty clearly a third part library like boost only made by Microsoft and only works on MS windows. 

pthreads is part of POSIX you just add the header for:

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

Lets go back to what I said:

On 10/18/2021 at 11:53 PM, mSparks said:

But the truth of the matter is the legacy cruft is in windows, which has had no major investment since windows NT in the mid 90s. Still mostly 16/32bits internally, virtually no software with multithread support (MS only added std:thread to their build tools/VC++ in 2018), and even those that do are crippled by the ancient thread scheduler in the windows kernel.

Are you really saying you disagree with the statement that up until very recently windows software performance was predominately single core performance?

Edited October 21, 20214 yr by mSparks

It is a X-Plane 12 topic and I believe it would be best this sub-topic about threading forks out, but I've just found an interesting site where they are comparing lots of different systems and benchmark tests. Here is Win vs Linux for "Multi-Core" https://openbenchmarking.org/result/2110190-TJ-2110193TJ40&stis=bXVsdGljb3Jl&ppt=D and for "CPU Massive" https://openbenchmarking.org/result/2110190-TJ-2110193TJ40&stis=bXVsdGljb3Jl&ppt=D&stis=Y3B1LW1hc3NpdmU&ppt=D (in short: Linux overall better on these 2 suites).

13 minutes ago, mSparks said:

Are you really saying you disagree with the statement that up until very recently windows software performance was predominately single core performance?

Yes, absolutely, this statement is 100% wrong. Where do you have that from?

I am running a modern flight simulator on Windows right now and see that there are 148 threads, distributed over all 16 cores. Even every single thread is distributed to all 16 cores to some degree (at least those with meaningful activity). Overall hardware use is pretty close to balanced usage over all resources.

 

16 minutes ago, RXP said:

It is a X-Plane 12 topic and I believe it would be best this sub-topic about threading forks out, but I've just found an interesting site where they are comparing lots of different systems and benchmark tests. Here is Win vs Linux for "Multi-Core" https://openbenchmarking.org/result/2110190-TJ-2110193TJ40&stis=bXVsdGljb3Jl&ppt=D and for "CPU Massive" https://openbenchmarking.org/result/2110190-TJ-2110193TJ40&stis=bXVsdGljb3Jl&ppt=D&stis=Y3B1LW1hc3NpdmU&ppt=D (in short: Linux overall better on these 2 suites).

kinda, it can stay on topic by being XP12 updated related, see below:

15 minutes ago, mrueedi said:

Where do you have that from?

replying to

On 10/18/2021 at 2:21 PM, Nigel said:

Does any-one know whether Laminar will ensure that CPU's in  X Plane 12 will be able to use all cores?

And posting more than one video/screenshot showing it maxing all cores and making use of HT.

15 minutes ago, mrueedi said:

see that there are 148 threads, distributed over all 16 cores.

And as I explained above, because its using 148 threads on your 8 cores, windows is absolutely crippled and you see virtually no performance gain, because the thread scheduler is giving large amounts of CPU time to threads that do absolutely nothing productive with that CPU time, other than hand over to another thread and burn power. On Linux and Mac 8 cores really is twice the performance of 4 cores regardless of the number of threads, on windows you are talking maybe a 20-30% boost at most, and that falls rapidly the more threads you have.

LR are optimising for performance not how much time windows reports its wasting on scheduling threads.

Edited October 21, 20214 yr by mSparks

39 minutes ago, mSparks said:

And as I explained above, because its using 148 threads on your 8 cores, windows is absolutely crippled and you see virtually no performance gain, because the thread scheduler is giving large amounts of CPU time to threads that do absolutely nothing productive with that CPU time, other than hand over to another thread and burn power. On Linux and Mac 8 cores really is twice the performance of 4 cores regardless of the number of threads, on windows you are talking maybe a 20-30% boost at most, and that falls rapidly the more threads you have.

This I consider just unsubstantiated and uneducated word not allowed talk unless you prove it.

And, why 8 cores? I wrote 16.

 

21 minutes ago, mrueedi said:

talk unless you prove it.

Wont need me to, my main point on this conversation is the steam deck will do exactly that.

When people see for themselves with their own eyes if its low power consumption mobile 4 core 8 thread cpu running linux really does outperform their nearly brand new 6 core 12 thread intel desktop chip running XP11 or 12 on windows

I reckon its gonna, mostly because of everything I just said and:

"because multithreading"

Assuming XP12 does end up also looking significantly better than the rest of the competition as well, should make for a very tasty update. Especially when the windows only competition (and that's not just msfs) is already at a disadvantage by their nature of being written using ancient windows cruft.

Edited October 21, 20214 yr by mSparks

29 minutes ago, mSparks said:

I reckon its gonna, mostly because of everything I just said and:

"because multithreading"

Lacking more details, this is no evidence or prove.

Do you have a link showing that parallel processing scales not in the same magnitude of order on Windows (as you indicated above with the 20-30% boost statement)?

25 minutes ago, mrueedi said:

 

Do you have a link showing that parallel processing scales not in the same magnitude of order on Windows (as you indicated above with the 20-30% boost statement)?

do you have one showing something else? I only have windows server benchmarks, pro and home is worse aiui.

6 minutes ago, mSparks said:

I only have windows server benchmarks, pro and home is worse aiui.

Fine, thanks, that image shows that you were wrong. Only looking at the Windows bars I can see, that performance in principal scales nicely up with the cores. Your "only 20-30% boost" claim does not hold water. For the comparison with Linux we are again lacking details.

23 minutes ago, mrueedi said:

Fine, thanks, that image shows that you were wrong. Only looking at the Windows bars I can see, that performance in principal scales nicely up with the cores. Your "only 20-30% boost" claim does not hold water. For the comparison with Linux we are again lacking details.

ok. If in your world 17 is more than 21 and 2 times 3 is 5 I cant really argue with you.

Like i said, that is a server benchmark, windows home and pro are capped much lower (so you cant use them for server stuff)

24 minutes ago, mSparks said:

ok. If in your world 17 is more than 21 and 2 times 3 is 5 I cant really argue with you.

Cant you see, how it scales? From 4 to 8 threads, there is a solid +98.36% boost. From 8 to 12 threads, the boost is even more than 100%! This is excellent, principally lossless scalability. You are proven wrong by your own image. Your "only 20-30% boost"- and " virtually no performance gain"-claims do not hold water.

And that the non-server windows editions also scale nicely, you can see e.g. here:
Windows vs. Linux Scaling Performance From 16 To 128 Threads With AMD Ryzen Threadripper 3990X - Phoronix

Windows might be a bit worse here and there, but not once by more than a magnitude of order as you make it appear. They absolutely are in the same ballparks.

Edited October 21, 20214 yr by mrueedi

5 minutes ago, mrueedi said:

Cant you see, how it scales? From 4 to 8 threads, there is a solid +98.36% boost. From 8 to 12 threads, the boost is even more than 100%! This is excellent, principally lossless scalability. You are proven wrong by your own image. Your "only 20-30% boost"- and " virtually no performance gain"-claims do not hold water.

And that the non-server windows editions also scale nicely, you can see e.g. here:
Windows vs. Linux Scaling Performance From 16 To 128 Threads With AMD Ryzen Threadripper 3990X - Phoronix

Windows might be a bit worse here and there, but not once by more than a magnitude of order as you make it appear. They absolutely are in the same ballparks.

Is there not msfs benchmarks by processor not gpu limited?