I'm using HardHat with gas-report but I'm not able to understand the following results:
Optimizer enabled: false
Runs: 200
Block limit: 30000000 gas
% of limit
Here I have marked with red square the fields:
enter image description here
Optimizer (whether it's enabled or disabled) and the target amount of contract runs, to which the optimizer should optimize the contract bytecode, are options of the Solidity compiler. When you compile the contract with an optimizer, it can decrease either the total bytecode size - or the amount of gas needed to execute some functions. (docs)
Block limit states the amount of gas units that can fit into one block. Different networks might have different values, some have dynamically adjusted limits, plus you can usually set your own limit if you're using an emulator or a private network. (docs)
% of limit states a portion of how much your contract deployment took in the total block limit. Example from your table: Deployment of HashContract cost 611k gas units, which is approx. 2% of the 30M block limit. If the number exceeds 100%, the transaction would never be included in a block - at least not in a block with the same or smaller limit. Also, if the transaction has a low gasPrice and a high % of the total block limit, some miners/validators might not be able to fit the transaction into a block (as transactions are usually ordered from highest gasPrice to lowest), so it might take longer to be included in a block.
Related
Let's say I have a smart contract with branch, where each branch has a different number of operations.
if (someCondition) {
// do operations costing 10 gas
} else {
//do operations costing 100 gas
}
When a user goes to call this function from their client, say metamask, how do they know how much gas their transaction will cost? Do they just have to guess and include enough gas for the most expensive path?
The client app is almost always able to calculate the gas usage. Either by running their own EVM emulator, or by querying an external API that emulates the transaction and returns the result.
All blockchain data is publicly available for reading (even values of private properties - just not with Solidity, but with using more low-level approach and querying the storage slots), and the gas cost of each operation is predetermined.
So the client knows, that the transaction is going to
read one slot from memory
write into storage slot
declare another slot in memory and return it
And it also knows that one MLOAD costs 3 gas, one SSTORE costs 5,000 gas, etc.
It can use all this data to calculate the final cost.
The exception is when the decision tree is based on block data such as block.timestamp, that is unknown beforehand. Then it depends on the client, but my guess is that most suggest the most expensive combination, so that they lower the risk of having the transaction reverted due to insufficient gas.
Example:
if (block.timestamp % 2 == 0) {
// even second, do operations costing 10 gas
} else {
// odd second, do operations costing 100 gas
}
You can find all the values corresponding to the relative costs, in gas, of a number of abstract operations that a transaction may affect in the Ethereum yellow paper (page 27).
The "if" statment in a low level languaje, is consider a "JUMP" operation (alters de program counter). So in the gas cost table (page 27) says that a JUMPDEST operation cost 1 gas value.
i know what is a gas, gaslimit and gasprice, but still have confusion even after searching and reading through the Internet.
There is a gaslimit per block, but why many blocks did not reach it? in other words, can a miner send a block to the network without reaching the gaslimit for the block?
Assume the block gaslimit is 4 million and i sent a transaction with 4 million gaslimit. But when the miner executed it (used gas was 1 million). Can the miner add extra transactions to the block to fill the remaining 3 million or not. In another way, does a transaction with a big gaslimit (but uses a fraction of that gas) affects the miner of adding more transactions to the block?
Each Opcode coast some value of gas. How Ethereum measure the cost of each EVM opcode? (any reference for explanation?).
Thanks
Q1 The block gas limit is an upper bound on the total cost of transactions that can be included in a block. Yes, the miner can and should send a solved block to the network, even if the gas cost is 0. Blocks are meant to arrive at a steady pace in any case. So "nothing happened during this period" is a valid solution.
Q2a The gas cost of a transaction is the total cost of executing the transaction. Not subject to guesswork. If the actual cost exceeds the supplied gas then the transaction fails with an out-of-gas exception. If there is surplus gas, it's returned to the sender.
Q2b Yes, a miner can and should include multiple transactions in a block. A block is a well-ordered set of transactions that were accepted by the network. It's a unit of disambiguation that clearly defines the accepted order of events. Have a look here for exact meaning of this: https://ethereum.stackexchange.com/questions/13887/is-consensus-necessary-for-ethereum
Q3 I can't say for sure (possibly someone can confirm) that this is an up-to-date list: https://docs.google.com/spreadsheets/d/1m89CVujrQe5LAFJ8-YAUCcNK950dUzMQPMJBxRtGCqs/edit#gid=0
The site https://ethstats.net displays statistics about the Ethereum network but I did not find a precise definition of each statistic and graph displayed. Is there somewhere I can get this information?
These are the items of the overview:
Best Block is the heaviest block regarding the cummultative difficulty, or in simple words: the highest block number of the longest valid chain.
Uncles are orphaned blocks, but in oposite to other blockchain systems, uncles are rewarded and included in the blockchain. Shows current bloc's uncle count and uncle count of last 50 blocks.
Last Block shows the time since the last block was mined, usually in seconds.
Average Block Time is, well, the average time between two blocks, excluding uncles, in seconds. Should be something around 15 seconds.
Average Network Hashrate is the number of hashes bruteforced by the network miners to find a new block. 5 TH/s means the network power is at five trillion hashes per second.
Difficulty is the current mining difficulty to find a new block which basicly means how hard it is to find a matching hash.
Active Nodes is the number of connected nodes to the Ethstats dashboard, (not the whole ethereum network!)
Gas Price is the price miners accept for gas. While gas is used to calculate fees. 20 gwei is the current default, which stands for 20 Giga-Wei which are twenty billion wei that is 0.00000002 ETH.
Gas Limit is the block gas limit. It defaults to 1.5 pi million gas (4,712,388) and miner can only include transactions until the gas limit is met (and the block is full). The gas limit is the analogy to bitcoin's block size limit, but not fixed in size.
Page Latency and Uptime are specific stats for the dashboard.
Block Time Chart shows the actual time between the last blocks.
Difficulty Chart shows the actual difficulty of the last blocks.
Block Propagation Chart shows how fast blocks are shared among the nodes connected to the dashboard.
Last Block Miners are the public keys of the miners who found most of the last blocks.
Uncle Count Chart shows numbers of uncles per 25 blocks per bar.
Transactions Chart shows numbers of transactions included in last blocks.
Gas Spending Chart shows how much gas was spent on transactions in each block, note the correlation to the transactions chart.
Gas Limit Chart shows the dynamicly adjusted block gas limit for each block.
And below you see details of connected nodes.
I have 2 version of a program I must analyze. One is recursive and the other is iterative. I must compare cache hit rate for both and examine as performance varies for both methods as well as their instructions count
For both methods regardless of block setting I get roughly 100 less memory access for the iterative method. both trigger 2 misses. I can only drop the cache hit rate to 85% if i set the setting to 1 block of size 256.
for the instructions count the iterative is roughly 1000 instructions less
Can someone explain to me why this happens or provide some literature I can read this in I can't seem to find anything. I would just like a general overview of why this occurs.
Took some info from this question: Recursion or Iteration? and some from in COMP 273 at McGill, which I assume you're also in and that's why you asked.
Each recursive call generally requires the return address of that call to be pushed onto the stack; in MIPS (assembly) this must be done manually otherwise the return address gets overwritten with each jal. As such, usually more cache space is used for a recursive solution and as such the memory access count is higher. In an iterative solution this isn't necessary whatsoever.
The hadoop documentation states:
The right number of reduces seems to be 0.95 or 1.75 multiplied by
( * mapred.tasktracker.reduce.tasks.maximum).
With 0.95 all of the reduces can launch immediately and start
transferring map outputs as the maps finish. With 1.75 the faster
nodes will finish their first round of reduces and launch a second
wave of reduces doing a much better job of load balancing.
Are these values pretty constant? What are the results when you chose a value between these numbers, or outside of them?
The values should be what your situation needs them to be. :)
The below is my understanding of the benefit of the values:
The .95 is to allow maximum utilization of the available reducers. If Hadoop defaults to a single reducer, there will be no distribution of the reducing, causing it to take longer than it should. There is a near linear fit (in my limited cases) to the increase in reducers and the reduction in time. If it takes 16 minutes on 1 reducer, it takes 2 minutes on 8 reducers.
The 1.75 is a value that attempts to optimize the performance differences o the machines in a node. It will create more than a single pass of reducers so that the faster machines will take on additional reducers while slower machines do not.
This figure (1.75) is one that will need to be adjusted much more to your hardware than the .95 value. If you have 1 quick machine and 3 slower, maybe you'll only want 1.10. This number will need more experimentation to find the value that fits your hardware configuration. If the number of reducers is too high, the slow machines will be the bottleneck again.
To add to what Nija said above, and also a bit of personal experience:
0.95 makes a bit of sense because you are utilizing the maximum capacity of your cluster, but at the same time, you are accounting for some empty task slots for what happens in case some of your reducers fail. If you're using 1x the number of reduce task slots, your failed reduce has to wait until at least one reducer finishes. If you're using 0.85, or 0.75 of the reduce task slots, you're not utilizing as much of your cluster as you could.
We can say that these numbers are not valid anymore. Now acording to the book "Hadoop: definitive guide" and hadoop wiki we target that reducer should process by 5 minutes.
Fragment from the book:
Chosing the Number of Reducers The single reducer default is something
of a gotcha for new users to Hadoop. Almost all real-world jobs should
set this to a larger number; otherwise, the job will be very slow
since all the intermediate data flows through a single reduce task.
Choosing the number of reducers for a job is more of an art than a
science. Increasing the number of reducers makes the reduce phase
shorter, since you get more parallelism. However, if you take this too
far, you can have lots of small files, which is suboptimal. One rule
of thumb is to aim for reducers that each run for five minutes or so,
and which produce at least one HDFS block’s worth of output.