Espozo wrote:
93143 wrote:
This is apparently why some people object to the term "cache" being used for TMEM on the N64, because unlike the PSX's texture cache, you have to explicitly load data into TMEM in order to use it.
I'd have thought this would be irrelevant; what's the textbook definition of cache in computer science? It'd have thought it'd just be "smaller but faster ram."
Cache is a more generic term, it's not memory-specific. A cache optimization stores some result and reuses it, instead of having to do it the "long" way. That long way could refer to a slow main memory fetch, or it could be some kind of computation, etc.
For instance, a search engine will cache recent search results so that when someone else asks for the same thing, they can just reuse that result instead of doing the whole search process again.
Outside the computer context a cache is just a place where you store stuff, or a collection of stored stuff. In computer science "cache" means "use a cache as an optimization". Store something to save effort.
Espozo wrote:
rainwarrior wrote:
93143 wrote:
Also, I suspect the use of an explicit start-caching-here instruction is archaic.
It's not archaic. Cache control instructions are very useful in high performance development.
You just reiterated what he said.
I don't think I did, but I guess 93143 really just meant that the SuperFX's mechanism is archaic, or maybe even more specifically that the SuperFX's instruction caching
doesn't happen unless you use an instruction to enable it? Modern CPUs do most of their caching in an automated way, without programmer or compiler intervention. For high performance code, though, and occasionally for other reasons, you have some explicit control instructions that can be taken advantage of. Ultimately, you can know more about your code and data than the compiler or CPU does; in the right place doing it "by hand" will outperform the automated version.
Espozo wrote:
Anyway, if the processor itself does so much abstracting already, then do you still need to program for each core specifically, or does the processor somehow handle that during runtime as well?
I think controlling which thread goes on which core is normally the operating system's job. It's got to multitask all running programs, not just yours. If you have 4 cores and create 4 threads and do heavy activity on each of them, the OS will generally automatically spread that load over the 4 cores. That's its job, and it will normally manage to do it fairly well. (Threads can move across cores, too. They don't have to stay where they began.)
...but again, there's ways to explicitly control this too. You can ask an OS how many cores you have, and you can tell it to put a thread on a specific core. On a console where you're not really multitasking in the same way, and the computer architecture is guaranteed, it's often very appropriate to do this. It's a refinement that can be used if needed.
See:
Wikipedia: Processor Affinity