You can test this entry and submit issues during the testing period of the TON Block Validation Challenge contest.
Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.
Info
Testing and Issues
Voting
Comments
I just realized that all of the "actor stuff" can do parallelism (I thought it's some kind of remainder of the main codebase, which has to deal with network and asynchrony), so I removed all the corresponding parts. For example, I replaced:
td::actor::send_closure(actor_id(this), &ContestValidateQuery::got_neighbor_out_queue, i, r_state.ok()->message_queue())
with a simple:
got_neighbor_out_queue(i, r_state.ok()->message_queue())
so I accidentally _removed_ some of the multithreading.
That's too say: the impact of my multithreading changes is slightly higher than it would appear.
td::actor::send_closure(actor_id(this), &ContestValidateQuery::got_neighbor_out_queue, i, r_state.ok()->message_queue())
with a simple:
got_neighbor_out_queue(i, r_state.ok()->message_queue())
so I accidentally _removed_ some of the multithreading.
That's too say: the impact of my multithreading changes is slightly higher than it would appear.
On a similar note, I assumed several block validations might be launched in parallel. If that is not the case and the verification is always one after another, some memory re-allocations could be easily removed. Most notably:
CellUsageTree::CellUsageTree() {
nodes_ = new Node[600000];
could be made a single static allocation.
(in case several block validations might run in parallel, some memory pool could be implemented to prevent re-allocations, but I didn't get to this)
CellUsageTree::CellUsageTree() {
nodes_ = new Node[600000];
could be made a single static allocation.
(in case several block validations might run in parallel, some memory pool could be implemented to prevent re-allocations, but I didn't get to this)
You have not added any comments yet...