On Thu, 2020-01-09 at 11:13 +0800, Liu Hao wrote: > 在 2020/1/7 下午10:31, Malcolm MacLeod 写道: > > Would you not deem actually being able to use more than half the cores on a > > high core count machine > > as 'essential'? > > It seems like a pretty bad limitation to me, granted not every application > > needs this sort of > > performance but there are certainly lots that do and its only going to get > > more common. > > > > The windows people don't seem to be about to do away with this limitation > > in the near future, and > > machines with more core availability are only getting more and more common. > > So if not a wrapper then what/how would you suggest that people who need > > their programs to support > > this deal with it? > > > > Processor groups are available only from Windows 7 and Windows Server > 2008 R2. If you would like to implement such wrappers in winpthreads, > please make sure they are conditionally excluded when targeting Windows > Server 2003 (which is the default). Yes, of course.
> But such wrappers have to have > references (e.g. they truly conform to the POSIX standard) so we can > verify they really work as expected. Processor groups are a windows concept, unless I am missing something POSIX has no such concept. So I don't know how you propose such a thing could possibly conform to the POSIX standard. Perhaps you can clarify? > It also doesn't seem clear to me why you want to have many many threads > in a single process. I would suggest multiple processes, each of which > has <=64 threads. Some types of programs and workflows are suited to multiple processes (e.g. a web browser like chrome), for such a program using multiple processes is good design and brings lots of benefits. While others are not, e.g. any program that produces a lot of small homogeneous computational tasks that need to be consumed by a thread pool as rapidly as possible. For such a program (often) all that using multiple processes does is introduce extra overhead as well as extra complexity to the codebase with no real gain. It is questionable from a design perspective to introduce complexity that is not only not necessary but actually reduces performance in software that might be performance critical. When such a program works perfectly fine on multiple linux compilers and distributions, unix, macOS and could be made to work fine on MSVC on windows, it seems to me a very bad idea to introduce an architecture change that brings no benefits other than to work around what is essentially a massive compiler limitation in a single compiler. Doing this would amount in my opinion and I am sure the opinion of many others to being a hacky workaround. It is worth noting that there is a large amount of software in the world that is designed primarily for linux and that then gets ported to windows using mingw. Regardless of your personal opinion on whether lots of threads in a single process is "good design" or not, some of this software could benefit from a few lines of code change to be able to fully utilise more cores where appropriate. It is a lot more likely that the authors of such programs, who often only use linux and are maintaining the project in their spare time, are going to accept a several line patch to handle processor groups correctly and that is easily wrapped in conditionals, than that they are going to completely rearchitecture their software for a limitation in a different platform (windows). As multiple core machines become more and more widespread and as linux adoption continues to grow this is only going to become more of an issue over time and not less. So sure I could just 'hack' around this in my own program and move on - but it really seems to me that it would be better to tackle the compiler/toolchain (mingw-w64) limitation instead of handwaving the issue away and pretending it doesn't exist. Thanks, Malcolm MacLeod _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
