[jira] [Comment Edited] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough

2024-02-14 Thread Vladislav Pyatkov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817350#comment-17817350
 ] 

Vladislav Pyatkov edited comment on IGNITE-21379 at 2/14/24 11:44 AM:
--

> Is this a single op latency in the table?
The total duration of 10M operations is shown in the table. One operation 
contains getting two read locks and two read unlocks. The test ran several 
times; this duration is after warmup.

> Test scenario description is not clear to me.
I attached the test.

> That is counter test?
The last row in the table is matched for the counter test.


was (Author: v.pyatkov):
> Is this a single op latency in the table?
The total duration of 10M operations is shown in the table. One operation 
contains getting two read locks and two read unlocks.

The test ran several times; this duration is after warmup.

> Test scenario description is not clear to me.

I attached the test.

> That is counter test?

The last row in the table is matched for the counter test.

> Investigate whether currently used busyLocks implementation is fast enough
> --
>
> Key: IGNITE-21379
> URL: https://issues.apache.org/jira/browse/IGNITE-21379
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3, performance
> Attachments: BusyLockTest.java
>
>
> h3. Motivation
> Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the 
> performance perspective. Let's compare current implementation with common RW 
> locks, CheckpointReadWriteLock, etc. Depending on the results it'll be 
> required either to use faster implementation or re-consider busyLock idea 
> itself because currently it brings significant performance drop. Given ticket 
> is only about initial step - busyLock performance investigation.
> h3. Definition of Done
>  * Prepare JMH benchmarks for busyLocks performance investigation.
>  * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc 
> in order to understand whether IgniteSpinBusyLock is fast enough.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough

2024-02-14 Thread Alexey Scherbakov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817332#comment-17817332
 ] 

Alexey Scherbakov edited comment on IGNITE-21379 at 2/14/24 11:06 AM:
--

> I compare two general approaches:

Is this a single op latency in the table ?

> This is a latency of 10_000_000 operations in millis

you mean total duration ?

Test scenario description is not clear to me.

That is counter test ?


was (Author: ascherbakov):
> I compare two general approaches:

Is this a single op latency in the table ?

> This is a latency of 10_000_000 operations in millis

you mean total duration ?

That is counter test ?

> Investigate whether currently used busyLocks implementation is fast enough
> --
>
> Key: IGNITE-21379
> URL: https://issues.apache.org/jira/browse/IGNITE-21379
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3, performance
>
> h3. Motivation
> Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the 
> performance perspective. Let's compare current implementation with common RW 
> locks, CheckpointReadWriteLock, etc. Depending on the results it'll be 
> required either to use faster implementation or re-consider busyLock idea 
> itself because currently it brings significant performance drop. Given ticket 
> is only about initial step - busyLock performance investigation.
> h3. Definition of Done
>  * Prepare JMH benchmarks for busyLocks performance investigation.
>  * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc 
> in order to understand whether IgniteSpinBusyLock is fast enough.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough

2024-02-14 Thread Alexey Scherbakov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817332#comment-17817332
 ] 

Alexey Scherbakov edited comment on IGNITE-21379 at 2/14/24 11:05 AM:
--

> I compare two general approaches:

Is this a single op latency in the table ?

> This is a latency of 10_000_000 operations in millis

you mean total duration ?

That is counter test ?


was (Author: ascherbakov):
> I compare two general approaches:

Is this a single op latency in the table ?

> This is a latency of 10_000_000 operations in millis

you mean total duration ?

> Investigate whether currently used busyLocks implementation is fast enough
> --
>
> Key: IGNITE-21379
> URL: https://issues.apache.org/jira/browse/IGNITE-21379
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3, performance
>
> h3. Motivation
> Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the 
> performance perspective. Let's compare current implementation with common RW 
> locks, CheckpointReadWriteLock, etc. Depending on the results it'll be 
> required either to use faster implementation or re-consider busyLock idea 
> itself because currently it brings significant performance drop. Given ticket 
> is only about initial step - busyLock performance investigation.
> h3. Definition of Done
>  * Prepare JMH benchmarks for busyLocks performance investigation.
>  * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc 
> in order to understand whether IgniteSpinBusyLock is fast enough.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (IGNITE-21379) Investigate whether currently used busyLocks implementation is fast enough

2024-02-14 Thread Vladislav Pyatkov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-21379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817309#comment-17817309
 ] 

Vladislav Pyatkov edited comment on IGNITE-21379 at 2/14/24 10:22 AM:
--

I compare two general approaches: based on IgniteSpinReadWriteLock and based on 
ReentrantReadWriteLock. The comparison runs in the dedicated test:
|RW lock test|406|
|Busy lock test|296|
|RW try lock test|358|
|Counter test|200|

This is a latency of 10_000_000 operations in millis. One operation contains 
two read lock and two read unlock operations.
There are the same results, but in multi-threaded environments:
|RW lock test|2 135|
|Busy lock test|2 377|
|RW try lock test|2 088|
|Counter test|1 476|

One operation acquires a lock in one thread, then takes a lock and releases it 
in another one, finally returning to the original thread and releasing the 
first read lock.
Also, I implement IgniteSpinBusyLock based on RW. I ran a load, and this 
implementation does not show a significant performance impact.


was (Author: v.pyatkov):
I compare two general approaches: based on IgniteSpinReadWriteLock and based on 
ReentrantReadWriteLock. The comparison runs in the dedicated test:
|RW lock test|406|
|Busy lock test|296|
|RW try lock test|358|
|Counter test|200|
This is a latency of 1000 operations in millis. One operation contains two read 
lock and two read unlock operations.
There are the same results, but in multi-threaded environments:
|RW lock test|2 135|
|Busy lock test|2 377|
|RW try lock test|2 088|
|Counter test|1 476|
One operation acquires a lock in one thread, then takes a lock and releases it 
in another one, finally returning to the original thread and releasing the 
first read lock.
Also, I implement IgniteSpinBusyLock based on RW. I ran a load, and this 
implementation does not show a significant performance impact.

> Investigate whether currently used busyLocks implementation is fast enough
> --
>
> Key: IGNITE-21379
> URL: https://issues.apache.org/jira/browse/IGNITE-21379
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3, performance
>
> h3. Motivation
> Seems that our busyLocks (IgniteSpinBusyLock) aren't good enough from the 
> performance perspective. Let's compare current implementation with common RW 
> locks, CheckpointReadWriteLock, etc. Depending on the results it'll be 
> required either to use faster implementation or re-consider busyLock idea 
> itself because currently it brings significant performance drop. Given ticket 
> is only about initial step - busyLock performance investigation.
> h3. Definition of Done
>  * Prepare JMH benchmarks for busyLocks performance investigation.
>  * Compare IgniteSpinBusyLock, common RW lock, CheckpointReadWriteLock, etc 
> in order to understand whether IgniteSpinBusyLock is fast enough.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)