Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show the hash rate of each implementation #47

Closed
furuame opened this issue May 27, 2018 · 11 comments
Closed

Show the hash rate of each implementation #47

furuame opened this issue May 27, 2018 · 11 comments
Assignees
Labels
enhancement New feature or request

Comments

@furuame
Copy link
Member

furuame commented May 27, 2018

Show the hash rate of each implementation by using BUILD_BENCH option

@furuame furuame added the enhancement New feature or request label May 27, 2018
@furuame furuame self-assigned this May 27, 2018
@furuame furuame removed their assignment Sep 11, 2018
@furuame
Copy link
Member Author

furuame commented Sep 11, 2018

@marktwtn Please reference the implementation in iotaledger/giota

@marktwtn
Copy link
Collaborator

The current implementation of getting the hash times would be calling an API
getHashTimes(ImplContext *impl_ctx, void *pow_ctx)

It would call the corresponding hardware-related function.
Take CPU - SSE as an example:

static uint64_t PoWSSE_getHashTimes(void *pow_ctx)
{
    uint64_t count = 0;
    PoW_SSE_Context *ctx = (PoW_SSE_Context *) pow_ctx;
    Pwork_struct *pitem = ctx->pitem;

    for (int i = 0; i < ctx->num_threads; i++) {
        if (pitem[i].ret >= 0 )
            count += (uint64_t)pitem[i].ret;
        else
            count += (uint64_t)(-(pitem[i].ret) + 1);
    }

    return count;
}

The GPU implementation is still under investigation.
The FPGA implementation would be completed by @ajblane .

@furuame
Copy link
Member Author

furuame commented Sep 20, 2018

@marktwtn About hash times of the OpenCL, you can take a look from giota. It seems trivial.

https://github.com/iotaledger/giota/blob/e34a409290248e6ff2205b06062d702690910f04/pow_cl.go#L94

marktwtn added a commit to marktwtn/dcurl that referenced this issue Sep 20, 2018
Obtain the hash times mentioned in DLTcollab#47 with API.
marktwtn added a commit to marktwtn/dcurl that referenced this issue Sep 21, 2018
Obtain the hash times mentioned in DLTcollab#47 in `doThePoW` function
marktwtn added a commit to marktwtn/dcurl that referenced this issue Sep 23, 2018
Calculate the hash count mentioned in DLTcollab#47 in `doThePoW` function
and get it with `getHashCount` API.
@marktwtn
Copy link
Collaborator

hash rate = hash count / PoW execution time

There are two ways to get the PoW execution time.

  1. Subtract the time before and after the doThePoW function.
  2. Create an API like getHashCount to get the PoW execution time.
    The time would be slightly accurate since the time subtraction would be done in the doThePoW function.
    It excludes the function call, the PoW initialization part and other things. It focuses on the PoW execution time.

However, if the time unit is second, I think the PoW execution time may have no difference at all.

I prefer the method 2.
Is there any suggestion?

And I am thinking that the hash rate should be got with the API, too.

@furuame
Copy link
Member Author

furuame commented Sep 24, 2018

Method 2 might be better to get the time.

But I'm not sure do we really need "three" APIs to achieve the goal of this enhancement?

@marktwtn
Copy link
Collaborator

But I'm not sure do we really need "three" APIs to achieve the goal of this issue?

How about

  1. Create the getHashRate API and remove the others.

or

  1. Create an API like getPoWContext which returns the pointer of PoW-related information. A structure contains hash count and PoW execution time.

@furuame
Copy link
Member Author

furuame commented Sep 24, 2018

2. Create an API like `getPoWContext` which returns the pointer of PoW-related information. A structure contains `hash count` and `PoW execution time`.

Let's do this! Create an API getPoWInfo to record the time and hashcount.

@marktwtn
Copy link
Collaborator

Here are the modifications I am going to do:

The return pointer of getPoWInfo function should be type cast to get the hash count and PoW execution time value.

I assume the PoW information structure of each implementation is the same.
Then I would like to extract it to the header file named common.h.
The concept is the same as the common.h header file in tests directory.

@furuame
Copy link
Member Author

furuame commented Sep 24, 2018

The return pointer of getPoWInfo function should be type cast to get the hash count and PoW execution time value.

It's no need to return a pointer to a struct. Just return the value of the struct.

I assume the PoW information structure of each implementation is the same.
Then I would like to extract it to the header file named common.h.
The concept is the same as the common.h header file in tests directory.

Good idea. After merging this PR, I will refactor the code to follow the OOP style.

@furuame furuame closed this as completed Sep 24, 2018
@furuame furuame reopened this Sep 24, 2018
@marktwtn
Copy link
Collaborator

This is what I am going to do.

  1. Get the hash rate n times -> [ h1, h2, ......, hn ]

  2. Calculate the standard deviation -> sqrt{ [ (h1 - avg)^2 + ... + (hn - avg)^2 ] / n }

  3. Show the result:

average hash rate: XXX kH/sec
with 95% confidence interval and error value (2 * standard deviation).
  1. Show the hash rate with histogram.

@jserv is this what you expect to see?

@furuame
Copy link
Member Author

furuame commented Sep 29, 2018

This is what I am going to do.

1. Get the hash rate `n` times -> [ h`1`, h`2`, ......, h`n` ]

2. Calculate the `standard deviation` -> sqrt{ [ (h`1` - avg)^2 + ... + (h`n` - avg)^2 ] / n }

3. Show the result:
average hash rate: XXX kH/sec
with 95% confidence interval and error value (2 * standard deviation).
4. Show the hash rate with histogram.

The original goal of this issue is achieved.

Let's create another issue for these features.

Thanks for @marktwtn and @ajblane's contribution. Close.

@furuame furuame closed this as completed Sep 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants