h a l f b a k e r y"More like a cross between an onion, a golf ball, and a roman multi-tiered arched aquaduct."
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
This memory module addin to a processor would contain the
solutions to larger
mathematical transforms for common commands such as
fetches from main
memory, system calls, and every add, subtract, multiply,
and divide command
for numbers up to a byte where the search can take less
time than
the
calculation. (and prehashed searches for them)
It
would interface with
the prefetch, L1, and L2 caches.
Wikipedia: Memoization
http://en.wikipedia.org/wiki/Memoization
What this general technique is called. [jutta, Aug 26 2010]
Faster laziness using dynamic pointer tagging
http://research.mic...s/ptr-tag/index.htm
Among other things, this paper discusses using tagged pointers to implement memoisation with optional hardware support, assuming I've remembered the right paper. [Wrongfellow, Aug 26 2010]
[link]
|
| |
Hm. This works at a more abstract level, but I
don't see it doing much good as a low-level
optimization technique. |
|
| |
What system call would you like to see cached
this way? |
|
| |
For "fetches from main memory", isn't this just
what a cache does (together with the increased
complexity of knowing when to invalidate the
cache)? |
|
| |
I doubt there would be much benefit to this for simple operations like addition etc for small numbers, which are generally much faster than memory accesses - to the point where some compilers will deliberately choose to recalculate an expression rather than saving it in the stack frame for later. |
|
| |
System calls aren't worth caching like this as they don't perform pure computations - they have side effects such as "write this block of bytes to that file". There's no point switching into kernel context or whatever if you're just going to calculate a value and return it. |
|
| |
For more complex calculations something like this can be a big win - see [jutta]'s link. Hardware support for this has been proposed before, often in the context of "tagged pointers" - see second link - which can impose a noticeable overhead if implemented in pure software. |
|
| |
I actually like this concept in that it may quicken math solutions for some who deal with repetitive, but alternating functions on large scale projects. |
|
| |
- check for bending, shear, & deflection from picked points of beam - no? (Hit Alt key) check for ... On column - no? (Hit Alt key) check for uplift, overturning... |
|
| |
I don't know if it could be made to work, but I suspect it could. |
|
| |