| Age | Commit message (Collapse) | Author |
|---|
|
+ Actual cache still missing, lol
+ Initial performance numbers aren't too promising compared to
simt_riscv64 or even simple_mesh1d, but there's a somewhat
increased latency due to registering inputs and the shared req
logic which can likely be improved. Will have to dig into this a
bit further
|
|
|
|
|
|
|
|
+ Might try to fix it at some point in the future but for now I don't
want to carry around broken code
|
|
+ Essentially equivalent to node2d test, just worse
|
|
+ Apparently quite a few components are currently broken, didn't
even remember
|
|
|
|
|
|
+ Seems to decrease performance a little bit, presumably due to
extra register copy, but simplifies code a lot and opens up more
genericism so I'll consider it an upgrade for now. Copying packets
around is rather slow though, might in the future move to some
kind of pointer based packet handling
|
|
|
|
+ Kind of like CHERI, but uses out-of-line pointer information.
The idea is that a core that is compatible with ALLOC_IF queries
the allocation tracker if an address is legal and gets a response.
This ideal tracker effectively has infinite memory and doesn't talk to
any other components, but a real implementation might want to limit
the allocations per process or chat with some reserved memory region
somewhere else in the system to maintain a binary tree or something.
|
|
+ Purely virtual, doesn't exist, but would be 'theoretically' ideal.
|
|
+ Previous name was grid
|
|
|
|
+ Not quite deadlock free for 2D/3D for whatever reason
|
|
+ With the limitation that a grid node can only attempt one move per
clock, which *seems* to be the easiest strategy to implement in hardware,
but I should try experimenting with more complex routing/priority
assignment schemes to speed up the system overall
|
|
+ Starvation is still an issue, but adding a slight bit of randomness
seems to help a bit. Also, simulating massive systems like 64x64 is a
bit too slow, so scale grid example down to 16x16. 256 cores is still
a fair bit, but I might try to think of some optimization methods.
I wonder at what point threading becomes faster than just running on a
single core?
+ Test now also sets processor nodes to sleep to avoid starvation issue,
seems like an opportunity for a DoS attack if someone can get enough
cores to bombard a single node with enough traffic.
The riscv64 processor has an initial control interface, very messy
code, should probably come up with a more elegant way to deal with
sleep/wakeups
|
|
|
|
+ As they are currently implemented, grid *may* get stuck if two nodes
try to send to eachother at the same time, I should probably add in
some kind of input buffer as well
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
