event1 честно говоря не знаю. Cамая частая ошибка c llvm и lto, что o файлы содержат LLVM IR, а его могут обработать только тулчейны llvm. Эта ошибка бывает когда сборочные скрипты пытаются использовать другой ld, ranlib, ar. Уже не помню ошибку с DKMS, так как эта ошибка была еще давно до lto, видимо была тоже причина в этом.
alsoijw человек просто перепутался в ошибках компилятора и ПО, ошибки компилятора посложнее ловить и ПО не всегда может их решить. Проблемы производительности ПО через профилировщик видно, в дальше можно просто посмотреть на ошибки оптимизации этого куска кода, компилятор при передаче определенных параметров может показывать такие ошибки, в clang это делать удобно. Ошибки компилятора это сложнее, чаще всего он предустановлен и даже если сделают быстро патчи, то не факт что они быстро появятся в дистрибутиве… Только на днях видел в каком-то пакете багрепорт связанный с GCC, и там отсылка на сам баг в GCC. У меня были тоже подобные баги с LLVM, но у меня git версия и патчи сразу переношу в свой пакет aur.archlinux.org/packages/llvm12-git
Вот к примеру баг llvm с которым лично столкнулся и там даже отписался bugs.llvm.org/show_bug.cgi?id=49915
alex1478 виды ДДОС бывают разные, может они общий канал к серверу забивают и создают нагрузку на сеть? Когда меня ддосили, крупный ДЦ в европе тоже отключал меня на несколько дней, сказали мой сервер создал большую нагрузку на их сеть и другие клиенты страдают из-за меня, хорошо, что счет мне не выставили, правда было это 8 лет назад, и тогда каналы у ДЦ были слабже, но натекло тогда пару десятков ТБ за пару дней. Плюс это вдс и количество сетевых карт ограничено, при большом количестве пакетов сетевые карты могут начать отбрасывать пакеты других клиентов.
И да и нет. В вашем случае вероятно можно просто обойтись сигнатурной фильтрацией трафика, и боты создают уникальный отпечаток трафика и повторяющиеся пакеты. Тут просто клиент платит за свою безграмотность, что не смог отфильтровать фаерволом сам. На безграмотности сейчас зарабатывают все, и в данном случае морально этические нормы не нарушены. Никто не должен заниматься обучением людей, а если они хотят учится пусть учатся на своих ошибках и деньгах. Да и многим проще не думать и заплатить другим…
По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.
Как же мне это знакомо. Очередной трейдер из разряда плохому танцору даже яйца мешают… Такие не видят своих ошибок. Первая ошибка это торговля в слишком в волатильное время, просто увеличивается дисперсия стратегии, и сильнее разброс от математического ожидания. Можно забить в мой симулятор математического ожидания h0tc0d3.github.io/evtools/#/en/ev.html
Quantity — количество сделок, поставить 200.
Deviation RSD — относительное отклонение, по умолчанию это процент от риска(больше подходит для трейдинга так как с ростом риска чаще всего увеличивается еще дисперсия портфеля), напротив есть переключатель Amount of lose/EV риск/мат. ожидания, поставить для начала 50%(и quantity 20), а потом 150%(и quantity 200) и сравнить как будут распределены вероятности вписывающиеся в 1-4 сигмы(черная линия мат.ожидание, цветные случайная симуляция и разброс стратегии в зависимости от дисперсии), и где будут длиннее просадки.
Вообще кто торгует интрадей обычно первые 30-60 минут открытия дня не торгуют, и последний час, плюс не торгуют 5-30 минут после клиринга и после открытия американской сессии. На новостях тоже не торгуют — высокая волатильность, многие убыточны в это время, чаще всего на новостях первое время движение будет противоположное новости, так крупные игроки сбрасывают позиции и обманывают рынок, а потом резко идет разворот в сторону новости. Для таких как раз придумали вести статистику и разбор сделок, по статистике сразу видно в какие часы открывались самые убыточные сделки и чаще всего они будут в то время про которое написал выше. Зачастую, если выкинуть такие часы из торговли, убыточный трейдер может начать зарабатывать т.к. всю заработанную прибыль сливал в самые волатильные часы. В роботы не редко люди закладывают расчет волатильности, чтобы отключать их при резком росте. По 100 сделок в минуту это совсем не здоровая торговля, непонятный скальпинг на высокой волатильности где системы риск менеджмента дают сбой.
В некоторых пакетах разработчики просто кладут на всех. Пишешь им багрепорты, а они забивают и даже не отписываются. Есть не мало адекватных, которые патчи быстро делают. Но так же не мало кто забивает на критические ошибки, мне даже самому не редко приходилось писать патчи потому что авторы забивали болт. В линукс есть такая штука, что старые разработчики боятся иноваций и всячески этому мешают, готовы поддерживать 30 летние компы, но отказываются от растущего рынка новых, например так было с автором zlib-ng когда его патчи не приняли в zlib, разработчики xorg не очень идут на помощь wayland и не спешат решать общие проблемы. Радует что mesa и ядро развиваются хорошо, привносят инновации и выкинули мертвые код для старых систем, чтобы открыть новым лучшую производительностью
yarston ничего странного. Кривая оптимизация может даже быть из-за неправильного разворачивания кода GCC. Плюс некоторые пакеты имеют плохую оптимизацию, а где-то вовсе криво собираются в Arch Linux. Поэтому мною были созданы свои сборочные файлы. До mesa 21 и ядра 5.10 моя видеокарта плохо поддерживалась, сейчас все стало лучше. До сих пор в ядре есть где AMD не совсем корректно работает, например управление электропитанием. Ядро под Intel лучше оптимизировано. Но вот что радует AMD нанимает разработчиков и с каждым месяцем ситуация меняется в лучшую сторону. Вообще графический стек это самое слабое место Linux, у меня к примеру в хромиум не работает hardware acceleration. Проблема уходит корнями далеко в прошлое, поэтому сейчас активно пытаются развивать wayland, но для меня он сырой еще, у меня с ним кучу багов, поэтому от него пришлось пока отказаться community.kde.org/Plasma/Wayland_Showstoppers
Gorthauer87 без разницы, хоть многое у меня собирается вручную, большая часть это бинарные пакеты дистрибутива. У меня все собирается и обновляется за минимальное и вполне адекватное время, и без напряга. Подойдет в принципе любой дистрибутив, просто написал про тот с которым мне удобнее работать. Основная задача статьи открыть дополнительные горизонты для оптимизации, где их будут применять в принципе без разницы. Хоть в centos 7 и на сервере в продакшене, в принципе стабильности всех решений достаточно для серверов. Ядро с clang собираю давно и стабильность системы имхо выше, LTO тестирую с 5.12.6 и ничего не ломалось, стабильность хорошая. Часть пакетов в arch linux и так собирается с LTO и GCC, просто переписал сборочные файлы под lto thin и clang.
staticmain у маломощных газоразрядных ламп не бывает таких взрывов, как у мощных. Чаще всего при взрыве лопается внутренняя колба, такие лампы стоят много где как как обычное освещение, мне известные единичные случаи взрывы маломощных ламп. А вот очень мощные лампы довольно часто взрываются.
Взорваться у вас может даже новая лампа. На видео нет доказательств того, что это именно лампа виновата. Во вторых лампа там на 6КВт и такой тип сам по себе взрывоопасен. В проекторах в районе 150ватт. Как понимаю там даже разный тип ламп стоит.
Почему нет? Собрать ядро с LTO нет ничего сложного. Насчет vi и vim первая сложность в обучении это как выйти из них и как перейти в режим ввода команд, дальше обучение очень простое. По этой причине многие не пользуются ими и не понимают их. Владение vi и vim никак не показатель опыта и не маркер владения Linux. Человек может всю жизнь пользоваться nano и знать Linux лучше вас. Статья в первую очередь для тех кто хочет обучиться большему.
alsoijw вы можете про это написать статью, с радостью вас почитаем. Мною было написано про то чем пользуюсь сам и давно. Мне как разработчику clang больше нравится как компилятор так как он лучше ловит ошибки в коде и проблемы оптимизации. Переходить обратно на GCC ради бенчмарков мне просто лень. На clang перешли FreeBSD и MacOS и лично это только поддерживаю. Все проблемы медленного кода можно удобно отловить в clang, переписать код и улучшить производительность, тем самым просто убрать разрыв там где gcc быстрее, в gcc этого нет. Для меня в первую очередь производительность зависит от разработчика, а не от компилятора или языка программирования. Для себя предпочитаю полу автоматический режим, могу накатить патчи, протестировать что-то, быть уверенным, что не будет такого, что сборка сломает систему когда меня не будет рядом. Всегда могу быстро откатить систему назад.
VioletGiraffe комментарием выше есть уже ответ на ваш вопрос. Судя по perf у меня есть улучшение общей производительности. В общем система стала стабильнее, пропала дерготня, особенно в анимациях kde и в хромиум, рендеринг и загрузка вебстраниц происходят заметно быстрее.
Статье не хватает бенчмарков. Так же непонятен вопрос обновления — запускается ли автоматическая пересборка или нет.
perf в помощь. У меня лично загрузка процессора упала при вызове API ядра. Пересборка остальных программ где-то быстрее где-то медленнее. В общем дало выигрыш хороший, упала загрузка процессора, стало меньше потребление памяти, анимации стали плавнее и производительнее. Сложно оценивать производительно современных компиляторов, в одних программах код будет быстрее в других наоборот. У меня есть бенчмарки для себя, где-то GCC выигрывает почти в 2 раза в скорости, где-то clang оказывается в раза 2 быстрее. clang в первую очередь дает более прогнозируемый код и не ломает поведение. Мне известны случаи когда GCC ломал поведение программ в случае переоптимизации, и поэтому разработчики программ отключали некоторые типы оптимизаций. Как знаю, в случае с рекурсивными вызовами их производительность будет увеличена в LLVM 13, но рекурсия в принципе является плохим тоном программирования и лучше ее избегать, переписывать алгоритм где есть возможность.
Так же непонятен вопрос обновления — запускается ли автоматическая пересборка или нет.
Не запускается, мой скрипт просто уменьшает количество действий, при установке все равно нужен sudo пароль. В принципе можно в крон или системд его прописать под рутом, и убрать проверку рута. Но сборка под рутом является плохим тоном.
Так же вопрос, почему выбран бинарный дистрибутив.
Мне не нужно собирать все. Дистрибутив выбран по принципу самое свежее ПО. Критические программы у меня собираются вручную. Arch Linux для этого хорошо создан и все делается удобно, можно автоматизировать сборку. У меня сборка всего критического автоматизирована, плюс где-то есть патчи которых нет в официальных пакетах github.com/h0tc0d3/arch-packages Плюс где-то программы даже свежее.
anatoly314 нет никакой проблемы, такие компании в принципе сразу видны по тому какой ремонт, какая техника в офисе, есть ли кофе машина и т.д. Просто придираться начинают не редко на последнем собеседовании, когда прошел все тесты и собеседования, и когда обсуждаются детали трудового договора. Просто прерываю переговоры словами, что из разговора понял, что они слишком хороши для меня и не достоин работать в такой замечательной компании, встаю, прощаюсь и ухожу.
Вы не поняли, а вот вас понял сразу. Был просто раскрыт термин LTO для понимания его смысла. Потому что на русском нормально написать LTO оптимизация. В тексте было просто раскрытие термина. Это было сделано в первую очередь для тех кто не знаком с терминологией. На самом деле очень долго подбирал слова, чтобы текст был понятен не профессионалам, и чтобы профессионалов не задеть. В том предложении поэтому остановился на таком варианте. Масло масленое заметил еще когда писал статью, но остановился на таком варианте написания.
Нет, это делают с другой целью, занизить самооценку, снизить цену и взять вас горячим подешевле. У рекрутеров чем дешевле они взяли специалиста тем выше премия. У меня лично много грамот, наград, сертификатов, есть запись в трудовую, что отмечен на работе наградой. Все собеседования и тестирования прохожу с первого раза и с максимальным балом. Но вот при трудоустройстве не редко слышал очень много просто неадекватных придирок в свой адрес, то сертификаты у меня поддельные, то не может быть человек таким хорошим специалистом сразу в нескольких областях, то вы это не знаете, а стоит разобраться, оказывается это они не знают даже простых и банальных вещей… Это к сожалению в дали от крупных городов стало нормой, и в крупных городах тоже… Единицы есть адекватные компании, где к сотрудникам отношение как к людям, а не рабам…
Вот к примеру баг llvm с которым лично столкнулся и там даже отписался bugs.llvm.org/show_bug.cgi?id=49915
И да и нет. В вашем случае вероятно можно просто обойтись сигнатурной фильтрацией трафика, и боты создают уникальный отпечаток трафика и повторяющиеся пакеты. Тут просто клиент платит за свою безграмотность, что не смог отфильтровать фаерволом сам. На безграмотности сейчас зарабатывают все, и в данном случае морально этические нормы не нарушены. Никто не должен заниматься обучением людей, а если они хотят учится пусть учатся на своих ошибках и деньгах. Да и многим проще не думать и заплатить другим…
Как же мне это знакомо. Очередной трейдер из разряда плохому танцору даже яйца мешают… Такие не видят своих ошибок. Первая ошибка это торговля в слишком в волатильное время, просто увеличивается дисперсия стратегии, и сильнее разброс от математического ожидания. Можно забить в мой симулятор математического ожидания h0tc0d3.github.io/evtools/#/en/ev.html
Quantity — количество сделок, поставить 200.
Deviation RSD — относительное отклонение, по умолчанию это процент от риска(больше подходит для трейдинга так как с ростом риска чаще всего увеличивается еще дисперсия портфеля), напротив есть переключатель Amount of lose/EV риск/мат. ожидания, поставить для начала 50%(и quantity 20), а потом 150%(и quantity 200) и сравнить как будут распределены вероятности вписывающиеся в 1-4 сигмы(черная линия мат.ожидание, цветные случайная симуляция и разброс стратегии в зависимости от дисперсии), и где будут длиннее просадки.
Вообще кто торгует интрадей обычно первые 30-60 минут открытия дня не торгуют, и последний час, плюс не торгуют 5-30 минут после клиринга и после открытия американской сессии. На новостях тоже не торгуют — высокая волатильность, многие убыточны в это время, чаще всего на новостях первое время движение будет противоположное новости, так крупные игроки сбрасывают позиции и обманывают рынок, а потом резко идет разворот в сторону новости. Для таких как раз придумали вести статистику и разбор сделок, по статистике сразу видно в какие часы открывались самые убыточные сделки и чаще всего они будут в то время про которое написал выше. Зачастую, если выкинуть такие часы из торговли, убыточный трейдер может начать зарабатывать т.к. всю заработанную прибыль сливал в самые волатильные часы. В роботы не редко люди закладывают расчет волатильности, чтобы отключать их при резком росте. По 100 сделок в минуту это совсем не здоровая торговля, непонятный скальпинг на высокой волатильности где системы риск менеджмента дают сбой.
en.wikipedia.org/wiki/Interprocedural_optimization
johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html
alsoijw
Да LLVM IR. LLVM использует свой язык описания для описания многих структур поэтому псевдокод не является ошибкой. Пример github.com/llvm/llvm-project/commit/5b149c437194d10877e9e45b3d8cc9252af1944b
perf в помощь. У меня лично загрузка процессора упала при вызове API ядра. Пересборка остальных программ где-то быстрее где-то медленнее. В общем дало выигрыш хороший, упала загрузка процессора, стало меньше потребление памяти, анимации стали плавнее и производительнее. Сложно оценивать производительно современных компиляторов, в одних программах код будет быстрее в других наоборот. У меня есть бенчмарки для себя, где-то GCC выигрывает почти в 2 раза в скорости, где-то clang оказывается в раза 2 быстрее. clang в первую очередь дает более прогнозируемый код и не ломает поведение. Мне известны случаи когда GCC ломал поведение программ в случае переоптимизации, и поэтому разработчики программ отключали некоторые типы оптимизаций. Как знаю, в случае с рекурсивными вызовами их производительность будет увеличена в LLVM 13, но рекурсия в принципе является плохим тоном программирования и лучше ее избегать, переписывать алгоритм где есть возможность.
Не запускается, мой скрипт просто уменьшает количество действий, при установке все равно нужен sudo пароль. В принципе можно в крон или системд его прописать под рутом, и убрать проверку рута. Но сборка под рутом является плохим тоном.
Мне не нужно собирать все. Дистрибутив выбран по принципу самое свежее ПО. Критические программы у меня собираются вручную. Arch Linux для этого хорошо создан и все делается удобно, можно автоматизировать сборку. У меня сборка всего критического автоматизирована, плюс где-то есть патчи которых нет в официальных пакетах github.com/h0tc0d3/arch-packages Плюс где-то программы даже свежее.