WASD1 ссылок нет, вполне логичная интерпретация. Выше уже был дан ответ, почему накладные расходы на переключение выше при использовании средств ОС. И в статье есть картинка иллюстрирующая это, похожие картинки есть в интернете по запросам Hyper-Threading, Intel HT, Simultaneous Multithreading, AMD SMT. Можно добавить еще, что в случае вытесняющей многозадачностью с таймером происходит прерывание, а все прерывания, как нас раньше учили самые дорогие операции для процессора. А в случае кооперативной многозадачности, мы можем не дождаться, что поток нам даст управление т.к. он должен делать это вручную, и при этом может простаивать. В случае с HT и SMT работает простой принцип если конвеер процессора простаивает происходит автоматические переключение на симметричный поток. Для понимания его принципа работы 99% людей этого более чем достаточно. Это все есть на картинке, где показан принцип работы. Могу предположить, что еще предсказание переходов лучше работает при HT и SMT, и отсюда тоже чуть лучше будет производительность. Если человек не занимается слишком низкоуровневым программирование, и низкоуровневой оптимизацией кода или производством процессоров, глубже нет смысла углубляться.
LynXzp у меня не было цели максимально достоверно донести, как работает вытесняющая многозадачность, если углубляться в тему там еще много нюансов. Это тема отдельной статьи. Наоборот цель была передать человеку незнакомому с устройством ОС максимально просто смысл происходящего в ядре ОС. Моя задача не писать сложным языком о сложных вещах, моя задача уменьшить разрыв в знаниях у специалистов и показать, что в реальности все очень просто.
13werwolf13 может и так. Просто у арча самые удобные для чтения скрипты сборки и нравится как сам дистрибутив устроен, но честно раньше я не ожидал, что там мейнтейнеры р*дяи, и тоже в скриптах сборки много грязи. Я им даже патчи на блюдечке преподносил для нескольких пакетов, чтобы они взяли и обновили зависимые пакеты. Все дистрибутивы это сделали, а они там что-то телятся, и многие совсем не умеют читать баги в астриме и писать патчи. Лично перерабатываю каждый скрипт сборки, смотрю багрепорты, оптимизирую код сборки, удаляю костыли времен царя гороха, где-то добавляю свои самопальные патчи, где могу сам решить проблему. Переход для меня не имеет смысл, уже на пути создании своего дистрибутива. В день просматривают не мало багрепортов и по объему написанных патчей RedHat впереди всех, больше всего багов они закрывают, но скрипты сборки тяжелые у них. Насчет универсальной сборки под arch, redhat, debian это не сложно сделать, все собирается в clean chroot просто разный упаковщик пакетов, главная проблема, что везде по разному именуются зависимости, вот это думаю они не смогли решит, иначе пакет будет сразу в себе все зависимости содержать, чтобы не ломать его работу.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
То есть, первый ответ Apple, в котором они признали проблему после получения видео с демонстрацией, вы не заметили случайно или притворяетесь шлангом в попытках отстоять свое мнение?
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Кто действительно разбирается, тому вполне достаточно идеи, описанной в статье для объективной оценки подобного вектора атаки.
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Для того, чтобы оценить вкус молока, не обязательно быть коровой, которая его производит.
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
Какого уровня? Из статьи даже не понятно были ли уязвимость на самом деле, и куча воды с размышлениями в сферическом вакууме. За такие уязвимости никогда не платили. Судя по статье, из Apple ему готовы были заплатить довольно приличную сумму за то, что даже уязвимостью нельзя назвать. И не была проведена успешная атака, и еще главное у человека совсем туго с комбинаторикой. Статья просто хайповая, не более того… И кто действительно разбирается, понимает, что статья это полная вода, и сложность атаки значительно сложнее чем написана в статье и за такую «уязвимость» $18000 это переплата с лихвой. Такую уязвимость ни одна уважающая себя security компания не купит. Сколько уязвимостей вы нашли сами и продали, чтобы рассуждать, что заплатили мало и это плевок в лицо?
ЧСВ у автора в статье просто зашкаливает. Так и не была показана успешная реализация атаки, куча теоретических рассуждений в сферическом вакууме, и много текста о том какой автор молодец… В конце убило, что автор отказался от вознаграждения в $18000, ведь он такой молодец и достоин минимум награды в $100000, а лучше в $250000. Не говоря про то, что много воды.
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...
@SnikeMK причина совсем в другом, причина в накрученных статьях, и программе поощрения авторов. С одной стороны это хорошо платить за хорошие статьи, но к сожалению получается так, что это наоборот поощряет не честную игру и поток шлаковых статей. Выгоднее писать плохие статьи и накручить, с этого живут команды авторов и разные конторы предлагающие услуги написания статей. На этом на днях поймали очередную компанию на хабре и она сильно просела в рейтинге. Увы, но качественные статьи просто тонут в общей массе и не набирают нужного количества голосов, про это уже указывал редактору RU_VDS, что нужно вводить лучшую фильтрацию статей, они платят за статьи деньги, и очень много статей просто не стоят тех денег, что за них платят. Плюс на накрученные статьи даже невозможно возразить, и иметь критическое мышление, надо быть "бараном" и засунуть свой опыт себе в одно место, иначе тебя сеткой ботов заминусуют моментально, так как критиковать безграмотных авторов не положено, и хабр уже не лучшая ИТ площадка, а форум домохозяек. Не реально конкурировать, когда многие играют не честно. Поэтому уже много лет назад произошел отток грамотных авторов и более грамотной аудитории. Про деградацию хабра уже писали везде где можно, такие компании как майл.ру которые раньше были в топе хабра и много писали, уже практически не пишут. Честно говоря когда хабр был в управлении маил.ру такого беспорядка не было, все началось после возврата проекта автору хабра и слияния всех площадок типа Geektimes в одну.
@Drag13 с разработчиками v8 как раз согласен, но чаще всего это просто не грамотный код, а не размер. Как раз после того как почитал разработчиков v8 начал внимательнее относится к стилям и JS коду. Кстати могу предположить, что там такое длинное время AOT это оптимизация больших и медленных библиотек типа jquery. В движке v8 есть специальные оптимизации для всех крупных JS библиотек, лично давно уже не использую сторонние библиотеки кроме vue, react и angular т.к. большая часть из них очень-очень медленные. Даже десяток строк кода может замедлить отрисовку, банально когда стили в рантайме обновляются не пакетно, а каждый стиль изменяется отдельно и тригерит перерисовку.
@Drag13 даже на мобильных девайсах старых и на айпаде втором не проблема, лично проверял. По первой ссылке вообще непонятная граф, там почти секунду происходит компиляция и 500мс парсинг, это совсем ужас, там походу что-то блокирует во время загрузки, или код ужасный и поэтому такие тайминги. Даже большие файлы парсятся за миллисекунды.
@Drag13 распарсить это самое простое, там используется токенизация и посимвольное чтение, там скорости парсинга огромные и моментальное можно мегабайтные файлы парсить. По моему опыту, как раз больше всего времени занимает сборка мусора - следствие не правильного использования переменных, и выполнение плохого оптимизированных участков кода. Со стилями вот сложнее там используется перерасчет стилей. Профилировщик это все показывает. Вот пример моего относительно тяжелого и быстрого https://h0tc0d3.github.io/evtools/https://h0tc0d3.github.io/hamster/
@Self_Perfection это пакеты для Arch Linux с лучшей оптимизацией и производительностью чем стандартные, и собранные с помощью clang и llvm. Они для лучшего отклика системы и чтобы OC работала шустрее. Чем грамматика не верна?
Вот мое 225кб https://archlinux.club/ полностью резиновый дизайн, есть анимации, вес больше всего создают кастом шрифты. Вообще размер сайта на производительность не влияет. Чаще всего размер это картинки они на скорость отрисовки мало влияют, если не совсем огромные. На производительность влияет качество JS и CSS люди не смотрят на качество кода и отсюда медленный рендеринг, всякие левые библиотеки, которые тянут копипаст программисты снижают производительность. К примеру ради быстрого рендеринга много лет назад отказался от reset css и normalize, и их аналогов, они в принципе даже не нужны, только лишние правила и лишние затраты на расчет стилей, все равно на нормальных сайтах почти все переопределенно по сравнению с дефолтными стилями браузера.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
@dlinyj Спасибо за отзыв.
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...
@SnikeMK причина совсем в другом, причина в накрученных статьях, и программе поощрения авторов. С одной стороны это хорошо платить за хорошие статьи, но к сожалению получается так, что это наоборот поощряет не честную игру и поток шлаковых статей. Выгоднее писать плохие статьи и накручить, с этого живут команды авторов и разные конторы предлагающие услуги написания статей. На этом на днях поймали очередную компанию на хабре и она сильно просела в рейтинге. Увы, но качественные статьи просто тонут в общей массе и не набирают нужного количества голосов, про это уже указывал редактору RU_VDS, что нужно вводить лучшую фильтрацию статей, они платят за статьи деньги, и очень много статей просто не стоят тех денег, что за них платят. Плюс на накрученные статьи даже невозможно возразить, и иметь критическое мышление, надо быть "бараном" и засунуть свой опыт себе в одно место, иначе тебя сеткой ботов заминусуют моментально, так как критиковать безграмотных авторов не положено, и хабр уже не лучшая ИТ площадка, а форум домохозяек. Не реально конкурировать, когда многие играют не честно. Поэтому уже много лет назад произошел отток грамотных авторов и более грамотной аудитории. Про деградацию хабра уже писали везде где можно, такие компании как майл.ру которые раньше были в топе хабра и много писали, уже практически не пишут. Честно говоря когда хабр был в управлении маил.ру такого беспорядка не было, все началось после возврата проекта автору хабра и слияния всех площадок типа Geektimes в одну.
@Self_Perfection ответил вам в личных сообщениях.
@Aldrog если не сложно опишите подробнее ошибки в личном сообщении.
@Drag13 с разработчиками v8 как раз согласен, но чаще всего это просто не грамотный код, а не размер. Как раз после того как почитал разработчиков v8 начал внимательнее относится к стилям и JS коду. Кстати могу предположить, что там такое длинное время AOT это оптимизация больших и медленных библиотек типа jquery. В движке v8 есть специальные оптимизации для всех крупных JS библиотек, лично давно уже не использую сторонние библиотеки кроме vue, react и angular т.к. большая часть из них очень-очень медленные. Даже десяток строк кода может замедлить отрисовку, банально когда стили в рантайме обновляются не пакетно, а каждый стиль изменяется отдельно и тригерит перерисовку.
@Drag13 даже на мобильных девайсах старых и на айпаде втором не проблема, лично проверял. По первой ссылке вообще непонятная граф, там почти секунду происходит компиляция и 500мс парсинг, это совсем ужас, там походу что-то блокирует во время загрузки, или код ужасный и поэтому такие тайминги. Даже большие файлы парсятся за миллисекунды.
@Drag13 распарсить это самое простое, там используется токенизация и посимвольное чтение, там скорости парсинга огромные и моментальное можно мегабайтные файлы парсить. По моему опыту, как раз больше всего времени занимает сборка мусора - следствие не правильного использования переменных, и выполнение плохого оптимизированных участков кода. Со стилями вот сложнее там используется перерасчет стилей. Профилировщик это все показывает. Вот пример моего относительно тяжелого и быстрого https://h0tc0d3.github.io/evtools/ https://h0tc0d3.github.io/hamster/
@na9ort спасибо.
@Self_Perfection это пакеты для Arch Linux с лучшей оптимизацией и производительностью чем стандартные, и собранные с помощью clang и llvm. Они для лучшего отклика системы и чтобы OC работала шустрее. Чем грамматика не верна?
Вот мое 225кб https://archlinux.club/ полностью резиновый дизайн, есть анимации, вес больше всего создают кастом шрифты. Вообще размер сайта на производительность не влияет. Чаще всего размер это картинки они на скорость отрисовки мало влияют, если не совсем огромные. На производительность влияет качество JS и CSS люди не смотрят на качество кода и отсюда медленный рендеринг, всякие левые библиотеки, которые тянут копипаст программисты снижают производительность. К примеру ради быстрого рендеринга много лет назад отказался от reset css и normalize, и их аналогов, они в принципе даже не нужны, только лишние правила и лишние затраты на расчет стилей, все равно на нормальных сайтах почти все переопределенно по сравнению с дефолтными стилями браузера.