By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), July 15, 2020 12:58 pm
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on July 15, 2020 11:05 am wrote:
>
> According to my understanding, it's not about Linux using either NFC or NFD.
Correct. Any normalization is fundamentally wrong in a filesystem.
The same way you don't want to change case, you really don't want to normalize. EVER.
It's really exactly the same issue.
Now, there are multiple reasons not to normalize, but the fundamental one is that you're losing information that can be relevant.
To pick one example: in Swedish, the letter 'ä' really is one letter, it has absolutely nothing to do with "a" combined with the diaeresis character. It's not an 'a' that is pronounced differently or has some other thing associated with it. It's literally its own character.
In contrast, in some other situations and other languages, the markings on top of characters (or bottom of) really are "modifiers" to the character, and people may intentionally use the decomposed form (although they rarely actually do, afaik).
So normalizing data that you don't understand how it is used (and by definition, an OS cannot know what the meaning of a filename is - that's a user choice), is truly and fundamentally broken.
And if some person tells you that they are the same, and by definition "canonically equivalent" and thus the differences don't matter, then that person doesn't understand Unicode. Being canonically equivalent does not mean that they are the same, and have to be treated the same. It means that they look the same when printed out. Nothing more, nothing less.
So canonical equivalence doesn't mean "equality", and it doesn't mean that normalizing doesn't matter. But some people get confused about it, because they think that "looks the same" means "is the same". Any technology person should know that isn't true. There are deep and fundamental differences, the same way ASCII 'A' looks and acts exactly like EBCDIC 'A', but has a fundamental encoding difference despite that.
You can't convert text from ASCII to EBCDIC and say that the end result is the same. It's not. They simple are not the same - not even if they are 100% equivalent, just different encodings of the exact same text, and should be printed out exactly the same.
And exactly as with ASCII and EBCDIC, the Unicode normal form conversions aren't reversible.
Is normalizing always wrong? No. There are places and times when you want to do it, but they are very very very rare. And you have to truly and fundamentally understand the context to do it.
So most commonly, you do normalization inside things that do comparisons between two strings, and the comparison is defined to be a normalizing one (even unicode comparisons do not have to be for equivalence! Doing "strcmp()" on UTF-8 isn't wrong). Or you may want to normalize to a combined character as part of picking the actual glyph: when you do ligatures between the letters 'f' and 'i', you should not be doing it as part of the context if the next character is a diearesis that combines with the 'i'.
(Ok, I'm not sure the latter case really counts as a normalization: it may actually be done that way, but I suspect in the big picture that's just all about the font layout rather than normalization per se).
But doing normalization at an interface where you do not understand the context is absolutely always wrong.
(Note that this is different from "malformed UTF-8", which you should also never normalize, you should either just reject that outright, or not consider to be Unicode at all. The most common reason for "malformed UTF-8" is that it simply isn't UTF-8 at all, and you have content that is some other format entirely, and you need to do a locale-aware conversion to Unicode, and turn it into UTF-8 that way).
Anyway, in almost all situations, the thing people want is NFC ("composed", "compact" or "cotrrect" - you choose the meaning of the "C"). It's the most common one, and it's the one you should use if you don't know what you're doing, and have no particular preferences, and just want to say "my data is in this form".
There are people out there (I think they are all Apple apologists) that claim that NFD is preferred because it's "faster". That's complete and utter BS. If you hear that claim, you can dismiss that person as not knowing what he's doing. That person probably had one particular problem where the decomposed form was simpler, and then decided NFD is the way to go.
But if NFD is the better one for your particular case, and you understand the conctext, by all means use NFD. NFD isn't wrong per se. It's only wrong when used blindly and when you then expose others to it. The most common reason for NFD may be to internally use it when you compare two strings, and you know that equivalence is what you want to use as the comparison criteria.
But even when you use NFD, and even when you know that your comparison criteria is "Unicode equivalence" (probably combined with case insensitivity), you don't change your source data that somebody else is using to do that! You just use it inside your own particular case where it made sense.
In a filesystem, NFD most certainly is not the way to go, for several reasons:
- don't normalize. Christ, people!
- it's less compact
- of the two main normalization choices, it's simply the wrong one
- you don't generally have to normalize even for case-insensitive comparisons
In particular, I think that what OS X (probably) does in its file handling code is to normalize the input to NFD at entry, because that way you normalize once and are done. It's slightly easier, but it means you do extra allocations and copies, and it's stupid and wrong.
And once you've done that stupid and wrong normalization, now you don't even have the original filename any more, so you save that wrong and normalized copy on disk.
Stupid.
Ignorant.
Wrong.
The smart thing to do is to avoid normalizing as long as possible, because even when you do file lookups, you can do the exact (non-normalized) match first, and that will wotk 99% of the time. And you did no extra work, so your 99% is faster.
When people have a file called "Banana" on OS X, it's true that they can look it up using the name "bAnAnA" too. But let's be honest: they don't. They open the file "Banana".
And then, because you have to get the "bAnAnA" case right too for the insane user, if you didn't have an exact match, you now go to the "slow compare" thing, and that one is likely better also done without ever normalizing either of the strings, but instead doing the comparison one normalized character at a time. Again, it's actually generally faster and cheaper to do it that way, partly because most of the time, the normalization is really simple (ie a lot of filenames are in fact plain ASCII, even in non-ASCII places - think all the system directories etc).
To get us back to vectorization, it's actually trivially doable to do all the normal US ASCII cases with a vectorized one (turning all ASCII letters from lower case to upper case is not hard, neither is it hard to test "are all these bytes US ASCII"). So the "handle all the really cheap and common cases without ever normalizing anything at all" is literally the fastest thing you can do in almost all cases, and it's often the simplest thing too, because all your fast-paths never need to care or know, or worry about extra allocations because the strings change length.
Btw, Linux doesn't normalize, and Linux filesystem accesses are generally much faster than OS X. And simpler to work with.
And look - Linux didn't corrupt any user data in the process!
Normalizing at a filesystem level really is wrong. Quod erat demonstrandum.
Linus
>
> According to my understanding, it's not about Linux using either NFC or NFD.
Correct. Any normalization is fundamentally wrong in a filesystem.
The same way you don't want to change case, you really don't want to normalize. EVER.
It's really exactly the same issue.
Now, there are multiple reasons not to normalize, but the fundamental one is that you're losing information that can be relevant.
To pick one example: in Swedish, the letter 'ä' really is one letter, it has absolutely nothing to do with "a" combined with the diaeresis character. It's not an 'a' that is pronounced differently or has some other thing associated with it. It's literally its own character.
In contrast, in some other situations and other languages, the markings on top of characters (or bottom of) really are "modifiers" to the character, and people may intentionally use the decomposed form (although they rarely actually do, afaik).
So normalizing data that you don't understand how it is used (and by definition, an OS cannot know what the meaning of a filename is - that's a user choice), is truly and fundamentally broken.
And if some person tells you that they are the same, and by definition "canonically equivalent" and thus the differences don't matter, then that person doesn't understand Unicode. Being canonically equivalent does not mean that they are the same, and have to be treated the same. It means that they look the same when printed out. Nothing more, nothing less.
So canonical equivalence doesn't mean "equality", and it doesn't mean that normalizing doesn't matter. But some people get confused about it, because they think that "looks the same" means "is the same". Any technology person should know that isn't true. There are deep and fundamental differences, the same way ASCII 'A' looks and acts exactly like EBCDIC 'A', but has a fundamental encoding difference despite that.
You can't convert text from ASCII to EBCDIC and say that the end result is the same. It's not. They simple are not the same - not even if they are 100% equivalent, just different encodings of the exact same text, and should be printed out exactly the same.
And exactly as with ASCII and EBCDIC, the Unicode normal form conversions aren't reversible.
Is normalizing always wrong? No. There are places and times when you want to do it, but they are very very very rare. And you have to truly and fundamentally understand the context to do it.
So most commonly, you do normalization inside things that do comparisons between two strings, and the comparison is defined to be a normalizing one (even unicode comparisons do not have to be for equivalence! Doing "strcmp()" on UTF-8 isn't wrong). Or you may want to normalize to a combined character as part of picking the actual glyph: when you do ligatures between the letters 'f' and 'i', you should not be doing it as part of the context if the next character is a diearesis that combines with the 'i'.
(Ok, I'm not sure the latter case really counts as a normalization: it may actually be done that way, but I suspect in the big picture that's just all about the font layout rather than normalization per se).
But doing normalization at an interface where you do not understand the context is absolutely always wrong.
(Note that this is different from "malformed UTF-8", which you should also never normalize, you should either just reject that outright, or not consider to be Unicode at all. The most common reason for "malformed UTF-8" is that it simply isn't UTF-8 at all, and you have content that is some other format entirely, and you need to do a locale-aware conversion to Unicode, and turn it into UTF-8 that way).
Anyway, in almost all situations, the thing people want is NFC ("composed", "compact" or "cotrrect" - you choose the meaning of the "C"). It's the most common one, and it's the one you should use if you don't know what you're doing, and have no particular preferences, and just want to say "my data is in this form".
There are people out there (I think they are all Apple apologists) that claim that NFD is preferred because it's "faster". That's complete and utter BS. If you hear that claim, you can dismiss that person as not knowing what he's doing. That person probably had one particular problem where the decomposed form was simpler, and then decided NFD is the way to go.
But if NFD is the better one for your particular case, and you understand the conctext, by all means use NFD. NFD isn't wrong per se. It's only wrong when used blindly and when you then expose others to it. The most common reason for NFD may be to internally use it when you compare two strings, and you know that equivalence is what you want to use as the comparison criteria.
But even when you use NFD, and even when you know that your comparison criteria is "Unicode equivalence" (probably combined with case insensitivity), you don't change your source data that somebody else is using to do that! You just use it inside your own particular case where it made sense.
In a filesystem, NFD most certainly is not the way to go, for several reasons:
- don't normalize. Christ, people!
- it's less compact
- of the two main normalization choices, it's simply the wrong one
- you don't generally have to normalize even for case-insensitive comparisons
In particular, I think that what OS X (probably) does in its file handling code is to normalize the input to NFD at entry, because that way you normalize once and are done. It's slightly easier, but it means you do extra allocations and copies, and it's stupid and wrong.
And once you've done that stupid and wrong normalization, now you don't even have the original filename any more, so you save that wrong and normalized copy on disk.
Stupid.
Ignorant.
Wrong.
The smart thing to do is to avoid normalizing as long as possible, because even when you do file lookups, you can do the exact (non-normalized) match first, and that will wotk 99% of the time. And you did no extra work, so your 99% is faster.
When people have a file called "Banana" on OS X, it's true that they can look it up using the name "bAnAnA" too. But let's be honest: they don't. They open the file "Banana".
And then, because you have to get the "bAnAnA" case right too for the insane user, if you didn't have an exact match, you now go to the "slow compare" thing, and that one is likely better also done without ever normalizing either of the strings, but instead doing the comparison one normalized character at a time. Again, it's actually generally faster and cheaper to do it that way, partly because most of the time, the normalization is really simple (ie a lot of filenames are in fact plain ASCII, even in non-ASCII places - think all the system directories etc).
To get us back to vectorization, it's actually trivially doable to do all the normal US ASCII cases with a vectorized one (turning all ASCII letters from lower case to upper case is not hard, neither is it hard to test "are all these bytes US ASCII"). So the "handle all the really cheap and common cases without ever normalizing anything at all" is literally the fastest thing you can do in almost all cases, and it's often the simplest thing too, because all your fast-paths never need to care or know, or worry about extra allocations because the strings change length.
Btw, Linux doesn't normalize, and Linux filesystem accesses are generally much faster than OS X. And simpler to work with.
And look - Linux didn't corrupt any user data in the process!
Normalizing at a filesystem level really is wrong. Quod erat demonstrandum.
Linus
Topic | Posted By | Date |
---|---|---|
Alder Lake and AVX-512 | me | 2020/07/11 07:02 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 11:41 AM |
informative (NT) | blue | 2020/07/11 12:40 PM |
grumpy | Michael S | 2020/07/11 12:51 PM |
grumpy | me | 2020/07/11 01:27 PM |
area and power cost of AVX-512 | Michael S | 2020/07/11 12:58 PM |
area and power cost of AVX-512 | Anon | 2020/07/11 04:35 PM |
area and power cost of AVX-512 | Michael S | 2020/07/12 04:16 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/12 09:13 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/11 07:19 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 02:02 PM |
Alder Lake and AVX-512 | Ungo | 2020/07/11 05:28 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 10:16 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:51 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 01:48 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:07 PM |
HDR | Anon3 | 2020/07/12 03:42 PM |
HDR10 in Kaby Lake? | David Kanter | 2020/07/12 05:09 PM |
HDR10 in Kaby Lake? | Maynard Handley | 2020/07/12 06:13 PM |
Thanks for the link (NT) | David Kanter | 2020/07/12 06:43 PM |
HDR10 in Kaby Lake? | Anon3 | 2020/07/13 01:36 AM |
Alder Lake and AVX-512 | Dummond D. Slow | 2020/07/12 03:00 PM |
AVX-512 with narrow ex units? | m | 2020/07/23 12:10 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 12:53 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 06:50 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 07:45 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 08:15 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/24 04:44 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/24 02:56 PM |
AVX-512 with narrow ex units? | Jouni Osmala | 2020/07/24 09:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/25 01:32 AM |
AVX-512 with narrow ex units? | Eugene Nalimov | 2020/07/25 05:56 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/26 01:28 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/26 02:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/27 07:00 AM |
AVX-512 with narrow ex units? | -.- | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Travis Downs | 2020/07/24 05:01 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 04:45 PM |
Alder Lake and AVX-512 | Chester | 2020/07/11 05:26 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 06:22 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:02 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:54 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:01 PM |
Alder Lake and AVX-512 | N Owen | 2020/07/12 12:37 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:48 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 07:13 PM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:09 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:42 PM |
Alder Lake and AVX-512 | Doug S | 2020/07/11 11:49 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:53 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 07:03 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/11 07:43 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:31 AM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:01 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 03:26 PM |
Alder Lake and AVX-512 | Anon3 | 2020/07/12 04:07 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:39 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:21 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:33 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 05:54 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 06:20 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/12 07:32 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 08:41 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/13 04:02 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/13 07:25 PM |
PentiumMMX vs Transmeta's VLIW in hindsight | ⚛ | 2020/07/19 06:16 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | Maynard Handley | 2020/07/19 10:47 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | anon2 | 2020/07/19 03:24 PM |
VLIW, OOO, Pairing, and Fusion | Chester | 2020/07/19 10:16 PM |
Poulson was in-order (NT) | anon2 | 2020/07/20 12:20 AM |
VLIW, OOO, Pairing, and Fusion | Michael S | 2020/07/20 12:48 AM |
Itanium is NOT VLIW | Heikki Kultala | 2020/07/20 02:27 PM |
Itanium is NOT VLIW | Adrian | 2020/07/20 11:03 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Heikki Kultala | 2020/07/21 03:38 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | anon2 | 2020/07/21 05:03 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | dmcq | 2020/07/21 03:27 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | j | 2020/07/21 08:54 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Tim McCaffrey | 2020/07/21 10:30 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Linus Torvalds | 2020/07/21 09:13 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 12:31 PM |
Turn that on its head? | Ray | 2020/07/22 12:49 PM |
Turn that on its head? | Anon | 2020/07/22 01:53 PM |
Turn that on its head? | Maynard Handley | 2020/07/22 02:37 PM |
Turn that on its head? | anon2 | 2020/07/22 03:32 PM |
Turn that on its head? | anon3 | 2020/07/22 04:45 PM |
Turn that on its head? | Heikki Kultala | 2020/07/23 02:53 AM |
Turn that on its head? | Anon | 2020/07/23 10:20 AM |
Turn that on its head? | Heikki Kultala | 2020/07/23 11:21 AM |
Turn that on its head? | Brett | 2020/07/23 03:26 PM |
Turn that on its head? | Brett | 2020/07/24 04:22 AM |
Bundling OOO entries does this implicitly | David Kanter | 2020/07/23 10:56 AM |
Turn that on its head? | anon | 2020/07/23 11:49 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Maynard Handley | 2020/07/22 02:29 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/22 03:16 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Doug S | 2020/07/22 10:37 PM |
what Intel would have done | Michael S | 2020/07/23 12:46 AM |
what Intel would have done | Doug S | 2020/07/23 09:52 AM |
what Intel would have done | Anon | 2020/07/23 10:25 AM |
what Intel would have done | Michael S | 2020/07/23 11:23 AM |
what Intel would have done | Montaray Jack | 2020/07/23 06:08 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 11:47 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/23 01:46 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Michael S | 2020/07/23 12:56 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/23 02:44 AM |
thanks | Chester | 2020/07/24 03:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 07:46 PM |
Alder Lake and AVX-512 | never_released | 2020/07/11 08:54 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:25 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:36 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 12:01 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:41 AM |
Alder Lake and AVX-512 | rwessel | 2020/07/12 10:17 AM |
Alder Lake and AVX-512 | -.- | 2020/08/18 03:24 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/08/18 11:04 PM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 07:49 PM |
Alder Lake and AVX-512 | anon | 2020/07/11 08:12 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:00 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/12 08:51 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 10:30 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 07:43 AM |
Alder Lake and AVX-512 | Montaray Jack | 2020/07/23 07:20 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/24 04:57 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 11:35 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:15 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 01:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:31 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 03:09 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 04:25 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 08:34 PM |
Alder Lake and AVX-512 | Jose | 2020/07/13 01:35 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:11 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:01 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:06 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/13 12:11 PM |
Alder Lake and AVX-512 | Brett | 2020/07/14 02:34 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/14 09:02 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 12:40 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:48 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/15 01:37 AM |
OS X file names normalization | Michael S | 2020/07/15 02:26 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 04:16 AM |
OS X file names normalization | Michael S | 2020/07/15 10:51 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 12:27 PM |
OS X file names normalization | Doug S | 2020/07/15 10:46 AM |
OS X file names normalization | Michael S | 2020/07/15 11:05 AM |
OS X file names normalization | Linus Torvalds | 2020/07/15 12:58 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 02:21 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:57 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:44 PM |
OS X file names normalization | Rob Thorpe | 2020/07/15 11:23 AM |
OS X file names normalization | Doug S | 2020/07/15 01:32 PM |
OS X file names normalization | Maynard Handley | 2020/07/15 05:20 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 08:37 PM |
OS X file names normalization | Anon3 | 2020/07/16 01:43 PM |
OS X file names normalization | Doug S | 2020/07/16 03:38 PM |
OS X file names normalization | Linus Torvalds | 2020/07/17 12:21 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:15 AM |
OS X file names normalization | Jukka Larja | 2020/07/17 06:40 AM |
OS X file names normalization | gallier2 | 2020/07/17 03:19 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 09:41 AM |
OS X file names normalization | Dummond D. Slow | 2020/07/17 09:54 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 10:16 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/18 06:12 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:04 AM |
OS X file names normalization | Doug S | 2020/07/17 10:15 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/15 10:32 AM |
File Systems and VC Problems | Rob Thorpe | 2020/07/15 07:24 AM |
vectorization of utf8 | Robert David Graham | 2020/07/13 02:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 05:07 PM |
vectorization of utf8 | Robert David Graham | 2020/07/13 08:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 11:23 PM |
vectorization of utf8 | Maynard Handley | 2020/07/13 10:46 PM |
vectorization of utf8 | Gabriele Svelto | 2020/07/15 03:27 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/14 01:13 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 01:29 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:08 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 06:26 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 07:11 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 07:43 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 08:38 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 10:10 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 11:02 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:22 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 12:10 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 04:03 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/14 06:53 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 08:34 PM |
Alder Lake and AVX-512 | Brett | 2020/07/11 09:02 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/13 12:36 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/13 01:01 PM |
Alder Lake and AVX-512 | Brett | 2020/07/13 04:19 PM |
Alder Lake and AVX-512 | Geert | 2020/07/11 09:36 PM |
AMD's FPU | Chester | 2020/07/12 02:28 AM |
Is 3|5 lower than 4? | Michael S | 2020/07/12 03:59 AM |
Is 3|5 lower than 4? | Chester | 2020/07/12 05:54 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 11:45 PM |
Alder Lake and AVX-512 | me | 2020/07/12 03:44 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:09 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:35 AM |
~80% of details are wrong. So what one can expect from conclusions? :( (NT) | Michael S | 2020/07/12 11:57 AM |
~80% of details are wrong. So what one can expect from conclusions? :( | anonymous2 | 2020/07/12 12:50 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:25 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:37 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:43 PM |
Alder Lake and AVX-512 | me | 2020/07/12 01:32 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 08:51 PM |
Alder Lake and AVX-512 | UnmaskedUnderflow | 2020/07/12 12:33 PM |
AVX-512 vs SVE2 | -.- | 2020/07/12 06:22 PM |
AVX-512 vs SVE2 | noko | 2020/07/13 12:12 AM |
AVX-512 vs SVE2 | -.- | 2020/07/13 04:00 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/12 08:18 PM |
Could you please stop top-posting (NT) | Jukka Larja | 2020/07/13 08:45 AM |
Alder Lake and AVX-512 | Romain Dolbeau | 2020/07/15 01:00 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:59 AM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/13 09:12 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:21 PM |
Alder Lake and AVX-512 | Jouni Osmala | 2020/07/14 02:55 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:11 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:13 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:10 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 10:09 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 10:53 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:27 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Maynard Handley | 2020/07/14 12:52 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Doug S | 2020/07/14 01:43 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 03:01 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Linus Torvalds | 2020/07/14 12:00 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:42 PM |
Configurable cache line size? | Doug S | 2020/07/15 10:56 AM |
Configurable cache line size? | dmcq | 2020/07/15 03:43 PM |
Configurable cache line size? | Romain Dolbeau | 2020/07/15 11:37 PM |
Configurable cache line size? | NoSpammer | 2020/07/16 01:27 AM |
Configurable cache line size? | Pixie | 2020/07/16 10:55 AM |
Configurable cache line size? | Etienne | 2020/07/17 01:03 AM |
Configurable cache line size? | Hugo Décharnes | 2020/07/18 02:11 AM |
Cache line size | Mark Roulo | 2020/07/15 06:10 PM |
Cache line size | anon | 2020/07/15 06:46 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Gabriele Svelto | 2020/07/17 02:30 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | dmcq | 2020/07/17 03:34 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | zArchJon | 2020/07/17 01:16 PM |
Macro-instructions to the rescue | ⚛ | 2020/07/24 12:56 PM |
Some fundamentals haven't changed | Chester | 2020/07/24 03:59 PM |
Some fundamentals haven't changed | ⚛ | 2020/07/24 04:24 PM |
Some fundamentals haven't changed | dmcq | 2020/07/25 07:58 AM |
Some fundamentals haven't changed | ⚛ | 2020/07/25 11:05 AM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:16 PM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:27 PM |
What belt is. | Heikki Kultala | 2020/07/26 07:49 AM |
What belt is. | Michael S | 2020/07/26 10:00 AM |
What belt is. | Brett | 2020/07/26 11:46 PM |
What belt is. | Michael S | 2020/07/27 12:52 AM |
What belt is. | Brett | 2020/07/27 07:25 AM |
What belt is. | Doug S | 2020/07/27 01:31 PM |
What belt is. | Andrew Clough | 2020/07/28 06:11 AM |
What belt is. | dmcq | 2020/07/28 08:17 AM |
Mill Compiler still MIA? | Geoff Langdale | 2020/07/28 05:04 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust (NT) | Anon | 2020/07/28 05:20 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust | Anon | 2020/07/28 05:20 PM |
Apparently they're busy writing a kernel... | Anon | 2020/07/29 03:03 AM |
Apparently they're busy writing a kernel... | dmcq | 2020/07/29 03:39 AM |
What belt is. | ⚛ | 2020/07/26 11:44 AM |
What belt is. | anonymous2 | 2020/07/26 12:02 PM |
What belt is. | Doug S | 2020/07/26 03:26 PM |
What belt is. | ⚛ | 2020/07/26 04:02 PM |
good | useruser | 2020/07/12 10:06 AM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:03 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:07 PM |
Alder Lake and AVX-512 | j | 2020/07/13 12:29 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 01:12 AM |
Alder Lake and AVX-512 | j | 2020/07/13 02:58 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/13 04:53 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:57 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 10:26 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 12:33 PM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 03:43 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 12:55 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:19 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 02:34 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:03 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 09:43 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 09:54 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 11:35 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:18 PM |
GV100 + POWER9 | Michael S | 2020/07/16 01:17 AM |
GV100 + POWER9 | dmcq | 2020/07/16 08:58 AM |
GV100 + POWER9 | dmcq | 2020/07/16 09:10 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:48 AM |
Alder Lake and AVX-512 | o | 2020/07/12 03:08 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:07 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:32 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:39 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 12:47 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:18 PM |
x87 crap | Heikki Kultala | 2020/07/12 01:30 PM |
x87 crap | Michael S | 2020/07/12 01:37 PM |
x87 crap | Heikki kultala | 2020/07/12 02:11 PM |
x87 crap | Michael S | 2020/07/12 02:50 PM |
Sparc and PA-RISC vs pentium FP performance | Heikki Kultala | 2020/07/13 01:14 AM |
Sparc and PA-RISC vs pentium FP performance | anonymous2 | 2020/07/13 10:48 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 03:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:10 PM |
Alder Lake and AVX-512 | David Kanter | 2020/07/12 05:01 PM |
Alder Lake and AVX-512 | anon | 2020/07/12 05:40 PM |
~0% of users do much FP outside of GPUs for games (NT) | anonymous2 | 2020/07/12 05:47 PM |
~0% of users do much FP outside of GPUs for games | Maynard Handley | 2020/07/13 12:26 AM |
not true | Chester | 2020/07/13 12:37 AM |
not true | Michael S | 2020/07/13 01:29 AM |
not true | Chester | 2020/07/13 01:59 AM |
not true | anonymous2 | 2020/07/13 10:32 AM |
not true | Maynard Handley | 2020/07/13 02:30 PM |
not true | Chester | 2020/07/14 05:47 AM |
not true | Doug S | 2020/07/13 12:30 PM |
not true | Anon | 2020/07/13 01:16 PM |
not true | Maynard Handley | 2020/07/13 02:39 PM |
not true | Maynard Handley | 2020/07/13 02:38 PM |
not true | Linus Torvalds | 2020/07/13 11:27 AM |
not true | Dummond D. Slow | 2020/07/13 02:10 PM |
not true | Maynard Handley | 2020/07/13 02:49 PM |
not true | Dummond D. Slow | 2020/07/13 03:38 PM |
not true (about FP, not avx-512) | Chester | 2020/07/17 10:37 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 06:45 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 06:57 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 04:26 PM |