Talk:Locality of reference

Globality of reference

See the new section of the article. I made explicit what I found already in the article in an implicit way: namely that locality is only a frequently occurring phenomenon, but the globality is also there in the life of computers. I also restructured the article and removed a few dulicated paragraphs, but in a conservative way: not to vanish any existing information. prohlep (talk) 16:27, 6 July 2008 (UTC)

---

I am not a native English speaker (see my user page and my academic page, I have the both), hence I encourage everybody to correct my formulation of sentences. During the last 4 hours it turned out, that THE SAME INFORMATION can be restructured in a better way, and also to include the reasons when locality fails, ESPECIALLY THIS IS THE CASE IN THE TOPIC OF MY ACADEMIC INTEREST. Naturally, as soon as my major restructuration will be settled (i.e. the under construction template is removed), it is worth while to judge, whether the new result is better than the original one. prohlep (talk) 21:32, 6 July 2008 (UTC)

---

THANKS EVERYBODY FOR THE ALMOST 9 HOURS OF PATIENCE. I HOPE, THAT I DID NOT MAKE WORSE THE ARTICLE AND I DID NOT VANISH ANY INFORMATION. I tried to reorganize the sections in such a way, that now we have a concise abstract, then two definitions (locality and globality), then two set of sufficient conditions for these notions, and the three sections where the usage of the locality is presented, first in general, and then gradually more and more restricted to particular examples. I essentially left untouched these three sections, I did not feel enough motivation to enhance them. Finally the usual references an see also, etc.

Just before me, 9 hours ago, the size of the page was 8513, and now it is 13011. My work is perhaps not a real vandalism.

Feel everybody himself free to improve this article, I know that my English needs essential polishing, but I wish not to fall back entirely to the original state what I found here approximately 9 hours ago. prohlep (talk) 01:00, 7 July 2008 (UTC)

URGENT TO DEREK FARN:

(cur) (last) 22:38, 6 July 2008 Derek farn (Talk | contribs) (8,515 bytes) (rv: Incorrect and poorly written attempt at a reworked article (please work out proposed major rewrites on the talk page first)) (undo)

COULD YOU NOT IGNORE THE {{underconstruction}} underconstruction TEMPLATE??!!

COULD YOU FIRST VISIT THE DISCUSSION PAGE, WHAT I KIND OF MAJOR WORK IS GOIN ON DURING THE LAST 4 HOURS??!!

COULD YOU FIRST CREATE YOUR User:Derek farn PAGE, OTHERWISE WE DO NOT KNOW, WHO ARE YOU??!!

DEREK, STOP VANDALIZE MY WORK DONE DURING THE 4 HOURS AND IS STILL IN SUBSTANTIAL PROGRESS!!!

For further reference on Derek, see Wikipedia:Mediation Cabal/Cases/2006-06-06 Programming language: "Derek farn is reverting changes without discussion, including sarcastic edit summaries, and ...", OK, so this is not the first case. prohlep (talk) 20:59, 6 July 2008 (UTC)

---

Even quite a few of the google [1] hits reports collision between Derek farn and the rest of the society

BUT THE GOOGLE DID NOT GIVE ANY ACADEMIC SITE OR PERSONAL HOMEPAGE ABOUT ANY PERSON NAMED DEREK FARN, SO I DO NOT SEE ANY FIRM SCIENTIFIC BACKGROUND BEHIND HIS PERSONAL OPINION AND ARTICLE VANDALISM. prohlep (talk) 21:11, 6 July 2008 (UTC)

T2, M2, M1

My question refer to Equation (4.1) on Page 132 of Book titled Computer Organization & Architecture -- Designing for Performance -- 6th Ed. by William Stallings ISBN-81-203-2103-0.

Time T2 is the access time from Main memory. This access time indicates only copying data from main memory (M2) to cache (M1) --OR-- it includes copying from M2->M1 and from M1->processor?. —Preceding unsigned comment added by 152.163.253.34 (talk • contribs)

Locality of reference versus Memory locality

The page should not be merged with memory locality. Memory locality describes the proximity of blocks of data in memory whereas locality of reference refers to the concept that programs often use data that are close to one another either spatially or temporally. The 2 concepts are similar yet distinct. —Preceding unsigned comment added by 84.9.208.34 (talk • contribs)

Well, the problem is that the "memory locality" article does indeed describe the latter idea, just like this article does. They should definitely be merged. --Piet Delport 15:20, 10 April 2006 (UTC)

I started the Memory Locality article (before I had an account) but didn't realize this article already existed. I agree with Piet Delport that they should be merged, though I may not get around to it. --Kimball Robinson Mon Apr 17 22:58:34 2006

This page should not be merged. Locality of reference describes more than memory locality. It also describes locality of access in filesystems, where files in the same directory are likely to be accessed at the same time. Filesystems try to optimise for this behaviour. There are also lots of other instances where the locality of reference principle applies. The article should be expanded to cover more than memory locality, rather than being merged. -- Phillip Lougher Tue May 30 00:37 2006

What are filesystems, but another type of memory? Are the principles really different enough to warrant separating them into two articles?

(Also, just to make it clear: expanding the article would be part of the merging process, not something that stands in opposition to it.) --Piet Delport 12:15, 30 May 2006 (UTC)

Seems like most people would prefer merging the articles; I added {{merge}} tags to both. -- intgr 08:26, 3 January 2007 (UTC)

File systems are not just "another type of memory". Also, couldn't memory locality be expanded to discuss multi-processor architectures and failure modes? In such a sense, memory locality can explain the problems with thread locality. -- anonymous 6:42 PM (EST) Jan 15 2007

The Memory locality article covers the same ground as this article, albeit only in the context of main memory. It is essentially a desciption of locality of reference as it applies to main memory. There is no reason that material should not be in this article (where not redundant). Once that is merged in here, there would not be anything left to Memory locality, so it should redirect here (since locality of reference is the more general and widely-known term). -R. S. Shaw 20:40, 4 January 2007 (UTC)

I agree completely. Locality of Reference also applies to other kinds of resources, such as web pages and even parking spaces. The topic of memory locality is a subset of the broader topic of locality of reference. - Rrcjab 23:44, 3 March 2007 (UTC)

It seemed pretty clear to me that nobody supports merging "Locality of reference" into "Memory locality". However, there seems to be some support for merging "memory locality" into "locality of reference". I thusly updated the merge tags to reflect the proposed merge direction. Since some of the above comments seem to assume one merge direction over the other, hopefully that will help direct the conversation towards the more viable merge possibility. – Zawersh 01:30, 9 April 2007 (UTC)

I also agree with merging memory locality into locality of reference. If no one speaks up for about a week, someone should do this. Superm401 - Talk 17:22, 13 December 2007 (UTC)

You should never say "someone should do this" on WP. It'll never get done. Also, See WP:BOLD. I just happen to be running through the REALLY old merge tags and did this. --ShakataGaNai (talk) 01:39, 27 December 2007 (UTC)

Modern caches do leverage spatial and temporal locality to improve memory coherence. Therefore, the spatial and temporal locality definitions can definitely be incorporated into the memory locality section of the WIki. —Preceding unsigned comment added by 129.59.94.146 (talk) 20:08, 18 December 2007 (UTC)

Merge Completed. --ShakataGaNai (talk) 01:39, 27 December 2007 (UTC)

Merge needed

The following articles are all largely about the same thing: "Locality of Reference" "Loop tiling" "Loop nest optimization" You would not guess this from what each says about the others. The information should probably be consolidated in one place by someone who has permissions. Also, it would be of extreme benefit to this topic of matrix blocking to have pictures that illustrate what's going on. 98.119.149.245 (talk) 23:19, 27 May 2014 (UTC)

[Please discuss at Talk:Loop nest optimization#Merge needed -- intgr [talk] 07:25, 28 May 2014 (UTC)]

link to morton & hilbert curves?

does anyone else think these topics are related enough to warrant an link?

http://en.wikipedia.org/wiki/Z-order_curve http://en.wikipedia.org/wiki/Hilbert_curve

yes i think those are worth considering, I've throw a description in another article memory access patterns, and i think thats a nicer place to link them too 'memory access patterns -> 2d/spatial (suitable for z-order curve)'. i've added links elsewhere too (texture mapping articles etc)Fmadd (talk) 19:53, 13 June 2016 (UTC)

Loop tiling and previous merge of Memory Locality

I see this article spells out an example for 'loop tiling' which came from an article 'memory locality', but loop tiling has it's own article. I would argue that the previous merge from 'memory locality' is counter productive.

What's the need to cram everything into one article, when wikipedia is hypertext accessed in a browser???

Why not rely on a link describing something in detail. Also think about the new hover cards feature and how nice it is to have a simple,direct,definitive definition from a linked phrase. Merges lose this, and it becomes awkward to reword text to define things. "memory locality" is a distinct term, often used, and a subset of / slightly different to 'locality of reference' arguably locality of reference can apply to things other than memory)

I've added an article memory access pattern really just wanting to define a phrase but went through the exercise of 'trying to flesh out an article', but I realise that this might just get merged here.. which again would IMO be counter-productive.

Think about the flow of concepts from one phrase. Perhaps 'memory locality' was a page that could have grown into what I was trying to write... but yet there are still difference.

I'm covering the concept of 'scatter/gather' memory access patterns r.e. GPGPU and parallelism. The phrases 'locality of reference', 'memory locality' , and 'memory access pattern' all appear in slightly different contexts and have a different emphasis.

In my added article, I was happy to reference 'loop tiling' as a solution in a list of categories of 'memory access patterns' (sequential, strided, random..)

I also notice this page immediately describes 'several types of locality', whilst memory locality is more specific.

Fmadd (talk) 19:49, 13 June 2016 (UTC)