[Ready] Fast Concurrent Deque Through Explicit Timestamping #127

EduardBlees · 2018-12-24T22:08:24Z

Implementation of [2014] Dodds,Haas,Kirsch Fast Concurrent Data-Structures Through Explicit Timestamping
Выполняли: Чирухин, Блеес (3304), Саклакова (3303)

EduardBlees · 2018-12-28T00:21:32Z

@eugenyk

pr3sto · 2018-12-28T00:28:01Z

cтресс тесты не собирались из-за того, что несколько раз пересобирал разными версиями gcc. пересобрал с нуля одной версией - все заработало

eugenyk · 2019-01-04T18:58:56Z

@EduardBlees - пока тесты не проходят для большей части архитектур

pr3sto · 2019-01-04T19:45:39Z

@eugenyk #6 не собирается ассемблерный код под архитектуру i386, это поправим.

#7 и #4 выдают ошибку Exception: Illegal. Причем ошибка не только в стресс, но и в юнит тестах. По ошибке абсолютно не понятно, чем она вызвана. Я могу только предположить: у нас ассемблерный код написан только для двух архитектур: ts_hardwaretimestamp.h. И тесты используют платформозависимый HardwareTimestamp класс. Можно тесты переписать на AtomicCounterTimestamp, который не зависит от платформы и компилятора.

khizmax · 2019-01-04T20:03:57Z

@eugenyk #6 не собирается ассемблерный код под архитектуру i386, это поправим.

FYI - здесь собран зоопарк реализаций rdtsc для разных архитектур:
https://github.com/google/benchmark/blob/v1.1.0/src/cycleclock.h#L56

eugenyk · 2019-01-05T09:53:53Z

Можно тесты переписать на AtomicCounterTimestamp, который не зависит от платформы и компилятора

@pr3sto по-хорошему надо бы в зависимости от платформы определять тип счётчика и для нереализованных действително использовать кроссплатформенный, через traits его передать в контейнер. Тут Максим меня может поправить

khizmax · 2019-01-05T16:10:50Z

по-хорошему надо бы в зависимости от платформы определять тип счётчика и для нереализованных действително использовать кроссплатформенный, через traits его передать в контейнер.
Да, передача через traits - хорошее решение, которое даст возможность использовать кастомные счетчики или сравнивать производительность при разных реализациях счетчиков

eugenyk · 2019-01-08T15:19:05Z

выдают ошибку Exception: Illegal

@pr3sto, это ошибка вызова некорректной инструкции, ниже прилагаю содержимое core dump, полученного после запуска модульного теста - в общем ваше предположение верно в части счётчика

Core was generated by `./unit-deque'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000046eb16 in void (anonymous namespace)::TSDeque::test<cds::container::TSDeque<int, cds::container::HardwareTimestamp, cds::opt::item_counter<cds::atomicity::item_counter>::pack<cds::container::tsdeque::traits> > >(cds::container::TSDeque<int, cds::container::HardwareTimestamp, cds::opt::item_counter<cds::atomicity::item_counter>::pack<cds::container::tsdeque::traits> >&) [clone .isra.183] [clone .constprop.228] ()
(gdb) bt
#0  0x000000000046eb16 in void (anonymous namespace)::TSDeque::test<cds::container::TSDeque<int, cds::container::HardwareTimestamp, cds::opt::item_counter<cds::atomicity::item_counter>::pack<cds::container::tsdeque::traits> > >(cds::container::TSDeque<int, cds::container::HardwareTimestamp, cds::opt::item_counter<cds::atomicity::item_counter>::pack<cds::container::tsdeque::traits> >&) [clone .isra.183] [clone .constprop.228] ()
#1  0x000000000046fe09 in (anonymous namespace)::TSDeque_hardware_timestamping_Test::TestBody() ()
#2  0x000000000049a263 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ()
#3  0x0000000000491a64 in testing::Test::Run() [clone .part.368] ()
#4  0x0000000000491d1d in testing::TestInfo::Run() [clone .part.369] ()
#5  0x0000000000491f05 in testing::TestCase::Run() [clone .part.370] ()
#6  0x00000000004943b1 in testing::internal::UnitTestImpl::RunAllTests() [clone .part.371] [clone .constprop.426] ()
#7  0x00000000004947c1 in testing::UnitTest::Run() ()
#8  0x000000000043e7e6 in main ()

pr3sto · 2019-01-16T20:56:04Z

@eugenyk по этой ссылке есть только инструкция rdtsc. у нас используются: rdtsc и rdtscp. поэтому для других архитектур и компиляторов не добавил реализацию (для i386 поправил).
тесты платформозависимых версий теперь только для архитектур, для которых есть реализация:

libcds/test/unit/deque/ts_deque.cpp

Line 80 in d5ece4c

    
           #if defined(CDS_ts_hardwaretimestamp_hwptime_defined) && defined(CDS_ts_hardwaretimestamp_hwtime_defined)

eugenyk · 2019-01-17T07:01:04Z

@pr3sto, тест всё равно не проходит под i386

pr3sto · 2019-01-17T08:14:04Z

@eugenyk я не вижу другого выхода для нас, кроме как удалить поддержку i386. У нас нет возможности тестировать и отлаживать код для этой платформы, а работа вслепую, как видим, результатов не приносит. Тем более, что у нас написан платформонезависимый atomiccountertimestamp, который работает абсолютно также, да и от алгоритма взятия временных меток работа дека никак не зависит

eugenyk · 2019-01-17T20:26:40Z

@eugenyk я не вижу другого выхода для нас, кроме как удалить поддержку i386. У нас нет возможности тестировать и отлаживать код для этой платформы, а работа вслепую, как видим, результатов не приносит. Тем более, что у нас написан платформонезависимый atomiccountertimestamp, который работает абсолютно также, да и от алгоритма взятия временных меток работа дека никак не зависит

Если вы попросите доступ - у вас будет возможность отлаживать код и под этой архитектурой, это не проблема. В любом случае, поддерживаться должны все архитектуры, которые сейчас поддерживаются библиотекой - пусть и через платформонезависмый счётчик будет поддерживаться i386, должно собираться и работать

pr3sto · 2019-01-18T19:26:06Z

@eugenyk последняя попытка пофиксить HardwareTimestamp. Скорее всего дело не в архитектуре, а в том, что у процессора просто нет инструкции rdtscp (по заявлениям авторов статьи, она есть на всех современных x86 процессорах). Добавил проверку (как описано тут)

eugenyk · 2019-01-19T22:30:02Z

cds/compiler/gcc/x86/ts_hardwaretimestamp.h

@@ -22,6 +23,15 @@ namespace cds { namespace tshardwaretimestamp {
            return ret;
        }

+        static inline int has_rdtscp()


It's quit strange to have "has_..." function returning logically boolean value with int signature

eugenyk · 2019-01-19T22:31:24Z

test/unit/deque/ts_deque.cpp

-
-        deque_type dq(1, 0);
-        test( dq );
+        if (cds::tshardwaretimestamp::platform::has_rdtscp() == 1)


You check rdtscp existence only in unit tests, but what should do developers who will use your API, the same? It should be transparent for users

Проблема в том, что, как я понял, нет возможности проверить наличие rdtscp во время компиляции. Эту проверку необходимо делать во время выполнения программы. Я не знаю, как сделать это прозрачным для пользователей. Подскажите?

I think it's possible to determine it through cpuid like this

Не совсем понимаю, что вы имеете ввиду. У нас и так проверка наличия rdtscp происходит с помощью cpuid. И функция cds::tshardwaretimestamp::platform::has_rdtscp() возвращает 1, если процессор поддерживает rdtscp.

Всё верно, я сначала ответил на вопрос, а потом посмотрел реализацию

pr3sto and others added 27 commits December 4, 2018 19:23

Init ts_deque

9d2f2af

init deque_buffer

4e31819

Merge branch 'develop' of github.com:EduardBlees/libcds into develop

fff2b21

init timestamp

c20d3c3

add Item and initialize method

86ff17d

try remove left impl

c7c96bf

threadcontext

9f6d53e

implement insert_right

92efc84

timestamp hardware

a136c71

insert_left implementation

0dcef53

try remove right impl

7fdf05c

timestamp hardware interval

ab723b5

implement ts_deque

b2a8b91

methods for fixing aba problem added

0178ecb

try remove fixes, use ABA functions

2bb8dce

fixes insert methods

06542ae

timestamp atomic counter

09052d7

assign threadcontext to each thread

546b8b3

code format

0e4fd30

add clear, size and empty methods

0181934

prepare to pull request

c4ecac4

add unit tests

eb5e9f6

move asm code to compiler folder

a5ecc16

fix

72f5ef0

add copyright note

ac02558

fix emptyness check, thread_id

430297f

stress tests added

ff40ba7

EduardBlees changed the title ~~Fast Concurrent Deque Through Explicit Timestamping~~ [Ready] Fast Concurrent Deque Through Explicit Timestamping Dec 28, 2018

pr3sto added 2 commits January 16, 2019 23:03

fix tests for different architectures

5ee65b5

fix rdtsc and rdtscp for i386 arch

d5ece4c

add rdtscp check

2410e88

eugenyk suggested changes Jan 19, 2019

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Ready] Fast Concurrent Deque Through Explicit Timestamping #127

[Ready] Fast Concurrent Deque Through Explicit Timestamping #127

EduardBlees commented Dec 24, 2018

EduardBlees commented Dec 28, 2018

pr3sto commented Dec 28, 2018

eugenyk commented Jan 4, 2019

pr3sto commented Jan 4, 2019

khizmax commented Jan 4, 2019

eugenyk commented Jan 5, 2019 •

edited

khizmax commented Jan 5, 2019

eugenyk commented Jan 8, 2019

pr3sto commented Jan 16, 2019

eugenyk commented Jan 17, 2019

pr3sto commented Jan 17, 2019

eugenyk commented Jan 17, 2019 •

edited

pr3sto commented Jan 18, 2019

eugenyk Jan 19, 2019

eugenyk Jan 19, 2019

pr3sto Jan 20, 2019

eugenyk Jan 29, 2019

pr3sto Jan 30, 2019

eugenyk Jan 31, 2019

[Ready] Fast Concurrent Deque Through Explicit Timestamping #127

Are you sure you want to change the base?

[Ready] Fast Concurrent Deque Through Explicit Timestamping #127

Conversation

EduardBlees commented Dec 24, 2018

EduardBlees commented Dec 28, 2018

pr3sto commented Dec 28, 2018

eugenyk commented Jan 4, 2019

pr3sto commented Jan 4, 2019

khizmax commented Jan 4, 2019

eugenyk commented Jan 5, 2019 • edited

khizmax commented Jan 5, 2019

eugenyk commented Jan 8, 2019

pr3sto commented Jan 16, 2019

eugenyk commented Jan 17, 2019

pr3sto commented Jan 17, 2019

eugenyk commented Jan 17, 2019 • edited

pr3sto commented Jan 18, 2019

eugenyk Jan 19, 2019

Choose a reason for hiding this comment

eugenyk Jan 19, 2019

Choose a reason for hiding this comment

pr3sto Jan 20, 2019

Choose a reason for hiding this comment

eugenyk Jan 29, 2019

Choose a reason for hiding this comment

pr3sto Jan 30, 2019

Choose a reason for hiding this comment

eugenyk Jan 31, 2019

Choose a reason for hiding this comment

eugenyk commented Jan 5, 2019 •

edited

eugenyk commented Jan 17, 2019 •

edited