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

Implement the getHashTimes() API #72

Closed
wants to merge 1 commit into from

Conversation

marktwtn
Copy link
Collaborator

Obtain the hash times mentioned in #47 with API.

The FPGA part will be implemented by @ajblane .

Obtain the hash times mentioned in DLTcollab#47 with API.
@@ -41,6 +41,7 @@ typedef struct {
cl_ulong max_memory;
size_t num_work_group;
KernelInfo kernel_info;
uint64_t hashTimes;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid camel case.

@@ -64,3 +64,8 @@ int8_t *getPoWResult(ImplContext *impl_ctx, void *pow_ctx)
{
return impl_ctx->getPoWResult(pow_ctx);
}

uint64_t getHashTimes(ImplContext *impl_ctx, void *pow_ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need implementation-specific counter?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a counter in each pow_ctx.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll set a counter named hash_count rather than hash_times to avoid misunderstanding in each pow_ctx.

And I'm not sure about the meaning of @jserv 's question.

Copy link
Member

@jserv jserv Sep 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see the methods to minimize changes against existing interface. We might split the functions of given interface into two fields:

  • ops (operations)
  • info (information)

That is, PoW takes ops after initialization, which expects info.

@@ -681,6 +681,22 @@ static int8_t *PoWAVX_getPoWResult(void *pow_ctx)
return ret;
}

static uint64_t PoWAVX_getHashTimes(void *pow_ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are various lines in common among PoWAVX_getHashTimes, PoWC_getHashTimes, etc. I don't think we really need that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marktwtn You can calculate the HashTimes inside the end of doThePoW function and store it. Then we can just use the interface get the HashTimes rather than duplicate getHashTimes functions in each implementation.

uint64_t getHashTimes(void *pow_ctx)
{
    return pow_ctx->hashtimes;
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the code would look like this

uint64_t getHashTimes(void *pow_ctx)
{
    return ((PoW_SSE_Context *) pow_ctx)->hashtimes;
}

and can not be used in other implementation.

I guess the getHashTimes function should remain the same and change the PoW[Impl]_getHashTimes function like this:

static uint64_t PoW[Impl]_getHashTimes(void *pow_ctx)
{
    return ((PoW_[Impl]_Context *) pow_ctx)->hashtimes;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right.

@@ -681,6 +681,22 @@ static int8_t *PoWAVX_getPoWResult(void *pow_ctx)
return ret;
}

static uint64_t PoWAVX_getHashTimes(void *pow_ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marktwtn You can calculate the HashTimes inside the end of doThePoW function and store it. Then we can just use the interface get the HashTimes rather than duplicate getHashTimes functions in each implementation.

uint64_t getHashTimes(void *pow_ctx)
{
    return pow_ctx->hashtimes;
}

@@ -64,3 +64,8 @@ int8_t *getPoWResult(ImplContext *impl_ctx, void *pow_ctx)
{
return impl_ctx->getPoWResult(pow_ctx);
}

uint64_t getHashTimes(ImplContext *impl_ctx, void *pow_ctx)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a counter in each pow_ctx.


for (int i = 0; i < ctx->num_threads; i++) {
if (pitem[i].ret >= 0 )
count += (uint64_t)pitem[i].ret;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please follow the coding style, thanks.

count += (uint64_t) pitem[i].ret;

if (pitem[i].ret >= 0 )
count += (uint64_t)pitem[i].ret;
else
count += (uint64_t)(-(pitem[i].ret) + 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant parentheses

@furuame
Copy link
Member

furuame commented Sep 20, 2018

getHashTimes() shoulde also be included in the test case.

@marktwtn
Copy link
Collaborator Author

getHashTimes() shoulde also be included in the test case.

Yes, it would be included in the other future pull request of getting the hash rate.

@marktwtn
Copy link
Collaborator Author

I rewrite the code in #73 without implementing getHashTimes() API.

If there is no problem, I will close this pull request without merging.

@jserv
Copy link
Member

jserv commented Sep 21, 2018

I rewrite the code in #73 without implementing getHashTimes() API.
If there is no problem, I will close this pull request without merging.

Agree.

@marktwtn marktwtn closed this Sep 21, 2018
@marktwtn marktwtn deleted the hash-times-api branch September 21, 2018 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants