In stats.txt file i find that difference between commited instructions and Ops
system.cpu_cluster.cpus.committedInsts 5028 # Number of instructions committed
system.cpu_cluster.cpus.committedOps 5834 # Number of ops commited
Can someone describe their difference ?
"committedInsts" is the architectural number of assembly instructions executed.
"commmittedOps" is the number of micro-operations. Each instruction can expand to multiple microoperations, so this number is always greater or equal than committedInsts.
See also: Difference between an instruction and a micro-op
Related
I'm trying to calculate the total memory a repository in GraphDB takes.
The total memory of the repository depends of the number of statements and the inference. As a starting point you can take a look at http://graphdb.ontotext.com/documentation/9.4/free/requirements.html
If you have inference sum the implicit and explixit statements.
I am not able to get what does the parameter parallel_iterations stand for in sampling multiple chains during MCMC.
The documentation for mcmc.sample_chain() doesn't give much details, it just says that
The parallel iterations are the number of iterations allowed to run in parallel. It must be a positive integer.
I am running a NUTS sampler with multiple chains while specifying parallel_iterations=8.
Does it mean that the chains are strictly run in parallel? Is the parallel execution dependent on multi-core support? If so, what is a good value (based on the number of cores) to set parallel_iterations? Should I naively set it to some higher value?
TensorFlow can unroll iterations of while loops to execute in parallel, when some parts of the data flow (I.e. iteration condition) can be computed faster than other parts. If you don't have a special preference (i.e. reproducibility with legacy stateful samplers), leave it at default.
What is the difference between Global Seed and Operation Seed in TensorFlow.
According to the tensorflow documentation
While explaining Global Seed, they mention this
If the global seed is set but the operation seed is not set, we get
different results for every call to the random op, but the same
sequence for every re-run of the program:
and while explaining Operation Seed, they again state, something similiar
If the operation seed is set, we get different results for every call
to the random op, but the same sequence for every re-run of the
program:
what are the main differences between the two...and how do they operate at a intuitive level.
Thanks.
Here is good decription of the differences: https://www.kite.com/python/docs/tensorflow.set_random_seed
In short, tf.random.set_seed or tf.set_random_seed will guarantee that all operations will produce repeatable results across sessions. It will set the operation-seed deterministically for every operation.
Setting operation seed makes sense only as part of operation definition tf.random_uniform([1], seed=1) and will also lead to same sequences produced by this op across sessions.
What is the difference?
graph-seed makes all ops repeatedly deterministic. Use it if you want to fix all ops. Different ops will still produce different sequences (but repeated across sessions)
operation-seed makes single operation deterministic. You can create 2 ops that will produce same sequences.
I am using TensorFlow's Supervisor to train my own model. I followed the official guide to set save_model_secs to be 600. However, I strangely find the path log_dir merely saves the latest five models and automatically discard models generated earlier. I carefully read the source code supervisor.py but cannot find the relevant removal code or mechanism why just five models can be saved all along the training process. Does any have any hint to help me? Any help is really appreciated.
tf.train.Supervisor has a saver argument. If not given, it will use a default. This is configured to only store the last five checkpoints. You can overwrite this by passing your own tf.train.Saver object.
See here for the docs. There are essentially two ways of storing more checkpoints when creating the Saver:
Pass some large integer to the max_to_keep argument. If you have enough storage, passing 0 or None should result in all checkpoints being kept.
Saver also has an argument keep_checkpoint_every_n_hours. This will give you a separate "stream" of checkpoints that will be kept indefinitely. So for example you could store checkponts every 600 seconds (via the save_model_secs argument to Supervisor), but only keep the five most recent of those, but additionally save checkpoints each, say, 30 minutes (0.5 hours) all of which will be kept.
When I run valgrind on my process and after process exit I get below output. What is the meaning of "loss record 33,118 of 34,156"
==4215== 2,048 bytes in 128 blocks are definitely lost in loss record 33,118 of 34,156
It means the 33118th loss record of total 34156 records.
As described in Memory leak detection section of Valgrind documentation,
... it merges results for all blocks that have the same leak kind and sufficiently similar stack traces into a single "loss record".
... The loss records are not presented in any notable order, so the loss record numbers aren't particularly meaningful. The loss record numbers can be used in the Valgrind gdbserver to list the addresses of the leaked blocks and/or give more details about how a block is still reachable.