Jump to content

Talk:Memory hierarchy

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

Article purpose

[edit]

topic in memory hierarchy and details on it.

I added a sentence and a half in the lead paragraph. The topic, being a general category of memory design, is more abstract than the practical orientation of the article.
It fills an important subject. If the article needed much more detail to be encyclopedic, it could be classified as a stub, but it hasn't been. It may not need more details. It may just need study, and while doing so, some careful magnification and tighter linking of the details it has.CpiralCpiral 00:18, 14 September 2009 (UTC)[reply]

www?

[edit]

Shouldn't lans and wans be added to the memory hierarchy? --128.243.21.225 13:06, 16 October 2006 (UTC)[reply]

No. Networks are means of communication, not storage. Adrianwn (talk) 09:28, 27 July 2008 (UTC)[reply]
No, Network Area Storage (NAS) devices optimize their own memory hierarchy (to optimize their physical design).
"On-line" (secondary storage) here refers to the "network" from the CPU's point of view, which is "on" the computer "line"—the hard drive.
"Off-line" (tertiary storage) here refers to "infinite" latency (waiting for manual intervention). It is the boundary of the realm of the 'memory hierarchy'.
Remember it is CPU-centric latency (delay)—the primary criterion for designing a placement in storage in a memory hierarchy—that fits the storage device into the design considerations concerning the operators of the computer. The term memory hierarchy is used only incidentally in operations, artifactually. It's primary use is in design, you know, abstract machines, thought experiments...
Network architect's use the term latency directly instead of memory hiererchy because they might never know what is on-line.
Wikipedia will now put this answer in (permanent!) storage. I don't care how or why, but rats will hide and birds will fly.
CpiralCpiral 18:21, 29 September 2009 (UTC)[reply]

Lead section cleanup

[edit]

There is now a "context" template, a cleanup banner in the lead section:

The editing comment said it was absurd to have a "main" template under the title of the article.

I agree. Now, what to do? How about this replacement of the "main" template:

This article is about the term "memory hierarchy".
See Computer data storage for the general context.

What is the place in Wikipedia of this article? I needed it, and it was here. Now it needs me. I ask for opinions.CpiralCpiral 21:05, 28 September 2009 (UTC)[reply]

Cloud storage

[edit]

How does cloud storage fit within the hierarchy? Is it considered tertiary storage? Nearline storage? 70.247.162.60 (talk) 15:37, 8 November 2015 (UTC)[reply]

It can be either Seconday storage or Teriaty storage depending upon implementation details. Tom94022 (talk) 19:36, 8 November 2015 (UTC)[reply]
User:Tom94022 is right, usually it means 3 and 4. Cloud storage may be Computer_data_storage#Off-line_storage (no4) where data is received after prolonged time (hours, days, weeks).
Such delay explained with "archival storage" systems where performance/delay doesn't matter; but maintenance and cost of ownership/operational cost matters.
Sending a hard-drive with data using transportation means is used by some software firms; but that's not a norm. Ushkin N (talk) 21:09, 27 July 2016 (UTC)[reply]
[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on Memory hierarchy. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:37, 25 January 2018 (UTC)[reply]

Use of ambiguous prefixes

[edit]

Various numbers used in this article could the same parameter prefix (i.e., M, G, T, etc) but having different meanings. The article has now unambiguous usage of prefixes by using consistent SI prefixes in place of JEDEC Binary prefixes throughout. The first usage in the Examples section with "Level 0 (L0) Micro operations cache – 6,144 bytes (6 KiB)[8] in size" alerts the reader to the usage of SI Binary prefixes. The question is should the article remain as is or should ambiguous prefixes be used? Tom94022 (talk) 21:00, 26 April 2021 (UTC)[reply]

The article benefits from use of unambiguous units and unit symbols. It would be inappropriate to replies these with ambiguous ones. Dondervogel 2 (talk) 22:15, 26 April 2021 (UTC)[reply]
WP:COMPUNITS controls here. A local consensus cannot override a site-wide guideline. WT:MOSNUM is the correct venue to discuss this if you wish to override WP:COMPUNITS. —Locke Coletc 22:17, 26 April 2021 (UTC)[reply]

IEC units

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Per WP:COMPUNITS, we do not use IEC units like mebibyte (MiB), gibibyte (GiB) and so on except in very limited situations (which this article is not covered by). Further, our sources do not support the language used. I've tagged the impacted sections as appropriate to reflect the current status of the article as not being reliably sourced and containing original research. There is also a balance concern as WP:UNDUE weight is being given to units of measure which are not widely used in the public (which is precisely why WP:MOSNUM forbids their use). Quoth WP:COMPUNITS:

The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except:

  • 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.

If no valid reason for keeping these units is provided, I'll correct them again in the near future. —Locke Coletc 21:04, 26 April 2021 (UTC)[reply]

The assertions above that the use of IEC binary prefixes is a violation of WP:COMPUNITS and that a mathematical transformation is somehow OR. Neither assertion is true.
  • WP:COMPUNITS gives an exception to use IEC binary prefixes in articles in which both types of prefix are used with neither clearly primary. This is such an article.
  • It is not OR to do mathematical transformations. For example, The first usage in the Examples section with "Level 0 (L0) Micro operations cache – 6,144 bytes (6 KiB)[8] in size" alerts the reader to the usage of SI Binary prefixes. The the published value is 6KB which is mathematically 6,144 B or 6 KiB; it is not WP:OR to use either or both mathematical transformations.
This article has been in this style for quite some time. The Arbitration Committee has expressed the principle that "When either of two styles are acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change. So far I see no substantial reason for a change and it would be inappropriate for any changes at this time. It would be useful to have other editor comments. Tom94022 (talk) 21:28, 26 April 2021 (UTC)[reply]
Both assertions are true. This article should not be using IEC prefixes as it does not meet any of the requirements to use them. WP:COMPUNITS provides methods of giving clarity to readers which obviate the need for IEC prefixes. And yes, performing your own transformation from what a source says into something a source doesn't say is in fact the definition of original research. Zero sources use the IEC prefixes as currently displayed in this article. WP:COMPUNITS is clear on what must happen here. —Locke Coletc 21:36, 26 April 2021 (UTC)[reply]
The assertion of OR is ridiculous, and it's easy to show that. The other assertion is debatable, but lacks credibility partly because of the OR claim and partly because you make zero attempt in any of your edits to disambiguate, even though you know disambiguation is required by COMPUNITS. Dondervogel 2 (talk) 22:26, 26 April 2021 (UTC)[reply]
The assertion of OR is ridiculous, and it's easy to show that. Cool story bro. Show it then. —Locke Coletc 23:35, 26 April 2021 (UTC)[reply]
Replacing “KB” with “KiB” is a routine calculation. We all know they mean the same thing. It’s no more OR than replacing other non-standard unit symbols “Mbps”, “Kg” or “kt” with the standard symbols “Mbit/s”, “kg” or “kn”, or countless other examples. Dondervogel 2 (talk) 18:56, 28 April 2021 (UTC)[reply]
Replacing “KB” with “KiB” is no different than converting miles to km, inches to cm, etc. Tom94022 (talk) 20:55, 29 April 2021 (UTC)[reply]
So if I make up some term I can just go around the Wiki and replace longstanding and widely used terms with my made up one? Fascinating. I state that the Lockibi is equal to 0.334cm, with a Lockibim equal to 1000x that. I'll begin the work of moving all of our distance statements in articles to this new, superior, definition of length. Thank you all for your understanding and making me aware that when it comes to units of measure, we can ignore WP:UNDUE and just widely report on units of measure with barely any actual public use. —Locke Coletc 05:45, 30 April 2021 (UTC)[reply]
You cannot expect us to take your arguments seriously with nonsense like this. The kibibyte and mebibyte are defined by international standards and used by 100s of peer-reviewed publications a year. There's no such thing as a "Lockibi". I have reverted your OR tags. Dondervogel 2 (talk) 15:40, 30 April 2021 (UTC)[reply]
This kind of nonsense, as pointed out, is typically the result when arguing with editors who insist on refusing to acknowledge progress and the ever-increasing use of the (not-so-)new units. Arguing and following down the rabbit hole with them is a waste of time; they will never concede to the progress and established notable trend, and typically resort to bullying (like posting groundless attacks on individual user talk pages, "We won, you loose", "you're gaslighting", and on and on...) This has been going on for years and years, and is probably the only reason for the vague and conciliatory language in the MOS, written to appease them and shutdown the warring. The idea that there were dozens of them who found consensus is unsubstantiated, some of them were likely mere socks of themselves. The use and benefit of binary prefixes is an accepted fact, and is shown in hundreds or thousands of pieces of software comprising modern cutting-edge computing. New editors come to Wikipedia all the time creating articles with these units–surely an impressive fact that shows their acceptance. But what happens? They get changed to confusing representations, unbecoming of modern information technology. Every other aspect of many WP articles is disambiguated at nauseam, but not this. Let editors make their own choices. I have not seen such militant behavior by those who do accept these units; they do not go around and change every WP article to new units. They understand that there is a historical background to all this and not every article needs brute-force-conversion. The train toward binary prefixes has long left the station, there is really no point in arguing about it anymore. Accumulating justification by producing lists of use is silly and unproductive. They don't persuade anyone. And finally, surely, these units do not sound any sillier (a common attack) than giga, atto, or yocto. Get with it or shut up. kbrose (talk) 14:44, 3 May 2021 (UTC)[reply]

Removed Locke Cole's attempt to filibuster this discussion and reported him for edit warring. This talk page is the appropriate place to discuss its content which so far has two editors in favor of continuing the long time use of IEC prefixes herein. Moving the discussion to WP:COMPUNITS is WP:FORUMSHOP. Tom94022 (talk) 17:34, 30 April 2021 (UTC)[reply]

Uh... you need to re-read WP:FORUMSHOP because that's exactly what you're doing by deliberately avoiding WT:MOSNUM. You aren't going to change WP:COMPUNITS on this obscure talk page, and WP:COMPUNITS is what will decide whether or not IEC units are used here. Not two editors off in some corner trying to undermine a decision they don't agree with. —Locke Coletc 17:49, 30 April 2021 (UTC)[reply]
Please read carefully read WP:COMPUNITS - it clearly allows the use of IEC binary units on " articles in which both types of prefix are used with neither clearly primary, ..." which is clearly the case here until you imposed your POV. Since this article clearly qualifies for such usage your attempting to move the discussion in fact formum shopping. The editors of this page have de-facto decided it qualifies and you certainly are entitled to raise the question here but you shouldn't impose your POV. Tom94022 (talk) 21:17, 30 April 2021 (UTC)[reply]
LOL!!!! The editors of this page have de-facto decided it qualifies; translation: "We've decided that we're an exception to the site-wide consensus, so those dozens of editors who participated at WT:MOSNUM will have to come argue here to prove us wrong". Yeah... no.... do you even logic? I suppose that applies to WP:V too? After all, who needs verifiability when two editors can decide on their own that they're an exception? —Locke Coletc 21:33, 30 April 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.