Jump to content

Talk:Intel 5-level paging

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

"Replace autogenerated reference names with more-meaningful names"

[edit]

Thank you. I detest auto-generated ref names. In a short article like this there's really no advantage to naming them anyway, unless they're used more than once. Jeh (talk) 02:11, 1 May 2018 (UTC)[reply]

Yeah - if you're editing something, you have no clue what <ref name=":17"/> is referring to, but you might at least have a clue what <ref name="AMD64-manual"/> is. Guy Harris (talk) 02:15, 1 May 2018 (UTC)[reply]

Suggestions for improvement

[edit]

This is not part of the DYK process, that's why I post it here:

  • In the Intel white paper (reference 1) I cannot allocate a page where it says that the highest bits must be sign extended. This is probably a result of good rewording, can the page number be added?
  • In the IA-32 Architectures manual, I seem to be too stupid to reach the indicated pages---I guess it is in one of the documents linked on that page. If that's the case, could the second url please be added to the reference (i.e, using |chapter= and |chapter_url=)?
  • I was under the impression that memory capacity has binary quantifiers. Should it then not be Gibibytes instead of gigabytes, etc.? The Intel manual consistently uses "KBytes", "MBytes", and so on. If I'm not mistaken, those are Kibi, Mebi, and so on.

As mentioned, those are suggestions, not DYK-hurdles to jump over. Cheers, Pgallert (talk) 09:43, 1 May 2018 (UTC)[reply]

@Pgallert: I think I've done all the above. The quote from the white paper is "an address is 57-bit canonical if bits 63:56 of the address are identical". My main concern with the direct link to the manual is that they do regularly update it, but at the same time, the edition is referenced, so that shouldn't be a problem. Finally, I do like the precision of the new terms, it's just that I'm used to referring to the binary ones as decimal names... the shame. Bellezzasolo Discuss 12:09, 1 May 2018 (UTC)[reply]
The term "sign extension" is imprecise because these aren't signed numbers and the highest bit implemented (bit 56 in the example given above) is not a sign bit. The term "in a manner similar to sign extension" is sometimes used to describe the formation of canonical addresses. btw not everything has to be found in the white paper; it may be in the SDM or in many other Intel docs - do not assume that "because I can't find it in the white paper" it's an invalid claim.
Re mebi, GiB, etc. - Although I personally like the IEC binary prefixes and support their use, WP:MOS does not. Those changes should be reverted. Really wish whoever did that had done that in an edit by itself so the change could be easily reverted. Jeh (talk) 14:09, 1 May 2018 (UTC)[reply]
Reverted and made other changes. I'm still not happy with the comparison with PAE as it is misleading. Although the changes from non-PAE to PAE appear superficially analagous to the changes from 4- to 5-level paging, PAE was about widening the PTE format to support more bits of physical address (while keeping the virtual address width the same), while 5-level paging increases the implemented number of bits in virtual addresses and does not change the available number of bits of physical address. I'll be thinking about the best way to draw this comparison, or maybe delete it completely. Jeh (talk) 14:44, 1 May 2018 (UTC)[reply]
@Jeh: I think there is a misunderstanding on the quantifiers here. Giga is not bad style for memory, giga is wrong. WP:COMPUNITS prescribes GB or GBytes instead of Gibi, that's all. MOS also recommends using the {{BDprefix}} template, as in this example:[1] Not going into an edit war here, but can the memory sizes be corrected again?
With "because I can't find it in the white paper" I meant that the claim was referenced to that white paper (I was adding page numbers at the time) but I couldn't make the connection which clause supported it. --Pgallert (talk) 18:53, 1 May 2018 (UTC)[reply]
WP:COMPUNITS prescribes that:
The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except:[a]
  • when the majority of cited sources on the article topic use IEC prefixes;
  • in a direct quote using the IEC prefixes;
  • when explicitly discussing the IEC prefixes; or
  • in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.
so, unless one of the four bulleted cases apply, the MoS appears to be saying you shouldn't say "tebibytes" or "pebibytes", even if "terabytes" and "petabytes" are technically incorrect due to being powers of 10.
Presumably correcting the memory sizes and, simultaneously, following WP:COMPUNITS would presumably mean 1) saying neither "tera" and "peta" nor "tebi" and "pebi", but saying "T" and "P" and 2) using {{BDprefix}}. Guy Harris (talk) 19:37, 1 May 2018 (UTC)[reply]
This has been the subject of much debate in the past, a lot of it quite heated. As I said, I personally support the IEC prefixes; I have argued for their routine use on Wikipedia in the past; I use them in my work; I agree that to say e.g. "megabyte" when you mean 220 bytes is wrong - per the standards for IEC binary prefixes. But not according to JEDEC's standards, nor according to the references used for this very article, nor according to our house style.
The last time this was discussed at any length, the arguments that a) the vast majority of our readers are not familiar with the IEC prefixes, and that b) we should follow our sources and the vast majority of our sources don't use them, held sway. We're an encyclopedia, we're supposed to follow our sources. Accordingly, a great many articles here on computer main memory and OS memory management use "megabyte" to mean 220 bytes, etc.; and so should this one, even though it is technically wrong per the IEC and related standards. If you want to argue for changing COMPUNITS you'll need to do it at TALK:MOS, not here. Jeh (talk) 20:02, 1 May 2018 (UTC)[reply]
No, arguing against COMPUNITS is not necessary at all. If this guideline forced me to make a wrong statement, that would be a classic WP:IAR case. But that's not even necessary: Nowhere at COMPUNITS does it say 'change tebi to tera'. All it says is 'change tebi to T, and provide a footnote'.
To the question whether the sources of this article use JEDEC or IEC standards: They use IEC. That's because they use TBytes and PBytes, when neither the T not the P has any meaning in JEDEC's standard. --Pgallert (talk) 09:11, 2 May 2018 (UTC)[reply]
Oh, please. COMPUNITS does not say "change tebi to tera" because it is not necessary, because it says that "tebi" and the other IEC binary prefixes are not to be used in the first place. And if the sources of this article used IEC they would be using e.g. TiB, not TB. But they use TB, and they are clearly using it to mean a power of 1024. They are using SI prefixes in a binary sense. I repeat: I agree with you that that is wrong. But per MOS:COMPUNITS that's what we're supposed to do here. I see other no way to interpret "the IEC binary prefixes are generally not to be used". Jeh (talk) 09:22, 2 May 2018 (UTC)[reply]
Then what are we arguing about? All I wanted is that the "tera" be changed to T with a footnote that the T has binary meaning. T is not an IEC prefix. So fully MOS-compliant, and not wrong anymore. --Pgallert (talk) 14:51, 2 May 2018 (UTC)[reply]
Huh. I thought that when you wrote "Should it then not be Gibibytes instead of gigabytes, etc.?" you were arguing for the use of e.g. "gibibytes" and "GiB" in the article (as Bellezzasolo did). You appear to have softened your position.
However I see no point in your new statement, "All I wanted is that "tera" be changed to T". (Per your statement re gibibytes/gigabytes as quoted above that is clearly not all you wanted, but never mind that.) I cannot see how you regard changing "Tera" to "T" as any sort of semantic change. One is simply an abbreviation, or a "symbol" in SI parlance, for the other. The use of "T" to mean 10244 is no more correct (per IEC and SI) than the use of "tera". But since you are no longer arguing for "tebi", etc., fine. The disambiguation footnote is also fine. Jeh (talk) 18:26, 2 May 2018 (UTC)[reply]
Good. Yes, I have softened my position, as I didn't know about that particular MOS part, and as I really have no desire to initiate a Wiki-wide change. As soon as I finish this review I'll go back write articles. You're around here longer than I am and have probably learned about the prospect of changing old habits of fellow editors. That's for someone else to take up, not me. Cheers, Pgallert (talk) 19:03, 2 May 2018 (UTC)[reply]
And then you go and change "terabyte" to "Tbyte", claiming "consensus"! That seems very WP:POINTy, not to mention disingenuous - you don't claim consensus for changing "tera" to "T" when nobody expressed any agreement that that would be ok. More generally, please note that you don't mix prefix symbols with full unit names, or vice versa, not in formal writing. Which this is supposed to be. And I don't think a DYK reviewer should be so insistent on changing an article to their preference. Jeh (talk) 20:45, 2 May 2018 (UTC)[reply]
From Unit prefix: "The prefixes of the metric system precede a basic unit of measure to indicate a decadic multiple and fraction of a unit. Each prefix has a unique symbol that is prepended to the unit symbol." Do you see? A prefix such as "mega" precedes a unit such as "byte". A prefix's symbol such as "M" precedes a unit symbol such as "B". Jeh (talk) 21:11, 2 May 2018 (UTC)[reply]

And, no, by "saying neither "tera" and "peta" nor "tebi" and "pebi", but saying "T" and "P"" I didn't mean "change terabyte to Tbyte and change pebibyte to Pbyte"; I guess I didn't make it clear enough that I meant using "TB" and "PB". So, no, I am not part of any consensus that "Tbyte" and "Pbyte" are the right answer. Guy Harris (talk) 21:55, 2 May 2018 (UTC)[reply]

Very well, now we're back to the clearly wrong gigabyte and petabyte. I give up. --Pgallert (talk) 10:57, 3 May 2018 (UTC)[reply]
@Pgallert: No, we're not. We can use "KB", "MB", "GB", "TB", "PB", etc., along with {{BDprefix}}. "Kbyte", "Mbyte", etc. are an awkward mix of prefix abbreviations and words. Guy Harris (talk) 16:18, 3 May 2018 (UTC)[reply]
"KB", "MB", etc., are just as "clearly wrong" as are kilobyte, megabyte, etc. The former are precisely symbols for the latter. Jeh (talk) 19:59, 3 May 2018 (UTC)[reply]

References

  1. ^ Transistorized memory, such as RAM, ROM, flash and cache sizes as well as file sizes are specified using binary meanings for K (10241), M (10242), G (10243), etc.

Notes

  1. ^ Wikipedia follows common practice regarding bytes and other data traditionally quantified using binary prefixes (e.g. mega- and kilo-, meaning 220 and 210 respectively) and their unit symbols (e.g. MB and KB) for RAM and decimal prefixes for most other uses. Despite the IEC's 1998 international standard creating several new binary prefixes (e.g. mebi-, kibi-, etc.) to distinguish the meaning of the decimal SI prefixes (e.g. mega- and kilo-, meaning 106 and 103 respectively) from the binary ones, and the subsequent incorporation of these IEC prefixes into the ISO/IEC 80000, consensus on Wikipedia in computing-related contexts favours the retention of the more familiar but ambiguous units KB, MB, GB, TB, PB, EB, etc. over use of unambiguous IEC binary prefixes. For detailed discussion, see WT:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008).

The MICRO-50 reference should be made more specific

[edit]

Which particular paper in the MICRO-50 proceedings is being treated as a reference for the "Adding another level of indirection makes page table "walks" longer." claim? Guy Harris (talk) 20:12, 11 January 2020 (UTC)[reply]