0: Друзья, всем привет. Меня зовут Антон Сысоев. И я буду помогать сегодня своему другу рассказать очень интересную тему. Зовут его Александр Емеленко. Он тут оказывает

1: Много лет скрывал от меня, что он эмбеде. Боже мой, Саша, как, как ты мог вообще? Вот. И, собственно, доклад будет о многопоточке. И у меня такой

2: Вопрос вот росы, да, ты там занимался какой-то вообще вот этой вот мелочёвкой всякой там, да, покрупнее мелочёвкой, ещё покрупней мелочёвкой. Так вот, ртос и наши большие операционки, они сильно вообще отличаются.

3: В плане многопоточки. Спасибо, Антон, за этот вопрос. Конечно, мы его не готовили. На самом деле, ртос очень сильно отличаются от больших операционок. Конкретно то, над чем я работал, это была ртос для Самолётов. И, как вы понимаете, если

4: Что-то пошло не так в операционной системе, в самолёте никто её не перезапустит. Ну как-то уже на земле, видимо будут смотреть, что произошло. Поэтому ртос для Самолётов, в отличие от обычных Тосов, ещё более жёсткие, там хартер алтай.

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

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

7: Ждём твоего звёздного выступления. Спасибо. Спасибо. Поехали.

8: Добрый день, уже почти вечер. Меня зовут Александр Емеленко. Сегодня мы будем с вами рассказывать, немножечко углубляться в такую тему, как многопоточное программирование. Мой эксперт уже немножко рассказал мне, но я хочу немножечко, как бы

9: Позитивного сказать, я не только занимался эмбеде и реалтайм, операционными системами, но также занимался бинарной трансляцией для процессоров intel собственно говоря, в интеле и работал 5 лет, отдал huawei и memory management, частью для виртуальной машины в open.

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

11: На её этапы это реализация кода, поиск ошибок, борьба с операционной системой и особенности мобильных процессоров. Дальше немножечко расскажу, что в итоге получилось. И начнём по хардкору опускаться на более низкие уровни. Я расскажу

12: Скажу, что мы делаем в spectra, насколько сильно на самом деле то, что мы делаем близко к тому, что я буду сегодня рассказывать про huawei, и в конце сделаем вывод немножко провокационный, но вы все увидите, начнём с задачи, в 1 очередь, когда мы говорим.

13: Про huawei многие из вас понимают, что huawei представляет из собой компанию, которая занимается в том числе разработкой телефонов от и до от железа до соответственно операционной системы. Если пользователь внезапно начинает работать с телефоном, то он прежде всего оценивает свою

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

15: Виртуальная машина это то та прослойка, которая находится между операционной системой и приложением. Если виртуальная машина внезапно становится тяжеловесной, начинает лагать, то пользователь это видит. Сначала он думает, что

16: Виноваты разработчики приложения, когда это происходит не только с 1 приложением, а с десятком. Он думает, что все разработчики huawei плохие люди выбрасывают телефон и уходит к другому вендору наверное не хочется иметь такой сценарий со всеми людьми.

17: Которые пользуются нашей компанией, пользовались нашей компанией, в которой я работал. Поэтому хочется сделать так, чтобы виртуальная машина была максимально отзывчивая, что в виртуальной машине ещё интересно, про что хочется сказать. Это то, что виртуальная машина под собой.

18: Несёт такую очень важную парадигму, как она исполняет менеджмент, язык, менеджмент, язык, например java и gs они отличительны тем, что, в отличие от плюсов, почему-то люди не хотят взаимодействовать с памятью напрямую они не хотят видеть какие-то дабл фри какие.

19: Удаление памяти, когда она уже была удалена, или, например, то, что мы где-то имеем провисшие указатели. Все это должен делать Гарбач коллектор, Гарбач коллектор должен прежде всего определить какие

20: Объекты можно удалять, то есть они мусорные, а какие нет. Для того, чтобы определить мусор, используется достаточно простая тривиальная схема маркировки объектов. То есть у нас есть текущий срез системы, у нас есть ссыл.

21: На глобальные переменные. У нас есть текущий стек исполнения с объектами. Дальше мы берём все эти объекты, которые получили строим дерево достижимости, то есть берём ссылки из этих объектов, потом ссылки

22: Ссылок и так далее. Все, что мы встретили на этом пути, это все, к чему пользователь может так или иначе получить доступ. Соответственно, удалять это ни в коем случае нельзя. Однако если мы встретили объект, который лежит вне этого графика, вне этого графа, то его точно можно

23: Удалить это как раз то, чем мы и займёмся. И насколько важно это сделать быстро. Прежде всего стоит сказать, что маркировка живых объектов из за особенностей алгоритма, который используется в Гарбач коллекторе, это вещь.

24: Которая происходит на Паузе что такое пауза для user space приложения пауза это полная остановка его работы. Соответственно у вас приложение останавливается, делается маркировка удаления объектов и приложение продолжает свою работу. Представьте себе, что

25: Вы работаете с приложением, и оно внезапно остановилось на несколько секунд. Вы, наверное, это заметите, но, к сожалению, на самом деле то тот временной промежуток, про который мы говорим, он не измеряется секундами. Современный.

26: Телефоны выдают порядка 100 кадров в секунду на некоторых приложениях. И это как раз тот таргет, на который мы должны были ориентироваться. Соответственно, если у нас 100 кадров в секунду между 2 кадрами проходит 10 миллисекунд, соответственно,

27: Мы должны делать маркировку быстрее, чем 10 миллисекунд, потому что если мы делаем её медленнее, все мы потеряли кадр. Конечно, нам давным давно говорили про то, что человеческий глаз способен увидеть только 24 кадра в секунду никак не иначе 25 кадр не поймать.

28: На самом деле вы увидите, если у вас внезапно частота кадров начала скакать, вы увидите эту просадку частоты кадров и опять же уйдёте к кому-нибудь другому. Это те ограничения, с которыми приходится сталкиваться, когда мы реализуем алгоритм маркировки и

29: Ещё очень важная вещь, которую хочется сказать, это то, что заранее неизвестно, сколько объектов у нас будет в нашем графе достижимости. Мы не знаем, сколько сейчас объектов живо, сколько умерло. Нам приходится это делать по мере заполнения этого графа. И вот

30: У нас есть задача 20 миллисекунд. Это текущая пауза однопоточного обхода живых объектов. Мы хотим это сделать быстрее, чем за 10 миллисекунд. Ну, приходит логичная идея. А давайте добавим просто многопоточность. Давайте сделаем всю эту работу в несколько

31: Потоков. Ускорим нашу производительность и получим отличный результат.

32: Давайте перейдём к 1 блоку. Это с изменением кода. Прежде всего, чтобы добавить многопоточность в однопоточный проект, нужно изменить некоторые его части. Для начала нужно добавить компере.

33: Операции в пометку того, что объект живой или нет. Действительно, вот у нас есть 10 потоков, которые так или иначе получили доступ к 1 и тому же объекту. Во время алгоритма маркировки. Мы не хотим в этих 10 потоках делать 1 и ту же работу. Давайте сделаем

34: Так, чтобы маркировка объекта, то есть выставление специального битика с информацией о том, что этот объект достижим, его не надо удалять. Происходила с помощью комппер фаб операции. Это достаточно тривиально, но немножечко просаживает производительность.

35: Относительно однопоточного режима. И 2 большая часть это то, что нам хочется как-то распределить задачи между потоками. В идеале сделать так, чтобы каждый поток работал определённое количество времени, причём идеально ровное. То есть мы не видели такого, что 1 поток

36: Dell 90% работы, остальные по 10. Хотелось бы для этого добавить какие-то многопоточные очереди, такие, чтобы все было идеально. И, например, с учётом того, что мы достаточно много взаимодействуем с операционными.

37: Системами на больших хостовых процессорах и вообще в принципе с процессорами на x 86 добавление лок фри очередей это хорошая идея, казалось бы, лок фри очереди нет блокировок, все прекрасно работает, но к Сожа.

38: К сожалению все оказалось немножечко сложнее так как мы говорим про мобильные процессоры, то в большинстве своём они используют архитектуру arm в отличие от x 86 архитектуры архитектура arm это вик мемори модул вот у нас.

39: Есть strong мемори модул и давайте я задам вам небольшой вопрос предположим, у нас есть 2 блока памяти зелёный и синий 1 поток записывает в зелёный блок, а в синий блок б.

40: Я бы хотел услышать, какое количество вариантов значений в зелёном и синем блоке мы можем увидеть в случае x 86 архитектуры, естественно, про компилятор ный. Реорина я не говорю его нету, забыли про него итак, поднимите руку. Кто?

41: Думает, что у нас будет только 1 вариант во 2 потоке. Хорошо, никто так не думает. Это отлично. 2 варианта. 3 варианта. Так уже побольше. Отлично. 4 варианта супер.

42: Мнения немножко разделились, но на самом деле количество вариантов в x 86 архитектуре ограничено 3, то есть мы либо увидим 0 и 0, либо увидим а и 0, или увидим а и б. Мы не можем увидеть б.

43: 0 просто из за особенностей стронг мемори модели она это гарантирует а вот arm этого не гарантирует то есть в случае арма у нас здесь будет 4 варианта что это значит для нас как для разработчиков прежде всего если у нас есть

44: Стандартная сингл, консьюмер, сингл продюсер, очередь. То есть у нас есть продюсер с записью данных и выставлением флага. И есть консьюмер, который читает флаг, когда флаг выставлен, он читает данные, если мы работаем с этим кодом, на

45: X 86 архитектуры, то мы получаем достаточно тривиальные ассемблерные инструкции 2 мува, а в случае консьюмера чтение из флага, и если флаг выставлен, просто читаем из данных, однако в слу.

46: Arma код немножечко увеличивается. И на самом деле самое главное, что здесь есть, это 2 инструкции. В 1 случае это store с релиз, а в другом случае это load с эквайр, то есть

47: Для arma из за того, что у нас есть 4 варианта того, что может увидеть 2 поток, вставляются дополнительные инструкции внутри, содержащие барьеры. Что это значит для тех, кто пытается разрабатывать какие-либо вещи под арм и пришёл, например,

48: Пример из интела то, что на самом деле лок фри структуры выдают другие значения, как бы это странно не казалось я взял академическое исследование, в котором авторы исследовали различные реализац.

49: Lock free очередей, а также сделали свою лок фри очередь по сравнению с производительностью мьютексов, и что интересного они получили то, что время исполнения на интела на интеле в случае с мьютексом и лок фри отличается намного.

50: Сильнее, чем в случае арма. То есть, как вы видите, лок фри, очереди на арме работают хуже, чем на интеле. То есть их разница по сравнению с ютексо сильно отличается. А что же получили мы, когда работали над обходом живых?

51: Объектов. То, что из за того, что у нас конкуренция была меньше, чем та, которая была в академической работе, то только в случае использования 4 плюс потоков лок фри очередь начинала обгонять обычный вариант с мьютексом это немножко странно.

52: Но на самом деле просто причина проста, потому что накладные расходы, которые вызывала лок фри очередь в случае, когда на самом деле никакой конкуренции не было, съедали достаточное количество производительности. Отсюда мы сделаем вывод.

53: Если мы будем использовать для нашей многопоточной синхронизации и для многопоточного обхода более 4 потоков, то лучше использовать lock free, если меньше, то лучше воспользоваться мьютексом, я думаю, мы к этому ещё вернёмся дальше.

54: Стоит немножечко окунуться в интересную тему поиска ошибок, когда мы думаем добавить многопоточность в наш однопоточный проект. 1, о чем стоит задуматься, это то, а сколько ошибок вообще то у нас получится, потому что, в принципе многопоточность

55: Увеличивает количество сценариев, которые в итоге приведут к 1 плохому месту. На самом деле, с учётом того, что у нас была не просто многопоточность, у нас была многопоточность, у нас были разные архитектуры, у нас были разные процессоры.

56: Общее количество сценариев стремилось, условно говоря, к бесконечности. Есть отличный пример, который описывает то, насколько сильно все может быть плохо перед вами. Код, который жил в нашем проекте полтора года. Я его написал достаточно.

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

58: Пробовали ещё раз, чтобы избежать двойного двойной локации памяти если и эта локация неудачная была, то мы создавали новый регион, выделяли в нём, что важно, без какого-либо атомика.

59: Память, потому что как будто бы доступ к этому региону имеет только 1 поток. Зачем там вставлять какие-либо ещё синхронизации и выставляли текущий блок, как выставляли новый блок в текущий, к сожалению.

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

61: Получать ошибку. Буквально каждый запуск нашей системы, каждый её запуск нашей системы приводил все к падению. Ошибка достаточно просто нашлась. Оказалось, что здесь точно такой же сценарий, про который я говорил чуть

62: Чуть раньше, то есть 2 поток видит уже новый блок, но не видит запись, которая была про то, что нужно изменить указатель на свободную память. То есть нужна дополнительная синхронизация. По сути дела, нужен просто компере сфаб в выделении.

63: Памяти в том блоке, который ещё 2 поток как будто бы не видит ради интереса я решил посмотреть, а сколько времени нужно, чтобы кэш линия с этими данными синхронизировалось, между 2 ядрами процессора оказало

64: Что нужны порядка секунд, нескольких секунд, чтобы эта синхронизация произошла. Это немножечко ввело меня в ступор, потому что получается, что сколько сценариев потенциально мы можем пропустить сегодня у нас 1 количество

65: Ядер, 1 количество процессоров. Завтра добавился какой-то другой и стала стрелять ошибка, которую мы никогда и не видели. Что вообще в принципе можно сделать в такой ситуации. Ну, во первых, стоит воспользоваться различными статическими

66: И динамическими анализаторами, и санитайзерами, например, тот же сан, и так далее. Однако, как вы понимаете, те, кто работали с санами и статическими анализаторами, если вдруг внезапно в вашей системе появляется прямой вызов плюсового

67: Кода из ассемблера, то тут они уже вам не особо помогают. А у нас, к сожалению, была именно такая ситуация все-таки виртуальная машина это не только сборщик мусора, но ещё и justin time, компилятор, джастен, тайм компилятор, он

68: Переводит байт код, который написан на менеджмент языке, то есть, например, на джаве и на gs в ассемблерный код, то есть, по сути дела, часть работы, которая у нас происходит на процессоре, она делается напрямую из ассемблерных инструкций и оттуда же вызывается плюсовый.

69: Код, а вот с этим статические анализаторы работают не очень. Что же делать в такой ситуации, так как у нас были некоторые дополнительные мощности. В отличие от небольших разработчиков приложений, мы могли себе позволить сделать подобное. Мы брали

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

71: Заряжались и все это работало 24 часа, 7 дней в неделю. Да, это не идеальная, неидеальная, не идеальный подход для того, чтобы снизить количество ошибок. Но в любом случае это намного лучше, чем получать ошибку каждый раз, когда у нас добавляется. Но

72: Процессоры все-таки покрыть все возможные варианты тестами очень сложно.

73: Давайте опустимся чуть ниже. Я расскажу про борьбу с мобильными операционными системами. Этот блок хочется начать с того, что в 1 очередь мобильные процессоры это очень интересная система.

74: В отличие от хостовых, где у нас, ну, максимум может быть 2 типа процессоров, то есть производительные энергосберегающие ядра. Здесь есть 3 варианта. Есть так называемое сильное ядро, это максимальная производительность. Максимальное энергопотребление есть несколько средних

75: Ядер со средними значениями и того, и другого, и есть слабые ядра, которые, возможно, работают даже в 2 раза хуже, чем сильное ядро, но при этом и потребляют намного меньше памяти. И вот у нас есть в телефоне, например, 8

76: Ядер 1 сильное, 3 средних, 4 слабых. Вот у нас есть задача, которую мы решили делать с помощью многопоточного программирования. Ну, логичное решение. Давайте сделаем её 8 потоков, 8 потоков на 8 ядрах. Хорошо, прекрасно будет быстро, к сожалению.

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

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

79: Устройств и так далее. Все это делается на слабых ядрах с высокой конкуренцией и в принципе этим процессам нормально там жить, но нам нужно сделать задачу как можно быстрее. Мы не можем себе позволить внезапно оказаться в ситуации, когда наш поток на слабом ядре был

80: Переключён скедулером операционной системы и не закончил свою работу. Собственно говоря, это мы и заметили. У нас был сценарий, когда стоит 1 поток на сильном ядре и 1 поток на слабом ядре, и это работает медленнее.

81: Чем просто 1 поток на сильном ядре, как это получалось. Да, очень просто. Сильное ядро делало свою часть работы. Слабое ядро взяло какое-то количество объектов для того, чтобы сделать для них маркировку. И внезапно операционная система его пре.

82: Сильное ядро закончило свою работу и ждёт, пока слабое закончит свою, но слабое спит слабый поток все также продолжает ждать, когда операционная система вернёт ему управление. И на самом деле то время ожидания, которое мы получали, было

83: Сравнимо с тем таргетом, который мы хотели достичь. То есть в районе нескольких миллисекунд мы могли просто ждать нас. Это, мягко скажем, не устраивает. Возможно, были какие-то другие способы для того, чтобы как-то распараллелить задачи. И вообще в принципе,

84: Модифицировать сам алгоритм, но при этом оказалось, что использовать все то, что я сейчас рассказал, слишком дорого. Мы потратим очень много времени на то, чтобы использовать слабое ядро, в котором производительность и так очень низкая. Давайте просто забудем

85: Про них хорошо убрали слабые ядра из вообще нашего, нашей темы дискуссии. Вот у нас есть сильное ядро, максимальная производительность. Как классно. Давайте туда запихнём самый главный поток управления.

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

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

88: Такого процесса, это активное ожидание, активное ожидание, что делает, увеличивает счётчик исполненных инструкций и при этом постоянно исполняется. Если дать такой процесс операционной системе, мобильной операционной системе, то она с высокой долей вероятности переведёт его какое-то время на

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

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

91: Мы увеличиваем ту скорость, с которой мы делаем задачу, но при этом потенциально мы увеличиваем энергопотребление, как нам быть вообще, в принципе, как операционные системы мобильные ведут себя с энергопотреблением. Они прежде все

92: Его любят. Это самое энергопотребление сберегать. Действительно, если ваш телефон живёт меньше 6 часов, навряд ли вы останетесь довольны его использованием. Поэтому мобильные операционные системы могут снижать частоту, с которой работают ваши я

93: На 20%. И причём это снижение происходит вне зависимости от того, что у вас работает высокопроизводительный режим. Ваш телефон стоит сейчас на зарядке. Вы все равно будете наблюдать снижение тактовой частоты.

94: Что это значит? Это значит, что те таргеты, которые мы строили, исходя из изначальных условий, на самом деле должны быть достижимы. И когда у нас тактовая частота была снижена на 20%, посмотрите на свои мобильные устройства. Я не думаю, что у всех

95: Из вас сейчас они заряжены на 90 100%. Скорее всего, там 60, 50. Соответственно, это тот таргет, на который тоже нужно рассчитывать. Соответственно, реальные значения паузы должны быть ниже. Окей, а что же на самом

96: Деле с энергопотреблением, что более энергоэффективно работа на максимальной частоте ядра или на минимальной. Давайте я спрошу у зала. Вот у нас есть задача, которую мы можем сделать в 1 поток.

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

98: Вариант. Хорошо, отлично. Поднимите руку. Сейчас те, кто думает, что 2 вариант

99: Super примерно мнения разделились. Это интересно. На самом деле, опять же, из академического исследования на андестендинг энерджи консан оф арм бейст, мультикор серверс. Видно, что работа на максимальной частоте ядра более энергоэффективна, то есть

100: Здесь работает принцип меньше времени. Работаем, несмотря на то, что в каждый момент времени работы мы потребляем большее количество энергии. Суммарно, батарейка разряжается меньше окей. Но, наверное, такой же принцип верен. И когда мы говорим

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

102: Для использования 3 и 4 ядер. И, как вы видите, использование 4 ядер в исследовании был четырехъядерный процессор. Использование максимального количества ядер на самом деле потребляет большее количество электроэнергии, чем использование 3 ядер для 1 и той же

103: Задачи. Авторы предполагают, что это происходит из за того, что мы тратим намного больше времени на многопоточные синхронизации. Так или иначе, ваши ядра в процессоре обмениваются кэшами. Так или иначе, вы

104: Действуете дополнительные ресурсы процессора на работу на максимальной загрузке. В итоге, что мы можем отсюда сделать вывод, какой в 1 очередь внимательно следим за зарядом батареи, если мы видели сниже

105: Его ниже 80%. Все те значения, которые мы можем померить. Например, вы изменили какую-то часть кода и хотите посмотреть, насколько сильно изменилась производительность. Они будут невалидны. Вам нужно всегда смотреть за зарядом батареи. Мы не используем слабые ядра рабо.

106: С ними не стоит свеч, вы потратите огромное количество времени для того, чтобы просто воспользоваться урезанным количеством мощности, которое у них есть. Делаем выставление наших потоков на сильное плюс среднее.

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

108: И, не используя максимальное количество ядер, потому что использование максимального количества ядер ведёт к увеличению заряда расхода батарейки, что в итоге получилось, да, добавление многопоточности ускорило обход живых объектов в сборщике.

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

110: Или ускорение 1 и 7 раз. Это, мягко скажем, далеко от того, что мы хотели бы получить. И как вы понимаете, если у нас была пауза 20 миллисекунд, до паузы 10 миллисекунд и даже до паузы 5 миллисекунд, потому что 10 миллисекунд, опять же, это время между 2

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

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

113: Мы делаем спектрал со всеми этими проблемами. Вообще, в принципе, спектрал это компания, которая занимается высокочастотным трейдингом. Высокочастотный трейдинг. Это прежде всего необходимость писать код, который работает очень быстро.

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

115: Мобильные процессоры. На самом деле, если среди вас есть апологеты серверных армов, я бы очень хотел с вами пообщаться, потому что там есть что обсудить, но на самом деле те проблемы, с которыми мы сталкиваемся, похожи на то, что я сейчас рассказывал.

116: Например, для той же ситуации, когда операционная система внезапно начинает перемещать наши потоки между ядрами, прерывать их и делать различные, другие, не очень желательные нам вещи, мы делим все ядра.

117: Ядра процессора на 2 типа. 1, который используется в наших высоконагруженных сервисах. Естественно, там работает принцип 1 поток, 1 ядро. Мы хотим получить максимум производительности и стабильную производительность в течение всего времени работы, а все остальное

118: Мы даём тем процессам, которые могут в принципе и подождать. Это мониторинг различные процессоры операционной системы, какие-то дополнительные синхронизации с сервером и так далее. Дальше, конечно же, мы отключаем гиперте.

119: Благодаря тому, что маркетологи интела в своё время очень сильно постарались, но когда-то, если старички помнят, когда интел была ещё компанией, которая работала под руководством инженеров, они могли быть честными со своими.

120: Пользователями и говорить то, что гипертрейдинг добавляет 30% производительности. Сейчас это по мановению волшебной палочки превратилось в увеличение количества ядер в 2 раза. На самом деле это далеко не так. И мы во всех своих проектах

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

122: Полная жопа, я сказал, это отличная возможность рассказать на конференции.

123: Вот перед вами красным линией написано изменение производительности нашего высоконагруженного сервера и сервиса на нём с включением гипертрейдинга. Но это мы с вами разобрали только

124: Персентиля ниже 0 75. А что же на высоких персентиля, на высоких персентиля? Все намного хуже? Почему это вообще в принципе происходит? Да, включение гипертрейдинга замедляет наше исполнение примерно в 2 раза. Но такие

125: И большие задержки на высоких персентиля. Это не то, что можно ожидать. Все очень просто. Мы работаем с частыми торговыми событиями. Соответственно, если вы не успели обработать торговые события за определённый промежуток времени, вы опоздали.

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

127: А дальше я хотел бы рассказать вам про очень интересный проект, который есть в открытом доступе на гитхабе. Он позволяет нам

128: Сконструировать вот такие интересные картиночки, что мы здесь видим, здесь представлены, так называемая корто кор летенси, то есть те задержки, которые мы получим, когда будем пытаться синхронизировать 1 кэш линию между 2

129: Ядрами 1 процессора. Перед вами четырехъядерный intel core ай 7. В 1 случае мы видим номер ядра, в другом случае время в наносекундах на обмен 1 линии кэша. Ну как будто бы казалось бы ну что тут такое? Но в 1

130: Случае у тебя 26 наносекунд, в другом случае 28 2 наносекунды. Ну это просто какие-то копейки. Однако если мы перейдём к настоящим большим серверным процессорам, например, я взял для примера 2 варианта амд райзен и

131: Интел ксион. Мы можем здесь увидеть уже более интересные результаты. Прежде всего в случае амд мы видим, что у нас есть ярко выраженные блоки по 3, то есть те ядра, которые обмениваются кэшами очень быстро, однако

132: Вне этого блока они обмениваются кэшами с другими ядрами медленнее. У интела все стабильно, все стабильно неплохо. Что это значит для нас? Предположим, вы решили выбрать себе процессор для

133: Высоконагруженного сервиса на вашем сервачке, где-то стоящем, например, рядом с биржей. И вот вы думаете, а какой процессор вообще то взять? И тут задаётесь логичным вопросом, а как вообще это выбрать? Я вам

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

135: Если же количество потоков превышает 3, то вам лучше взять intel ну как будто бы взять интел, не взять intel ну там и в принципе пофигу запихнули куда-то потоки на какие-то ядра и все и забыли про это на самом деле это не так, если.

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

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

138: Рассказать в рамках 1 сессии. Поэтому я думаю, что я подготовлю доклад, наверное, на следующий сипипи раша плюс. Здесь присутствуют мои коллеги, которые, если что, тоже смогут ответить на все ваши вопросы. Если вдруг я буду занят, я сегодня точно буду занят.

139: Потому что сегодня вечером автопати. Итак, сделаем выводы, да, добавление многопоточности может ускорить работу вашей критичной части системы, но вам нужно учитывать большое количество

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

141: Будет добиться стабильной работы на всех устройствах, которые у вас есть, и даже стабильной работы на 1 устройстве. И вообще, в принципе, добавление многопоточности в однопоточный проект это очень ресурсозатратная штука, с 1 стороны.

142: Минус, вы потратите большое количество времени на то, чтобы это сделать. С другой стороны, это плюс. Если вас компания наняла на добавление многопоточности, вы можете быть уверенны, вы тут работать будете ещё долго.

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

144: Нет, я хочу закончить вопросом. А вам точно нужно многопоточное программирование. Спасибо вам за внимание. Сейчас я готов ответить на все ваши вопросы.

145: Саш, спасибо огромное за такой мозговзрывательный рассказ. И у меня к тебе будет такой вопрос. А может быть, ну их нафиг, эти операционные системы.

146: Это хорошее предложение, Антон. Операционные системы, да, с 1 стороны, они вставляют очень много палок в колеса. С другой стороны, ну, нельзя же разрабатывать операционную систему под каждое приложение, которое вы хотите использовать, было бы странно пользователя заставлять. Знаете, вот у вас есть

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

148: Не знаю, ну то есть, когда ты хочешь что-то запустить, что-то под windows, и у тебя линукс или мак, то становится грустно с 1 стороны, да, но, с другой стороны, все-таки стоит учитывать, что-то, что работает поверх.

149: Операционной системы или на уровне гипервизора все равно имеет какие-то

150: Какое-то потребление ресурсов, которые вы могли бы использовать для выполнения ваших задач. Поэтому если вы хотите что-то делать безумно быстро, я бы сказал максимально быстро, то вот с этим стоит подумать. Возможно, вам вообще стоит переписать операционную систему, либо написать рт.

151: Ортос, это хороший вариант. Окей, у нас есть вопрос онлайн. Есть ли возможность запускать гц на уровне ядра?

152: Я даже сказал бы, что есть возможности запускать Гарбач коллектор, точнее, как поддержка Гарбач коллектора на уровне процессора. Какое-то время назад компания азул, по моему, могу

153: Ошибаться. В названии представила идею процессора, который внутри себя будет поддерживать Гарбач коллектор. То есть мы не будем дополнительно хранить какую-то информацию о том, жив объект или нет. А благодаря работе с адресом объекта мы можем это получить напри.

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

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

156: Определённая прям боль, чувствую, сейчас было, да, такое вот. И заставить её работать так как тебе хочется без всяких вот этих вот переключений, потоков и так далее. Но, к сожалению, это невозможно. И на самом деле, может быть, мой доклад звучал как-то несколько резко.

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

158: Оно ещё работало максимально энергоэффективно, это сложная задача, и однозначного ответа я здесь не могу дать. А может быть, стоит начать бить разработчиков процессоров?

159: Хорошая идея, хорошая идея. Я, честно говоря, так далеко не заходил. Вот. Но, возможно, я попробую. Просто все попахивает тем, что-либо мы разработчики софта, делаем что-то.

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

161: Давайте так. Мы все здесь профессиональные разработчики, никогда не ошибающиеся в нашем коде, поэтому очевидно, что виноваты не мы, то есть железячники.

162: Ребят, у нас во первых я че то немножко продолбался и забыл сказать, что у нас есть QR-код, по которому во первых вы можете оценить доклад и перейти в чат онлайн вопросов, также вы можете

163: Поднять лапку и к вам подойдёт человек с микрофоном и вы зададите свой вопрос. Вот я уже сейчас уже вижу таких людей и пока человек идёт с микрофоном, вопрос такой.

164: Модель памяти сейчас арм все чаще появляется в ноутах и desktop х там и так далее, там тоже вик мемори, модель ну да, в принципе, арм это подразумевает и надо же это

165: Учитываете при разработке плюсового кода для дестоповую? Абсолютно верно. Поэтому в этом и заключается 1 из основных проблем, когда мы переносим тот код, который хорошо работал на интеле, но, к сожалению, не был покрыт полностью тестами, либо

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

167: Так, у нас вопрос, да, спасибо за доклад. Вопрос такой. А вот если мы возьмём сервер какой-нибудь, да, и там, получается, будут 2 нумы, например. А вот эта картинка, она будет аналогична, если, например, 1 нумма или 2 нумы, ну вот где было сейчас вот сравнение.

168: Райзен и интел ну amd intel точнее давайте так вот конкретно этот проект, который на гитхабе он сделан под 1 нуму вот, то есть если 1 процессор все хорошо, если несколько тут уже возникают вопросы.

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

170: Если там 2 номы, мы между новыми хотим перекидывать данные, то это будет, ну, плохо. Я имею ввиду, что там не будет никаких оптимизаций, что, например, там просто у вас же по картинке было там, что у процессора получается 1 часть условно, ядер, она работает лучше, а последняя

171: Который хуже. И вот если 2 нумы, там не будет никаких оптимизаций, чтобы, например, там все работали примерно одинаково. Хорошо, я понял вас. Вопрос вас вопрос, простите, уже немножко заговариваюсь. На самом деле, к сожалению, это я не мерил, поэтому однозна

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

173: Отчасти удивительным открытием, потому что я никогда не думал, что у мд настолько ярко выраженное деление на ядра, которое внутри 1 блока, поэтому я предполагаю, что здесь нужно просто мерить. Спасибо.

174: Ну или оптимизировать дальше.

175: Здравствуйте. Огромное спасибо за интересный доклад. У меня вопрос, касающийся ваших текущих сервисов, спектрал технолоджис. Вы говорили, что используете подход. 1 поток. 1 ядро. Значит, я предполагаю, вы, наверное, изоля.

176: Ядер используете? То есть не хотите, чтобы какие-то другие процессы вот на этих ядрах запускались? И у меня вопрос такой, а какой механизм изоляции вы использовали? И удалось ли вам избавиться?

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

178: К сожалению, точно ответить, что именно мы использовали, я не совсем уверен, что я могу все-таки под da, но то, что я могу сказать, это то, что да, мы полностью избавились от дополнительных процессов системы, в том числе от Демонов, на самом деле, из своего опыта могу сказать, что все зависит от

179: От того, какую вы операционную систему используете, есть некоторые операционные системы, которые поддерживают такое разделение из коробки. Поэтому, если вы найдёте такую операционную систему, я вас уверяю, она достаточно легко ищется, то это возмож.

180: Ваш вариант для ваших задач можно уточняющий вопрос. То есть вы используете не линукс. Ну это как-то вы меня загоняете в угол, если честно. Хорошо, извините. Спасибо за ответ. Ну.

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

182: Real time, линукс, отличная идея. Ещё вопросы. Как-то все скромнее. Вот. Да.

183: Большое спасибо за доклад. Вот вы рассказали про текущее устройство мобильных arm процессоров, где у нас есть сильные, слабые средние ядра, а до этого у нас была схема биг литл, когда были только большие, там и малые, а до этого у нас вообще были только как бы 1.

184: Тип ядер, когда, ну, только появились мобильные четырехядерные процессоры. Возможно, вот здесь мы свернули не туда, и надо вернуться обратно или нет. Я на самом деле считаю, что это прекрасное разделение на 3 типа ядер, потому что как

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

186: Как бы где-то в бэкграунде. Поэтому по любому нужны слабые ядра. И вот мы приходим к тому, что нужны сильные ядра, нужны слабые ядра, но все делать сильными или все оставшееся делать слабыми тоже странно, поэтому как будто бы текущая схема

187: Неплохо так покрывает все возможное количество сценариев использования. Спасибо. Так, может это все на слабых, все на слабых тоже нет, это отличный вариант, потому что все на слабых и у нас по сути,

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

189: Ещё вопросы есть, то? Сейчас я начну накидывать.

190: Да, большое спасибо за доклад. А если взять армовские ядра, которые вот в одноплатниках, они там, у них нету биг литл, у них там обычно все-таки, ну, либо 4, либо сейчас уже там сильно больше, но они, я так понимаю, одинаковые. Там, я так понимаю, есть тоже смысл для того, что

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

192: Зависит от задачи, которую вы делаете, и от тех возможностей, которые у вас есть. Если вам можно делать изоляцию ядер, то, конечно, для достижения максимальной производительности её лучше делать вообще в любом случае. Вот. Но тут вопрос, что вы можете делать? Потому что

193: Например, на мобильных устройствах. Вряд ли вы можете это себе позволить. Вот. Поэтому ответ на ваш вопрос такой, что я бы рекомендовал это вам делать, если вы это можете делать. Ну, потому что, в принципе, если вы не особо паритесь насчёт производительности, то и вопрос такой не стоит.

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

195: Прекрасным решением. Ну, классно сделать какую-то задачу. Несколько потоков мы получаем ускорение, ну, как некоторые изначально считают, делаем в 3 потока, в 3 раза ускорение. Ну ладно, это опустим, что на самом деле, там в любом случае даже математически чуть меньше буде.

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

197: Было очень часто можно так делать. То есть, то есть ты говоришь, что оптимизировать код это оптимальнее, чем сделать его многопоточным в большинстве сценариев. Да, вопрос зачем?

198: Вот все здесь собрались, да и кто, кто, кто ноготочку пишет, давайте руку поднимем.

199: Зачем?

200: Вот вопрос у нас есть в зале. Возможно, ответ на твой предыдущий. Да, да. Возможно, это на самом деле ответ на мой предыдущий вопрос. Да, спасибо за доклад. Ну вот как раз про многопоточку, например, есть.

201: Solver, который решает какие-то цпу интенсивные задачи и нужно каждые, допустим, 5 секунд отправлять статус. Ну типа, например, hard beat. Что солвер действительно решает или что он

202: Решил. И вот тут как раз, ну, в отдельном треде как раз эти статусы отправляются, тут как-то можно обойтись без многопоточки. Если же задача солвера, она же, ну, блокирующая, просто идёт какой-то там.

203: Вычисление математическое. Ну, как раз то, что вы описали, по сути дела, ничем не изменится ситуация. Если вы разделите вашу задачу не на 2 потока, на 2 процесса, 2 разных процесса, которые работают на 2 разных ядрах. То есть, по сути дела, у вас будет однопоточный

204: Исполнение на 1 и 2 процесс, который просто смотрит статус через, например, обращение к текущим живым процессам линукса и отправляет этот статус. Поэтому тот пример, который вы привели, мне кажется, он отлично работает.

205: С тем, чтобы сделать его в несколько ядер. Просто между ними нет синхронизации. Тот кейс, про который я говорю сейчас это кейс, когда мы хотим увидеть синхронизацию между потоками, а не просто 2 потока, которые синхронно работают как раз для синхронной многопоточности. Все прекрасно работает. Мы

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

207: Красный вариант и я ни в коем случае против него не выступаю. Спасибо. Так, вернёмся чуть чуть чуть чуть назад. Так, может быть, продолбались инженеры, которые делали процессоры. Ну ты.

208: Мы сталкиваемся с тем, что у нас, а рассинхрон кэшей мы сталкиваемся с тем, что у нас, к сожалению, синхронного доступа к памяти нету.

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

210: Вообще, в принципе, а куда мы катимся? То есть получается, что новые процессоры нам приносят больше проблем. Ну, это очень интересный, дискуссионный вопрос. Я думаю, что сегодня его можно поднять на lightning talk, которые будут, но вообще

211: Да, куда мы катимся вообще? Я бы, в принципе, здесь поднял вопрос вик мемори модели армовойлок. Это прекрасный вариант для экономии памяти, экономии батарейки. Действительно, те значения, которые они показывают, это действительно очень круто.

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

213: Модель сама по себе. Вот тут как раз очень актуален тот возглас из зала, который был вик мемори. Модель подразумевает то, что программист про неё думает. Чтобы использовать её на 100%, нужно перестроить своё мышление. Мы в большинстве своём

214: Начинаем работу с интелом и x 86, ну или с амд не так принципиально, и когда мы работаем с ними, мы так или иначе, например, закладываемся на парадигму флагов, то есть сделали какие-то данные, выставили флаг, прочитали флаг, прочитали.

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

216: Монорепу, которая будет отличаться во всем на 2 разных таргета. Ну, это вообще непостижимая задача. Поэтому, к сожалению, ну, тут ты намекаешь на то, что как бы, наверное,

217: Нас ждёт какая-то эволюция операционных систем.

218: В чем именно в том, что, по сути дела, пока мы используем x 80 шестые, которые просто перекомпилировали и стали работать на армах, возможно, возможно, в принципе у нас очень

219: Многое поменяется. Все зависит, по сути дела. Сейчас от текущей гонки между интелом и армом. Как мы все знаем, компания intel сейчас переживает не лучшие времена. И, возможно, там ещё амд. Правда есть, да, амд точно есть. Вот.

220: Возможно сейчас будут происходить какие-то большие изменения в этом всем может быть через какое-то количество времени мы вообще будем писать на 3 архитектуре, например, на риск 5. Вот почему про неё ещё никто не вспомнил, потому что ты про неё не сказал.

221: Ну вот теперь я сказал, вот, поэтому, возможно, что в будущем все изменится. И действительно, то есть надо было пораньше, да, задать этот вопрос, время заканчивается.

222: Нет, все-таки, смотри, мы уже там сколько мобильным устройствам, ну, лет 30 то точно тем, которые вот, вот, вот, вот такие уже, но все равно операционные системы.

223: Это, ну, как-то там подкрученный куда-то линукс, который разрабатывался ещё при царе горохе.

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

225: Видишь, на самом деле, я думаю, что потенциально, конечно, есть такой вариант, что кто то когда-то перепишет операционную систему непосредственно под вик мемори модель, но шансов очень мало. Все-таки линукс это такой сбор знаний. Сбор.

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

227: Которые, я помню, находили в ядре линукса, в том числе на интеловских процессорах на x 80/6, и все это будет заново изучаться, заново находиться, заново, все будет не работать, работать, не так будет какие-то дыры.

228: В безопасности. Не уверен, что такое достижимо. Просто так нужен. Нужна компания, которая поведёт за собой и действительно сделает это с нуля. Ну, смотри, у нас есть огромный опыт в эксплуатации.

229: Первых операционных систем типа linux у нас есть огромный опыт макось, линукс, windows мы можем посмотреть на все, как как они проектировались, как они эволюционировали.

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

231: Хорошее предложение, на самом деле отличная идея для стартапа. Если кто-то хочет, то берите. Вот, потому что если прийти с инвестором, с такими предложениями, что давайте мы сделаем вам новую операционную систему, которая будет работать прекрасно на мобильных устройствах и на немобильных

232: В данном случае, так как apple открыла для нас то, что макбуки тоже могут работать хорошо на армах там мобильный, ну, по сути дела, не серверная вот эта штука, по сути дела, да, вот то, возможно, вам и дадут денег, но сколько времени вам понадобитс?

233: На то, чтобы это сделать. А давай деньги возьмём. Это дальше реши. В принципе, я думаю, что так и стоит всегда поступать с подобного рода. Саш, спасибо тебе большое. Спасибо вам и не