- Unglaublich, dass das funktioniert: - 1 Update
- Sieve of Erastosthenes optimized to the max - 11 Updates
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 31 02:26PM -0800 > cannot "potentially generate executable instructions". I would say > "there is no code to reach hence there is no switch-unreachable > warning". Some compilers complain. Other don't. I've seen the 'if(1)' version get a warning, and not get a warning with a different compiler. I've seen a 'for(;0;) case 1: ...' get a warning in some circumstances, and not in others. I tried some other variations, and got various results under different compilers. I'm reminded of Abraham Lincoln's review: "For people who like this sort of thing, this is the sort of thing that those people like." |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 31 06:51AM +0100 Am 30.12.2023 um 20:58 schrieb Chris M. Thomasson: > Huh? Wow, you really need to write Intel a letter about it wrt their > older hyperthreaded processors! ... The suggestion Intel made at this point is superfluous. > Intel's suggestions for how to mitigate the problem in their earlier > hyperhtreaded processors actually worked wrt improving performance. ... I'm pretty sure they never ran the numbers on that. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 31 06:54AM +0100 Am 30.12.2023 um 21:35 schrieb Kaz Kylheku: > My comment makes it clear that there are two thread stacks > vying for that cache line, plus a couple of other accesses > that are not thread stacks. With four way associativity that's rather unlikely to happen. |
Kaz Kylheku <433-929-6894@kylheku.com>: Dec 31 07:01AM >> vying for that cache line, plus a couple of other accesses >> that are not thread stacks. > With four way associativity that's rather unlikely to happen. What? The associativity of the cache is not the determiner of program behavior; if the program accesses five different areas whose addresses are the same modulo 65536 bytes, that happens whether there a direct mapped cache, fully associative cache or no cache at all, or ... -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 31 11:20AM +0100 Am 31.12.2023 um 08:01 schrieb Kaz Kylheku: > What? The associativity of the cache is not the determiner > of program behavior; if the program accesses five different > areas whose addresses are the same modulo 65536 bytes, ... The set size is smaller than 64kB an of course there can be aliasing but with four way associativity it's unlikely that there's a need to control aliasing. And if the set size would be 64kB aliasing would be even less likely through page colouring. |
Bonita Montero <Bonita.Montero@gmail.com>: Dec 31 11:22AM +0100 Am 30.12.2023 um 19:27 schrieb David Brown: > The idea is to have /different/ allocation sizes in different threads, > so that the different threads have their stacks at wildly different > address bits in their tags for the processor caches. There's not much need to do that with four-way associativity. > I can't tell you how helpful or not this may be in practice. ... Even Intel cant't do that. |
Kaz Kylheku <433-929-6894@kylheku.com>: Dec 31 05:30PM > but with four way associativity it's unlikely that there's a need to > control aliasing. And if the set size would be 64kB aliasing would be > even less likely through page colouring. When I describe a scenario in which five items are being frequently accessed and collide to the same cache line, which is associative with a set size of four, there is necessarily a conflict, because five is greater than four. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted. |
scott@slp53.sl.home (Scott Lurndal): Dec 31 06:44PM >> If it's four way associative, you star to have a performance problem as >> soon as five things collide on it. ... >With four-way associativity that's rather unlikely. Why? The set selection is based on specific bits in the address. As soon as a fifth address hits the set, you lose one of the existing lines. Given the aligned stacks in the specified processor, the next function called would _always_ overwrite the elements of the set(s) used by the calling function. |
scott@slp53.sl.home (Scott Lurndal): Dec 31 06:49PM >Citation? You are usually wrong in your claims, or at least mixed-up, >so I won't trust you without evidence. (That does not mean you are >wrong here - I don't know either way.) Kernel threads generally run with a small, fixed stack. Stack-based dynamic allocation is generally avoided. I don't know of any hard restrictions, but I suspect that Linus would look askance at it. >Of course, avoiding alloca() within the kernel is, again, utterly >irrelevant to the point under discussion. Very true |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 11:36AM -0800 On 12/30/2023 9:51 PM, Bonita Montero wrote: >> Intel's suggestions for how to mitigate the problem in their earlier >> hyperhtreaded processors actually worked wrt improving performance. ... > I'm pretty sure they never ran the numbers on that. I am pretty sure you are trolling, Bonita? |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 11:39AM -0800 On 12/30/2023 9:51 PM, Bonita Montero wrote: >> Intel's suggestions for how to mitigate the problem in their earlier >> hyperhtreaded processors actually worked wrt improving performance. ... > I'm pretty sure they never ran the numbers on that. I am pretty sure you never read that paper before, even now. |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 11:49AM -0800 On 12/30/2023 2:58 PM, red floyd wrote: >> way back machine has my older code. > Oh, come on, Chris. It's clear that Bonita knows more about what's > going on inside an Intel processor than Intel does. Sometimes, I hope it is trolling. Afaict, Bonita seems to be full of crap to a point where I actually feel sorry for the damn toilets it has to punish. |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |