I am implementing a prefetcher on gem5. It requires to know the RAS state, branch type (call or return ) and branch target of a committed instruction. I am new to the gem5 environment. How can I get this info to the prefectcher?
Related
I'm reading the definition of leaderless state machine replication from this Thesis.
Page 34, section 3.2.1, defines the transitive closure of a deps*(c) as the transitive closure of the deps relation starting from {c}. deps relation here means the incoming neighbours of a node. For example, in the figure below, the deps(a) = {b}.
In g_4, it says the deps*(a) and deps*(b) are all {a,b,c,d} (deps(a) = {b} and deps(b) = {a,d,c}). From what I thought, this set tells all the preceding commands that must be executed before or with a command.
But what does the "starting from {c}" mean in the definition of Transitive Closure?
taking deps*(a) as the example, does it mean all deps relations starting from {a}?
I am running gem5 version 22.0.0.2. I operate Garnet in a standalone manner in conjunction with the Garnet Synthetic Traffic injector. I want to emulate a routerless NoC so I guess I need to connect an end point (e.g, Cores, Caches, Directories) to more than one "local" router. I just use a python configuration to configure the topology. But when I do this, there is a runtime error:
build/NULL/mem/ruby/network/garnet/GarnetNetwork.cc:125: info: Garnet version 3.0
build/NULL/base/stats/group.cc:121: panic: panic condition statGroups.find(name) != statGroups.end() occurred: Stats of the same group share the same name `power_state`.
Memory Usage: 692360 KBytes
Program aborted at tick 0
Here is a description from the gem5 documentation: "Each network interface is connected to one or more “local” routers which is could be connected through an “External” link." Here is the link:https://www.gem5.org/documentation/general_docs/ruby/heterogarnet/
Here is the constructor of Stats::Group
Group(Group *parent, const char *name = nullptr)
Here is a description from the gem5 documentation: "there are special cases where the parent group may be null. One such special case is SimObjects where the Python code performs late binding of the group parent."
Here is the link:https://www.gem5.org/documentation/general_docs/statistics/api.
I guess the error may be related to this, but I don't know the exact reason.
Any help would be appreciated.
Thank you.
I want to keep track on 2 repo with the SAME NAME created SEPARATELY. 1 is in local machine and 1 is in remote.
But whenever I pressed "publish repository" after "commit to production", there was a red warning saying that "Repository creation failed. (name already exists on this account)".
So my question is, is there any way for me to keep track on the code history of these 2 repo?
Thank you.
I'm going to assume that when you say "repo" you mean "branch" (a big stretch, I know), and that the situation is something like this: GitHub has this:
A -- B -- C (mybranch)
But you on your local machine have this:
X -- Y -- Z (mybranch)
And I take it that what you want is this, on both:
A -- B -- C -- X -- Y -- Z (mybranch)
The way to obtain that is as follows:
git fetch
git switch mybranch
git rebase --keep-empty origin/mybranch
git push origin mybranch
You will observe that I have not limited myself to the restriction that this should be done using GitHub Desktop alone. I don't know whether it has the power to do this (and I don't really care).
I'm submitting jobs to a cluster via SLURM scheduler, and let's say I have access to 5 types of GPUs in my cluster. They are GPUs of type A,B,C,D,E. I would like to submit a job that requests the use of GPUs of type A or B or C but NOT of type D or E. So I need some type of OR logic with the --gres flag.
As a concrete example, here is what it looks like when I request a gpu of a single type (in this case, an RTX 2080):
qlogin -p gpu --gres=gpu:rtx2080:1 --mem=8g -c 2 I'd like to do this but allowing SLURM to pick from a list of allowed GPU types
Slurm does not have that option at this time.
One workaround is for the system administrator to setup features of the node with the GPU type to allow a request such as:
qlogin -p gpu --gres=gpu:1 --constraint="rtx2080|rtx3090" --mem=8g -c 2
(assuming qlogin uses the same options as sbatch)
If that is not possible, you can submit as many job as there are types of GPU that you want, all with the same --job-name=<SOME_NAME> and the --dependency=singleton option. Then you use whichever job starts first and cancel the other with
scancel --jobname <SOME_NAME> --state=PENDING
The --dependency option makes sure only one job is started at a time.
I am aiming on GPU-mining Ethereum on a Windows 10 PC with 2 Radeon RX590.
geth version is
1.9.9-stable-01744997
cmd call to start geth:
geth --rpc --syncmode "fast" --cache 4096 --etherbase [ADR] --datadir "[MyDataDir]" --mine --minerthreads 0
Blockchain is up to date and everything seems fine on the geth side.
Used Miner is
Claymore's Dual GPU Miner - v15.0
cmd to start miner:
EthDcrMiner64.exe -epool http://127.0.0.1:8545 -mode 1 -tt 75
Now the miner starts and seems to start mining. GPU's show they are doing massive work.
Once the miner is initiated it only permanently outputs something like this (plus every once in a while some GPU info):
ETH: 12/21/19-15:46:33 - New job from 127.0.0.1:8545
ETH - Total Speed: 21.345 Mh/s, Total Shares: 0, Rejected: 0, Time: 45:52
ETH: GPU0 10.665 Mh/s, GPU1 10.680 Mh/s
So this looks good.
In the geth console meanwhile I get this output:
INFO [12-21|15:46:35.446] Imported new chain segment blocks=1 txs=74 mgas=9.921 elapsed=159.999ms mgasps=62.007 number=9141165 hash=05972d…032349 dirty=1019.58MiB
INFO [12-21|15:46:35.459] Commit new mining work number=9141166 sealhash=35129c…59de27 uncles=0 txs=0 gas=0 fees=0 elapsed=999.3µs
INFO [12-21|15:46:35.720] Commit new mining work number=9141166 sealhash=3788e2…df83fc uncles=0 txs=39 gas=9922304 fees=0.0347883012 elapsed=261.998ms
WARN [12-21|15:46:36.032] Served eth_submitHashrate conn=127.0.0.1:54083 reqid=6 t=0s err="the method eth_submitHashrate does not exist/is not available"
INFO [12-21|15:46:38.548] Commit new mining work number=9141166 sealhash=7451f4…69a431 uncles=0 txs=72 gas=9911680 fees=0.04369322037 elapsed=89.942ms
WARN [12-21|15:46:41.120] Served eth_submitHashrate conn=127.0.0.1:54083 reqid=6 t=0s err="the method eth_submitHashrate does not exist/is not available"
There is this warning/error message:
err="the method eth_submitHashrate does not exist/is not available"
But also it states "Commit new mining work".
I am quite unsure now.
Do I mine or do I only waste electric power as the work is never commited?
You have not connected to any mining pools, only to your own geth node, meaning that you are mining alone and competing against the whole world. When mining solo, you have no shares. You either mine a whole block or get nothing. It is extremely hard to mine all alone, thus it is advised to join a mining pool. Claymore-Dual-Miner (CDM) has a list of available mining pool alternatives.
Also, when mining solo with CDM, you can miss mined messages because in this mode, it uses HTTP protocol instead of the Stratum pool protocol. You can manually check your balance on etherscan at any time, though.
Use PhoenixMiner 5e with -rate 2 command. It will stop showing this error.