Программирование[11]

16 байт еб твою мать жалеют

Ребят вы в датацентр сходите на экскурсию, ощнакомьтесь с современными вычислительными мощностями

Там в стойках плашки по 10 терабайт уже стоят лет 10

Ваше гавно на си плюс плюс будто хуй резиновый в ведре

ural1qqq написал 8 часов назад:

16 байт еб твою мать жалеют

 

Ребят вы в датацентр сходите на экскурсию, ощнакомьтесь с современными вычислительными мощностями

Там в стойках плашки по 10 терабайт уже стоят лет 10

Ваше гавно на си плюс плюс будто хуй резиновый в ведре

Лично купишь норм компики всем нашим юзерам?

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

Index написал 19 часов назад:

Ебать вы тут насрали ходя вокруг да около. Сейчас вам батя все объяснит. 

 

Почему сложно тестировать многопоточный код:

Допустим у вас есть тред(бизнес-задача) А у которого есть состояния перед локом->лок->отдал лок и тред (бизнес-задача) Б с таким же состоянием (3 состояния)

Получается чтобы протестировать все поведение вам нужно в рамках теста сделать 3х3 (9 кейсов сочетаний состояний) и это только в статике. А есть ещё динамика, когда начинают в одном состоянии но другой прошел чуть быстрее а потом замедлился.

А когда число состояний увеличивается количество тест кейсов растет экспоненциально.

 

Опять же можно прибегнуть к виртуальному времени, как Vova упомянул, но это если у каждого из тредов есть возможность собственно то самое виртуальное время подсунуть. Есть точки где треды обращаются к Clock за временем.

 

Если же там чисто CPU не ожидающий, не блокирующийся код, то виртуальное время можно засунуть в жопу.

 

А когда в бизнес-логику напиханы точки входа для тестов. Типо давай сюда засунем Thread.sleep(clock.nanos(1)) и будем мокать клок в тестах))))0 то от такого кода хочется помыться 

 

P.S. Даже то же виртуальное время в разы лучше работает когда пишешь многопоточный код конкарент агностик вещами типо реактивщины/корутинщины

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/-delay-controller/advance-time-by.html

https://nexocode.com/blog/posts/fast-reactor-tests-with-virtual-time/

 

Парочка поправочек

Index написал 19 часов назад:

Получается чтобы протестировать все поведение вам нужно в рамках теста сделать 3х3 (9 кейсов сочетаний состояний) и это только в статике. А есть ещё динамика, когда начинают в одном состоянии но другой прошел чуть быстрее а потом замедлился.

А когда число состояний увеличивается количество тест кейсов растет экспоненциально.

Тест пишется не с целью проверить все возможные случаи а с целью уменишься вероятность бага. Ты оцениваешь что и где стоит протестировать так чтобы мат ожидание пользы перевешивало потраченное время.

Index написал 19 часов назад:

А когда в бизнес-логику напиханы точки входа для тестов. Типо давай сюда засунем Thread.sleep(clock.nanos(1)) и будем мокать клок в тестах))))0 то от такого кода хочется помыться 

Какие блять еще точки входа? В продакшен коде должно быть примерно ноль кода для тестов. Для этого есть Mock, Stub, Spy...

Vova написал 1 час назад:

Опять же можно прибегнуть к виртуальному времени, как Vova упомянул, но это если у каждого из тредов есть возможность собственно то самое виртуальное время подсунуть. Есть точки где треды обращаются к Clock за временем.

 

Если же там чисто CPU не ожидающий, не блокирующийся код, то виртуальное время можно засунуть в жопу.

 

А когда в бизнес-логику напиханы точки входа для тестов. Типо давай сюда засунем Thread.sleep(clock.nanos(1)) и будем мокать клок в тестах))))0 то от такого кода хочется помыться 

Вот тебе пример теста. У меня заняло пять минут написать. Теперь напиши имплементацию - посмотрим сколько займет.

Test:

  clock.mock()

  a_time = 8

  b_time = 2

  c_time = 5

  C_starts_after_A_and_B_finished(a: ()=> clock.sleep(a_time), b: ()=> clock.sleep(b_time), c: ()=> clock.sleep(c_time))

  clock.tick(max(a_time,b_time) + c_time + 1)

  exception = false

  try

      C_starts_after_A_and_B_finished(a: ()=> clock.sleep(a_time), b: ()=> clock.sleep(b_time), c: ()=> clock.sleep(c_time))

      clock.tick(max(a_time,b_time) + c_time - 1)

  catch

     exception = true

  assert(exception)

Grohuf написал 51 минуту назад:

ural1qqq написал 9 часов назад:

16 байт еб твою мать жалеют

 

Ребят вы в датацентр сходите на экскурсию, ощнакомьтесь с современными вычислительными мощностями

Там в стойках плашки по 10 терабайт уже стоят лет 10

Ваше гавно на си плюс плюс будто хуй резиновый в ведре

Лично купишь норм компики всем нашим юзерам?

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

да я угараю расслабься ботан

я понимаю все это, но тут надо тоже понимать что 16 гб оперативной памяти это минимальный стандарт в 2025 году будет

Drakonian написал 9 часов назад:

джаст как обычно разъебал по фактам и че только его хейтят постоянно

По каким фактам напомни?

По этим?

Just.Doit написал 31.05.2024 в 09:13:

в канкаренси проблема в том что невозможно протестировать.

Just.Doit написал 02.06.2024 в 00:45:

Vova написал 01.06.2024 в 19:30:

Вы че умственно неполноценные? Под потокобезопасность точно также пишут тесты

 

https://jasmine.github.io/api/2.6/Clock.html

я писал код с подобными моками

он позволяет засетапить некоторые инварианты и проверить их более менее достоверно

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

Just.Doit написал 02.06.2024 в 03:02:

Vova написал 02.06.2024 в 01:59:

Just.Doit написал 02.06.2024 в 00:45:

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

 

Так так так

 

Ты намекаешь что с тестами однопоточных программ как-то по другому?

 

на высоком уровне абстракции - нет

но в канкаренси гораздо выше вероятность рандомных срабатываний и гораздо больше инвариантов, в этом плане оно сильно отличается от синхронного последовательного кода, где огромное количество инвариантов невозможны из-за гарантий последовательного выполнения и ты в целом можешь перебрать инварианты и протестировать их без особых сюрпризов и без особых навыков

- конкареннси невозможно протестировать

- а этот мок времени тогда нахуй

- да я писал тесты с моком времени в конкарренси (зачем если "невозможно протестировать") но они ничего не гарантировали железно

- в однопотоке гарантируют?

- нигде не гарантируют желещно

- ???

Я блять промолчу какой бред он несет про термины значения которая не понимает типо инварианты. Это просто полный тотальный пиздец и бред. Какие еще нахуй инвариады??? Для инвариантов есть assert() внутри продакшен кода который либо логает тебе "critical_error" не краша код либо крашит код например с exception.

ural1qqq написал 12 минут назад:

Grohuf написал 1 час назад:

ural1qqq написал 9 часов назад:

16 байт еб твою мать жалеют

 

Ребят вы в датацентр сходите на экскурсию, ощнакомьтесь с современными вычислительными мощностями

Там в стойках плашки по 10 терабайт уже стоят лет 10

Ваше гавно на си плюс плюс будто хуй резиновый в ведре

Лично купишь норм компики всем нашим юзерам?

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

да я угараю расслабься ботан

 

я понимаю все это, но тут надо тоже понимать что 16 гб оперативной памяти это минимальный стандарт в 2025 году будет

мы до сих пор поддерживаем 32 битную версию браузера 

Но, конечно, изменение железа юзеров вносит свои коррективы. Например, раньше мультипоточное обращение к диску только вредило. С ссд все наоборот

Grohuf написал 13 часов назад:

Давай я напомню основные тезисы:

1) Тестировать многопоточные ошибки сложно. GR: Ахаха, вы просто не умеете писать тесты <далее приводит пример с тестированием имплементации>.

Ты в дерьмо сел.

Напоминаю как все было в реальности. Вы доказывали что их невозможно протестировать, а я утверждал что возможно, но тяжело, и дорого.  

GoldRobot написал 01.06.2024 в 21:10:

Just.Doit написал 31.05.2024 в 23:13:

в канкаренси проблема в том что невозможно протестировать.

А что мешает? Возможно.

Просто тяжело и дорого покрывать.

Поэтому, думаю все согласны считать значит что у меня получилось вам объяснить реальное положение дел. Приятно было пообщаться, много нового узнал! 

Чел, получается ты мне мозги столько страниц ебал, потому что не осилил "основной тезис" дуита нормально прочитать?

GoldRobot написал 35 минут назад:

Поэтому, думаю все согласны считать значит что у меня получилось вам объяснить реальное положение дел. Приятно было пообщаться, много нового узнал! 

 

Чел, получается ты мне мозги столько страниц ебал, потому что не осилил "основной тезис" дуита нормально прочитать?

Клоун так и не осилил простые примеры, где нужны барьеры памяти и все думает, что многопоточный код пишется через захваты мьютекса.

А еще считает, что писать тест, мокая мьютексы - это ок.

Клоуна в зеркале увидишь чучело. Ты уже не первый раз влетаешь, несешь хуйню, а потом выясняется что ты вообще понятия даже не имел о чем спор.

Напомню, как пишутся тесты от GR:

Цитата

Для этого достаточно и нужно мокать и абстрагировать. Тебе нужно придумать логику работы, и проверить то что ты эту логику заимплементил как ожидалось. Это и является предметом теста.

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

локи - часть имплементации объектов connection и cache и при использовании этих объектов мы не должны проверять их имплементацию (они для нас черные ящики). Мы же не проверяем, когда выделяем память в куче, что там спинлок захватывается. Однако GR на полном серьезе предлагает так тестировать. Когда нормальный юнит-тест - это когда объект считается черным ящиком и мокаются его входы и выходы и проверяется, что когда мы подаем что-то на вход, то на выходе получаем ожидаемые значения (при необходимости - в нужном порядке).

Некоторые многопоточные случаи можно провеять, подавая данные на вход в нужном порядке, но обычно в случае локов нужно минимизировать места, где их нужно использовать, внимательно их просмотреть (код с локами должен быть максимально простым). И стараться не использовать локи в большей части кода.

Если класс с локами не удалось сделать простым, а локи в нем необходимы по каким-то причинам (производительность, например), то тогда надо делать для него что-то вроде многопоточных фаззинг тестов.

Можешь не выебываться, ты обосрался в самом начале.

Но ты круто тему переводишь.

Абстракция и разделение зоны ответственности, чтобы не тестить мютекс, а протестировать логику многопотока, это - сложна. Наш предел хуячить везде умный-указатель-но-с-ручным-управлением.

Но опустим, считай как хочешь, я пытался объяснить, но твой уровень мы уже знаем. Влететь не читая, и начать срать, устраивая клоунаду чтобы потом поорать "вы не понимаете, я тролил, на самом деле в яндексе работаю".

Лучше давай оценим тесты за твоим авторством:

Grohuf написал 21 час назад:

 

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

 

Grohuf написал 11 минут назад:

Некоторые многопоточные случаи можно провеять, подавая данные на вход в нужном порядке, но обычно в случае локов нужно минимизировать места, где их нужно использовать, внимательно их просмотреть (код с локами должен быть максимально простым). И стараться не использовать локи в большей части кода.

Ебать откровение. Которое я еще в первых пару комментов написал как причину того почему я, персонально, этого не делаю.

Тьфу блять, ну грохув, ну это уже тролинг какой-то не иначе.

GoldRobot написал 32 минуты назад:

Абстракция и разделение зоны ответственности, чтобы не тестить мютекс, а протестировать логику многопотока, это - сложна. Наш предел хуячить везде умный-указатель-но-с-ручным-управлением.

Каким ручным управлением? Хули ты такой тупой? Там все до предела автоматизировано и везде поставлена защита от дурака. Именно поэтому была допущена такая ошибка. Запостить задачу на другой поток в хромике - это как чихнуть. Это рядовая рутинная работа, где ошибиться сложно из-за той самой защиты. Однако чел умудрился, заюзав посттаск в конструкторе, от которой, как оказалось, тогда защиты не было (хз как сейчас, вряд ли есть). Фишка тут в том, что такую ошибку хуй найдешь и удалось поймать только из-за особенности работы планирования потоков (кажись на unix системах).

Для того, чтобы сделать что-то потенциально опасное, нужно при создании задачи явно указать "да, я знаю, что это опасно, но я подумал и знаю, тут будет все ок". Например, если создаешь таску с сырым указателем на объект, то его надо обернуть в base::Unretained.

Если ты не работал с нормальными абстракциями тасков и таскраннеров - это твой пробел. Не надо пытаться делать вид, что все это хуйня и достаточно знания стандартной библиотеки.

GoldRobot написал 32 минуты назад:

Лучше давай оценим тесты за твоим авторством:

Ну я уже понял, что ты настолько тупой, что не догнал, что я просто максимально упростил предлагаемый тобой тест. Ты предлагал написать в коде функции лок у другого класса. Вызвать функцию у другого класса, сделать анлок у другого класса. А потом в тесте нахуячить проверку, что вызван лок у другого класса, вызвана рабочая функция у другого класса, вызван анлок у другого класса. Я написал тоже самое. Присвоил единицу переменную у другого класса и проверил что присвоена единица. Такой же идиотизм, что предлагаешь ты. Но ты настолько тупой, что ты не можешь допереть, что я просто довел до абсурда твою технику тестирования.

GoldRobot написал 32 минуты назад:

Ебать откровение. Которое я еще в первых пару комментов написал как причину того почему я, персонально, этого не делаю.

Мы уже поняли, как ты все делаешь. Ты сам это написал.

Вы о хуйне спорите. В этом разговоре нет денег. Разговор без денег это хуйня.

Чем барьер отличается от лока мьютекса?
https://godbolt.org/z/7K1r7nf9T
Мьютекс это lock inc; lock dec;
барьер это lock or;

Grohuf написал 19 часов назад:

Ага. Всего-то вставляет барьер памяти (не давая оптимизировать код), синхронизирует кэши в разных ядрах и не дает обращаться к ячейке памяти другим ядрам. "Почти" бесплатно.

(про атомик)

вопрос в зал - есть ли материал, где было бы расписано, как оно работает на нижнем уровне - что делает система, что происходит с железом

Olololnet said 5 minutes ago:

Grohuf said 19 hours ago:

Ага. Всего-то вставляет барьер памяти (не давая оптимизировать код), синхронизирует кэши в разных ядрах и не дает обращаться к ячейке памяти другим ядрам. "Почти" бесплатно.

(про атомик)

 

вопрос в зал - есть ли материал, где было бы расписано, как оно работает на нижнем уровне - что делает система, что происходит с железом

интел мануал.
А так вот
https://stackoverflow.com/questions/50323347/how-many-memory-barriers-instructions-does-an-x86-cpu-have

thousand cursed enemies написал 9 минут назад:

Вы о хуйне спорите. В этом разговоре нет денег. Разговор без денег это хуйня.

Чем барьер отличается от лока мьютекса?
https://godbolt.org/z/7K1r7nf9T
Мьютекс это lock inc; lock dec;
барьер это lock or;

атомарные операции вставляют барьер памяти. Ничего удивительного.

Мьютекс - это не lock inc.

lock inc - это атомарный инкремент. На Windows называется InterlockedIncrement.

Типичный мьютекс, доступный только в одном процессе - это спинлок (который делается на атомарных операциях) + системный мьютекс, если спинлок крутится слишком долго (в Windows эта хуйня называется критической секцией). Уход в ожидание на мьютексе, предоставляемым ядром, - очень дорогая операция. Но если все ограничивается ожиданием в спинлоке, то ожидание на критической секции достаточно не дорого.

Olololnet написал 41 минуту назад:

Grohuf написал 19 часов назад:

Ага. Всего-то вставляет барьер памяти (не давая оптимизировать код), синхронизирует кэши в разных ядрах и не дает обращаться к ячейке памяти другим ядрам. "Почти" бесплатно.

(про атомик)

 

вопрос в зал - есть ли материал, где было бы расписано, как оно работает на нижнем уровне - что делает система, что происходит с железом

хз, сам бы почитал. Тема с барьерами памяти и атомиками довольно сложная. Но как-то забиваю, так как в работе не нужно.

Grohuf написал 2 часа назад:

Там все до предела автоматизировано

Ага, вижу. AddRef, RemoveRef, Release.

А если тег поставить, чтоб считало с 1, то ты споткнешься на local_ptr.

Grohuf написал 2 часа назад:

Ну я уже понял, что ты настолько тупой, что не догнал, что я просто максимально упростил предлагаемый тобой тест. Ты предлагал написать в коде функции лок у другого класса. Вызвать функцию у другого класса, сделать анлок у другого класса. А потом в тесте нахуячить проверку, что вызван лок у другого класса, вызвана рабочая функция у другого класса, вызван анлок у другого класса. Я написал тоже самое. Присвоил единицу переменную у другого класса и проверил что присвоена единица. Такой же идиотизм, что предлагаешь ты. 

Во, об этом и речь. Ты в меру своего скудного разумения мокинга и тестов, собственно, и написал тест. Как умеешь, как знаешь.

Такую хуйню можно изобразить только в страшном сне.

Что нужно было сделать, какая библотека для мокингов это позволит сделать красиво, я уже сказал.

Флажки он блять тестит. Произошел мем "я не тупой я просто тролю".

Olololnet написал 1 час назад:

вопрос в зал - есть ли материал, где было бы расписано, как оно работает на нижнем уровне - что делает система, что происходит с железом

Да в целом гроха все и написал.

Цпу читает память через кеш, как прослойку. Пишет тоже через нее.

При чтении собственно кешируется адресс из памяти, очевидно. Но при этом еще кешируется некоторый объем данных вокруг конкретно нужного адресса памяти. Этот объем чето около 100 байт, он и называется кеш линией.

Раз это кеш, то конкретная ячейка из RAM в кеше может быть только в одном виде (твоя переменная условно).

Далее, этот кеш делится между ядрами. Ядра пишут в память через кеши обратно, с каким-то там размером пайплайна на запись. Соответственно с одной кеш линией в общем случае может работать множество ядер одновременно.

В случае атомарных операций вся линия лочится к хуям (читать с нее может только одно ядро), ожидается пока то что уже там на молотили ядра и хотели записать в кеш запишется, потом из нее читает одно ядро, выполняет работу пишет анлокает.

Потому атомик может подзадушить вообще все что на одном процессе с ней находится. В теории. На деле похуй, плюс похуй, если ты не начинаешь атомики за место интов юзать (я видел такое говно). Потому что кеш линий дохуя, и наврятли все твои 10 потоков в одной кеш линии зависнут, если не захотят одновременно с атомиком поработать. Хотя я не знаю как согласованность кешей работает (L1, L2), но они быстрые пиздец, сами понимаете. Потому я и говорил что в однопотоке похуй+похуй если ты там чутка лишними атомиками обмазался, и умный указатель у тебя по доброте душевной атомик, а не просто инт.

Далее, барьером называется потому что все что до атомика происходит в твоем коде выполнится.

Написал ты

y ++;

x ++;

z ++;

atomic_store(z);

Все эти y,x,z компилятор может перетасовать как хочет, в каком хочет порядке. Пайплайн у процессора так же. То как в коде описано, не факт что будет так же как выполнится.

Однако, когда дойдет до атомика исполнения, это значит что все что выше выполнилось однозначно. И так же у соседнего потока с этим же атомиком, у которого вообще другие не связанные с синхронизациями функции выполнялись до атомика. Даже если атомик "свободен". Вот тебе и "барьер". С помощью таких барьеров можно сделать машинарию и обеспечить трейдсейф работу с "обычными" типами, даже не используя явный мутекст.

Но на самом деле этих барьеров больше одного, и лок кеш линий/записей может быть разный, а есть его варации. std::memory_order. Чето типа std::shared_lock/std::unique_lock. Можно себя этим наебнуть очень легко.

Только лично я ебал в этих сортах разбираться, это выдрочь либо для тех кому прям интересно, либо для очень узких мест в дорогом софте. Браузеры тормозят не из-за этого, а у хрома фризит сайдбар с всего пару к закладк не потому что там кто-то вписал атомик лишний. Как и то что вам пара смс пришла с задержкой тоже не от того что там голдробот фаелсистем заюзал. Потому я придерживаюсь мнения что лучше зажать мутех заместо ебли с фенсингом, за исключением случаев когда это реально оправдано.

UPD: Вопрос конечно где я напиздел и помню не правильно. Яб тоже почитал какой научпоп на эту тему с удовольствием.

да нет литературы, никто в душе не ебет, как оно работает, а те кто ебет, сами работают в интеле/амд

В интел мануале немало инфы если нужно больше
бенчмаркать можно. как Вагнер фог
https://agner.org/optimize/instruction_tables.pdf

Instructions with a LOCK prefix have a long latency that depends on cache organization and possibly RAM speed. If there are multiple processors or cores or direct memory access (DMA) devices, then all locked instructions will lock a cache line for exclusive access, which may involve RAM access. A LOCK prefix typically costs more than a hundred clock cycles, even on single-processor systems. This also applies to the XCHG instruction with a memory operand.