С LSP можно вставлять доп. элементы отображения, о чём я и писал. Набирать меньше, видеть больше.
Сложнее реализация - естественно. Кеширование промежуточных представлений давно придумали для больших проектов. Не нужно перебирать всё каждый раз.
Я про простоту реализации компилятора для синтаксиса C и вырвиглазный синтаксис Rust с его переусложнённым компилятором. Все ЯП имеют опр. цели и из поста мне непонятно, что за объективные цели у данного ЯП раз разработчик волнуется о синтаксисе.
Так я про то, что объявлять их обычно не нужно. Напр., объявлена функция или переменные с типами. Либо всё соответствуют по вычисленным типам, либо нет. Это LSP и компилятор вычислят и поймают. Зачем программисту это постоянно прописывать?
А писать их везде явно - бред, LSP вам в помощь и не болейте C++ портянками шаблонов.
Создатели ЯПшек, зачем вам доп. символы перед функциями? Сигнатура функции же ф()|ф(p0:t0 p1:t1) или ф:|ф:p0:t0 p1:t1: и т.п.. Если сигнатуры не пересекаются с другими объявлениями, то зачем специально указывать, что это функция? Для простоты компилятора есть C , для вырвиглазного синтаксиса есть Rust , а зачем вот это вот всё? Всегда не мог понять, зачем люди усложняют жизнь другим людям при разработке синтаксиса ЯП? Возьмите стандартную раскладку, попробуйте понабирать спецсимволы и удалите все, что требуют слишком много странных движений (оставшийся набор станет очень мал). Строго типизированный ЯП точно не взлетит, т.к. к удобству набора кода они имеют околонулевое отношение. Большинство типов переменных легко вычисляется на основе использования в коде. Подсветку таких типов и их несоответствие можно убрать в LSP. Т.е. мин. информации и писанины в тексте и макс. информации с LSP.
Ещё, заглавные и строчные во встроенных элементах ЯП - зло. Либо всё одним, либо только строчные.
Я смотрю на это с точки зрения физики. Любой запрос стоит ресурсов (платный). Чем раньше отрубишь запрос тем меньше ресурсов серверам нужно потратить (во всей цепочке прохождения пакета от клиента до сервера). Любой запрос, что имеет околонулевую вероятность конверсии в оплату, можно слать в лес, если брать только экономический баланс. И там 3.6 млн. "китайцев" в сутки ломилось, т.е. в ~$10 в месяц сверху бы ему это встало только на запросах, если не считать, что это число может вырасти (всякие сайты с БЖУ и пр. фигнёй парсят часто и иногда жёстко). CF тоже не впёрлось отдавать по каждому бесплатному клиенту 10 млн. запросов в день, поэтому у них там и своя фильтрация есть.
На пустой сервак у меня иногда до 100 уникальных IPшников пробивается с ipset с чёрными списками (подсетями). С серыми списками перед чёрными проходит максимум пара десятков. Без этого логи они забивают быстро, ненужной фигнёй (без учёта простого дропа по портам и лимитам). Большая часть - запросы на уязвимые url всяких CMS/.NET/Python/NodeJS и пр. серверов.
"Сама по себе борьба против участия мужчин в соревнованиях для женщин ничем обоснована быть не может, ибо мужчины действуют на благо Франции от имени и по поручению женщин."
По теме статьи: сеть на доверии всегда будет служить злоумышленникам (цена свободы).
Как там писал один лисповод "Худшее всегда побеждает" или что-то в этом роде.
У меня больше вопросов к протоколам пониже, т.к. html+js можно закешировать один раз и 304-кой отвечать (или как сейчас принято ServiceWorker крутить, чтобы даже сервер не пришлось дёргать после первого раза до очистки данных для origin), а дальше по WS/HTTP гонять код в виде байт кода для своей нано-VM и данные.
Но так никто не станет работать со стороны бизнеса для создания фронта (текст простит многое, а бинарь - нет). Текст проще обрабатывать людям (http оттуда же).
С точки зрения браузера - текст (нельзя от него просто избавиться) + бинарь поддерживать как форматы для одного и того же это просто источник ошибок, неодинакового поведения и затрат при обновлении.
Обычно сайты свои ServiceWorker'ы пихают, базы данных и пр. Особенно доставляет там, где только один раз текст и картинки смотришь, а оно тебе кучу всего сверху накидывает на всякий случай. Были/есть директивы в html/http заголовках для этого.
В самом YB по времени + лимитам по памяти старые страницы выгружаются намного чаще (на моём линуксе браузер в лимит на 4Гб на всю систему укладывается, но обычно нужно что-то ещё делать кроме браузера). На андроид у них есть YB Lite, могли бы и для десктопов собирать лёгкую упрощённую версию.
А так, минимальная сборка v8 вроде 30-50 метров занимает (бинарь на базе v8 со скриптами и статичными либами 41 метр в файловой системе лежит, когда-то было 12 и меньше, но те древние времена давно прошли). Плюс мегабайты всякой фигни страниц (открыл статью на хабре и у меня почти 15Мб насчитало просто в загрузке, а потребление памяти 46Мб только v8+DOM+JS и растёт до 52 пока там GC не подчистит и снова, дичь неоптимизированная в коде происходит судя по всему), встроенных расширений и изолированные копии v8 (надеюсь) на каждый origin. Ещё много всякого нужного для современных стандартов веба изолировано в каждой копии. Сверху телеметрии, логирование, свистоперделки и пр. радости современных продуктов.
Видно вы не поняли, что я имею ввиду под синхронизацией для асинхронности. Это память, неважно где, в которой записано, что нужно пнуть подзадачу с такой-то точки исполнения при опр. условиях. Если не сохранить точку синхронизации исполнения, то асинхронность невозможна, т.к. невозможно продолжить прерванное исполнение подзадачи. Если такой синхронизации нет, то подзадача не асинхронна.
Много вопросов к сваливанию в кучу доп. абстракций разных уровней. Есть ли планировщик задач, как он работает, что есть потоки для планировщика, что есть задачи для планировщика, что за ядра процессора, какое исполнение на ядрах процессора, бесконечное и т.д. и т.п.?
Вот пишу unikernel и организовать исполнение задач можно синхронно/параллельно/асинхронно. Можно отключить прерывания (точки синхронизации для асинхронщины) и асинхронность становится простой абстракцией без ног. Если отключить доп. ядра, то параллельность уже не добавишь никак. Если отключить и последнее ядро, то и задачки уже не порешать никак. Отсюда приходит мысль, что синхронные вычисления первичны, параллельность синхронных вторична, а асинхронность на самом деле простая абстракция без ног, которой нет разницы на чьей шее сидеть.
Асинхронность предполагает точку синхронизации (когда можно продолжить исполнение след. куска подзадачи - пресловутые await), если нет синхронизации, то её нет. Разрыв исполнения подзадачи должен быть, чтобы назвать её асинхронной. Параллельность - про исполнение подзадач одновременно. Без синхронизации в ней не будет асинхронности, т.к. не будет логического разрыва исполнения.
Т.е. 128b/130b, 64b/66b, 8b/10b кодирование это враньё? Я думал о чём-то таком (8b/6t) https://en.wikipedia.org/wiki/4B3T Лучше от 128b/Nt, чтобы было ближе к макс. плотности. Если там плотнее кодируется нормально, то неплохо, но тройка всё равно должна давать максимум плотности при 3, 9, 27 и т.д. уровнях на такт.
Edit: Хотя по энергоэффективности выгоднее пару линий с PAM-3 и (M)b/(N)t кодировкой, т.к. 9 уровней это слишком жёстко.
У Ethernet протокола на 1Гбит там 1.25+Гбит на физ. уровне. И такие люди будут думать о выгоде в 1.5+ раза по плотности информации для передачи? Бред же. Потом добавьте потери скорости при перекодировании из двоичной в троичную и обратно. Ещё меньше людей будет о таком думать. Элементная база нужна + толстый заказчик, т.к. на малых объёмах экономика не экономит. Круг заинтересованных людей сужается в точку.
Если бы все думали, что все за них уже всё подумали, то сидели бы мы в какой-нибудь пещере нынешней Франции. Если у вас есть мат./физ. док-ва, что это невозможно, то кидайтесь ссылками, чтобы и меня просветить.
Тройка оптимальна для многих реальных задач (те же задачки с гирями), т.к. теоретически получается макс. плотность информации на единицу трёхстабильного элемента.
Минус только в сложности переключения в трёхстабильных элементах (либо энергопотребление большое, либо переключение долгое, либо другие минусы). Хотя патенты только в путь клепают по ним, но из них не очень ясно приемлемы ли они для реального применения или просто кто-то вышел покурить-подумать и придумал фигню.
Для передачи большого кол-ва информации лучше использовать троичную систему (напр. на оптоволокне и спец. лазерах), т.к. 661578 разряд в троичной хранит больше информации чем 1048576 разрядов в двоичной и нужно передавать сигнал в ~1.584962 (для 64 байтов [мин. ethernet пакет] - 512 бит, что меньше информации в 324 тритах, кол-во необходимых сигналов для передачи сокращается в ~1.580247 раз) раза меньшее кол-во раз - время передачи сокращается, расход энергии сокращается. Больше информации за раз - больше экономия. Напр., для видео/аудио и пр. больших объёмов, для небольших - лучше двоичными, т.к. там разница в ~1.5 раза и выгода от использования пары трёхстабильных элементов для передачи троичных данных стремится к 0.
Т.е. и троичный процессор должен работать с блоками, а не с отдельными тритами (SIMD), чтобы выгода была отлична от 0 по объёму схемотехники и энергопотреблению. Т.е. не для обычных пользователей, т.к. кач-во кода в таких системах не впечатляет (от ОС и до пользовательских программ).
"VLESS Reality сигнатуры не имеет" - как бы статистический анализ должен работать вне зависимости от транспорта (статистическая сигнатура сильно отличается от нормы, в чёрный список, а IP ограничены). Запихали медиа в трубу и на другом конце не белосписочное хранилище медиа? Выглядит подозрительно, Чебурнет такого не допустит. А сайтики смотреть - проблем не должно быть больших, если не слишком много и часто (тоже подозрительно и сайты не помогают - постоянно шлют дичь и с нескольких источников канал будет толще нормы всегда). Белосписочные реле, но им тоже всё это видно. Любой предопределённый поток имеет сигнатуру. Всё равно, что всё зашифровано известным ключём. И подражать потоком одной плотности потоку с меньшей плотностью - удачи, расскажите потом сколько кбит/с у вас на источник данных в итоге выходит.
Любой контакт, что вы не инициировали - скорее всего развод (начальник/родственник/скамер/и т.д. нашёл лоха для своих целей). В телеге постоянно пишут (в качестве развлечения можно пописать в ответ с помощью чат гопоты какой-нибудь, но быстро надоедает).
Схема простая - перегрузить мозг данными и пока он пытается вытянуть из них информацию отдавать команды почти без обработки мозгом. DoS + усиливающаяся из-за этого уязвимость в виде непрямого управления. А если там DDoS по нескольким каналам, то ещё хуже (эмоциональных людей лучше изолировать от себя при любых серьёзных контактах, т.к. они будут мощной доп. нагрузкой из-за которой вас могут развести как лоха).
Т.е. защититься от этого сложно (сам когда-то давно попался на развод, хоть и контакт инициировал сам и там схема с подменой целевого контакта была, но мозг так работает, что можно им управлять извне в опр. условиях), если команды в мозг отправляют довольно простые по нагрузке (мозг любит экономить на вычислениях): кликни здесь, напечатай под диктовку / по буквам (если нужно самому где-то вычитать и печатать [много], то уже мозг получит время подумать "а нафига? нормально же было, ничего не делал, что тут началось?") и т.п. простые операции. Но современные сервисы даже в критических местах спроектированы под простоту и скам процветает. Но это нужно через регуляторов продавливать, чтобы на автопилоте нельзя было работать с критичными данными/доступами.
Лучше на железку арбузы кидать, т.к. это материальное что-то, а не ссылка динамическая. Бороться с доменами довольно бесполезно (хотя РКН пытается, уровень компетенций печален).
256MiB (со всем, что я там наделал. с prefetcht0 на 0.2-0.35ms дольше исполняется чем с prefetchnta, а так стабильно предзагрузка лучше) AVX2 normal assembly sum: Sum=134216776.000; best time = 57.612553ms AVX2 prefetch assembly sum: Sum=134216776.000; best time = 56.600445ms
цикл развёрнут на все 16 регистров (предзагрузке чуть хуже становится, обычному варианту на % лучше): AVX2 normal assembly sum: Sum=134225120.000; best time = 57.081848ms AVX2 prefetch assembly sum: Sum=134225120.000; best time = 56.624981ms
Рандом (одинаково или так): Random load NO prefetch : 216 cycles Random load WITH prefetch: 180 cycles Improvement: +16.67 %
Тогда `prefetchnta` (и положить в регистр) и просто не мусорить в кеш. Это намного быстрее, чем мусорить в кеш с помощью железки. Но также как и железка этот вариант будет добавлять DRAM refresh задержки в общую обработку случайным образом, т.к. окно (только понял, что это основное, что хотел донести изначально) предзагрузки слишком маленькое, чтобы оно не влияло на результат.
Предзагрузка - чтобы работать как конвеер из стиралок и сушилок, а не как стиралка-сушилка (железный вариант обязателен для старого софта, а так - часто мешает, вспомнить хотя бы мусорные кеш линии для ограждения данных потоков). Задача - скрыть время доступа к внешней памяти.
Сомневаюсь, что железный предзагрузчик может скрыть почти 1us DRAM refresh (некоторые работы в этой области намекают, что точно не может и все решения memory bound задач просто живут с этими непредсказуемыми задержками), т.к. типичный доступ к памяти не занимает много сотен наносекунд. Если взять доступ L1d за 4-5 циклов, то на 5GHz ядре один DRAM refresh это провал по времени почти в 1000000 кеш линий (почти 64KiB, если обработка <1 цикла на кеш линию), а т.к. там нужна синхронизация на это время все полученные параллельно из памяти кеш линии для ядра будут ждать "неудачную" (попала в банку с DRAM refresh) предзагрузку кеш линии. И если нет предзагруженного буфера почти в 64KiB хотя бы в L3 работа будет просто останавливаться на сотни наносекунд.
Будем мы их сразу использовать или нет не имеет значения. Там LRU, поэтому при нагрузке на кеш предзагрузка теряет свою эффективность настолько, что предзагружать много кеш линий задолго до их обработки становится вредно (т.к. железная предзагрузка ещё добавит нагрузки на кеш).
Запрет вытеснения это хорошо, но что-то всё равно будет вытеснено, а магия это плохо.
Отражатели стоят копейки, а панели - нет. КПД повышается, стоимость за единицу собранной энергии уменьшается
Ошибся, имел в виду явное объявление типов
С LSP можно вставлять доп. элементы отображения, о чём я и писал. Набирать меньше, видеть больше.
Сложнее реализация - естественно. Кеширование промежуточных представлений давно придумали для больших проектов. Не нужно перебирать всё каждый раз.
Я про простоту реализации компилятора для синтаксиса C и вырвиглазный синтаксис Rust с его переусложнённым компилятором. Все ЯП имеют опр. цели и из поста мне непонятно, что за объективные цели у данного ЯП раз разработчик волнуется о синтаксисе.
Так я про то, что объявлять их обычно не нужно. Напр., объявлена функция или переменные с типами. Либо всё соответствуют по вычисленным типам, либо нет. Это LSP и компилятор вычислят и поймают. Зачем программисту это постоянно прописывать?
А писать их везде явно - бред, LSP вам в помощь и не болейте C++ портянками шаблонов.
Создатели ЯПшек, зачем вам доп. символы перед функциями? Сигнатура функции же
ф()|ф(p0:t0 p1:t1)илиф:|ф:p0:t0 p1:t1:и т.п.. Если сигнатуры не пересекаются с другими объявлениями, то зачем специально указывать, что это функция? Для простоты компилятора естьC, для вырвиглазного синтаксиса естьRust, а зачем вот это вот всё? Всегда не мог понять, зачем люди усложняют жизнь другим людям при разработке синтаксиса ЯП? Возьмите стандартную раскладку, попробуйте понабирать спецсимволы и удалите все, что требуют слишком много странных движений (оставшийся набор станет очень мал). Строго типизированный ЯП точно не взлетит, т.к. к удобству набора кода они имеют околонулевое отношение. Большинство типов переменных легко вычисляется на основе использования в коде. Подсветку таких типов и их несоответствие можно убрать в LSP. Т.е. мин. информации и писанины в тексте и макс. информации с LSP.Ещё, заглавные и строчные во встроенных элементах ЯП - зло. Либо всё одним, либо только строчные.
Всем читающим - не плодите сущности, пожалуйста.
Я смотрю на это с точки зрения физики. Любой запрос стоит ресурсов (платный). Чем раньше отрубишь запрос тем меньше ресурсов серверам нужно потратить (во всей цепочке прохождения пакета от клиента до сервера). Любой запрос, что имеет околонулевую вероятность конверсии в оплату, можно слать в лес, если брать только экономический баланс. И там 3.6 млн. "китайцев" в сутки ломилось, т.е. в ~$10 в месяц сверху бы ему это встало только на запросах, если не считать, что это число может вырасти (всякие сайты с БЖУ и пр. фигнёй парсят часто и иногда жёстко). CF тоже не впёрлось отдавать по каждому бесплатному клиенту 10 млн. запросов в день, поэтому у них там и своя фильтрация есть.
На пустой сервак у меня иногда до 100 уникальных IPшников пробивается с ipset с чёрными списками (подсетями). С серыми списками перед чёрными проходит максимум пара десятков. Без этого логи они забивают быстро, ненужной фигнёй (без учёта простого дропа по портам и лимитам). Большая часть - запросы на уязвимые url всяких CMS/.NET/Python/NodeJS и пр. серверов.
Физика: "иду я нафиг".
"Сама по себе борьба против участия мужчин в соревнованиях для женщин ничем обоснована быть не может, ибо мужчины действуют
на благо Францииот имени и по поручению женщин."По теме статьи: сеть на доверии всегда будет служить злоумышленникам (цена свободы).
Как там писал один лисповод "Худшее всегда побеждает" или что-то в этом роде.
У меня больше вопросов к протоколам пониже, т.к. html+js можно закешировать один раз и 304-кой отвечать (или как сейчас принято ServiceWorker крутить, чтобы даже сервер не пришлось дёргать после первого раза до очистки данных для origin), а дальше по WS/HTTP гонять код в виде байт кода для своей нано-VM и данные.
Но так никто не станет работать со стороны бизнеса для создания фронта (текст простит многое, а бинарь - нет).
Текст проще обрабатывать людям (http оттуда же).
С точки зрения браузера - текст (нельзя от него просто избавиться) + бинарь поддерживать как форматы для одного и того же это просто источник ошибок, неодинакового поведения и затрат при обновлении.
Обычно сайты свои ServiceWorker'ы пихают, базы данных и пр. Особенно доставляет там, где только один раз текст и картинки смотришь, а оно тебе кучу всего сверху накидывает на всякий случай.
Были/есть директивы в html/http заголовках для этого.
В самом YB по времени + лимитам по памяти старые страницы выгружаются намного чаще (на моём линуксе браузер в лимит на 4Гб на всю систему укладывается, но обычно нужно что-то ещё делать кроме браузера). На андроид у них есть YB Lite, могли бы и для десктопов собирать лёгкую упрощённую версию.
А так, минимальная сборка v8 вроде 30-50 метров занимает (бинарь на базе v8 со скриптами и статичными либами 41 метр в файловой системе лежит, когда-то было 12 и меньше, но те древние времена давно прошли). Плюс мегабайты всякой фигни страниц (открыл статью на хабре и у меня почти 15Мб насчитало просто в загрузке, а потребление памяти 46Мб только v8+DOM+JS и растёт до 52 пока там GC не подчистит и снова, дичь неоптимизированная в коде происходит судя по всему), встроенных расширений и изолированные копии v8 (надеюсь) на каждый origin. Ещё много всякого нужного для современных стандартов веба изолировано в каждой копии. Сверху телеметрии, логирование, свистоперделки и пр. радости современных продуктов.
Видно вы не поняли, что я имею ввиду под синхронизацией для асинхронности. Это память, неважно где, в которой записано, что нужно пнуть подзадачу с такой-то точки исполнения при опр. условиях. Если не сохранить точку синхронизации исполнения, то асинхронность невозможна, т.к. невозможно продолжить прерванное исполнение подзадачи. Если такой синхронизации нет, то подзадача не асинхронна.
Много вопросов к сваливанию в кучу доп. абстракций разных уровней. Есть ли планировщик задач, как он работает, что есть потоки для планировщика, что есть задачи для планировщика, что за ядра процессора, какое исполнение на ядрах процессора, бесконечное и т.д. и т.п.?
Вот пишу unikernel и организовать исполнение задач можно синхронно/параллельно/асинхронно. Можно отключить прерывания (точки синхронизации для асинхронщины) и асинхронность становится простой абстракцией без ног. Если отключить доп. ядра, то параллельность уже не добавишь никак. Если отключить и последнее ядро, то и задачки уже не порешать никак. Отсюда приходит мысль, что синхронные вычисления первичны, параллельность синхронных вторична, а асинхронность на самом деле простая абстракция без ног, которой нет разницы на чьей шее сидеть.
Асинхронность предполагает точку синхронизации (когда можно продолжить исполнение след. куска подзадачи - пресловутые await), если нет синхронизации, то её нет. Разрыв исполнения подзадачи должен быть, чтобы назвать её асинхронной. Параллельность - про исполнение подзадач одновременно. Без синхронизации в ней не будет асинхронности, т.к. не будет логического разрыва исполнения.
Т.е. 128b/130b, 64b/66b, 8b/10b кодирование это враньё?
Я думал о чём-то таком (8b/6t) https://en.wikipedia.org/wiki/4B3T
Лучше от 128b/Nt, чтобы было ближе к макс. плотности.
Если там плотнее кодируется нормально, то неплохо, но тройка всё равно должна давать максимум плотности при 3, 9, 27 и т.д. уровнях на такт.
Edit: Хотя по энергоэффективности выгоднее пару линий с PAM-3 и (M)b/(N)t кодировкой, т.к. 9 уровней это слишком жёстко.
У Ethernet протокола на 1Гбит там 1.25+Гбит на физ. уровне. И такие люди будут думать о выгоде в 1.5+ раза по плотности информации для передачи? Бред же.
Потом добавьте потери скорости при перекодировании из двоичной в троичную и обратно. Ещё меньше людей будет о таком думать.
Элементная база нужна + толстый заказчик, т.к. на малых объёмах экономика не экономит. Круг заинтересованных людей сужается в точку.
Если бы все думали, что все за них уже всё подумали, то сидели бы мы в какой-нибудь пещере нынешней Франции. Если у вас есть мат./физ. док-ва, что это невозможно, то кидайтесь ссылками, чтобы и меня просветить.
Тройка оптимальна для многих реальных задач (те же задачки с гирями), т.к. теоретически получается макс. плотность информации на единицу трёхстабильного элемента.
Минус только в сложности переключения в трёхстабильных элементах (либо энергопотребление большое, либо переключение долгое, либо другие минусы). Хотя патенты только в путь клепают по ним, но из них не очень ясно приемлемы ли они для реального применения или просто кто-то вышел покурить-подумать и придумал фигню.
Для передачи большого кол-ва информации лучше использовать троичную систему (напр. на оптоволокне и спец. лазерах), т.к. 661578 разряд в троичной хранит больше информации чем 1048576 разрядов в двоичной и нужно передавать сигнал в ~1.584962 (для 64 байтов [мин. ethernet пакет] - 512 бит, что меньше информации в 324 тритах, кол-во необходимых сигналов для передачи сокращается в ~1.580247 раз) раза меньшее кол-во раз - время передачи сокращается, расход энергии сокращается. Больше информации за раз - больше экономия. Напр., для видео/аудио и пр. больших объёмов, для небольших - лучше двоичными, т.к. там разница в ~1.5 раза и выгода от использования пары трёхстабильных элементов для передачи троичных данных стремится к 0.
Т.е. и троичный процессор должен работать с блоками, а не с отдельными тритами (SIMD), чтобы выгода была отлична от 0 по объёму схемотехники и энергопотреблению. Т.е. не для обычных пользователей, т.к. кач-во кода в таких системах не впечатляет (от ОС и до пользовательских программ).
"VLESS Reality сигнатуры не имеет" - как бы статистический анализ должен работать вне зависимости от транспорта (статистическая сигнатура сильно отличается от нормы, в чёрный список, а IP ограничены). Запихали медиа в трубу и на другом конце не белосписочное хранилище медиа? Выглядит подозрительно, Чебурнет такого не допустит. А сайтики смотреть - проблем не должно быть больших, если не слишком много и часто (тоже подозрительно и сайты не помогают - постоянно шлют дичь и с нескольких источников канал будет толще нормы всегда). Белосписочные реле, но им тоже всё это видно.
Любой предопределённый поток имеет сигнатуру. Всё равно, что всё зашифровано известным ключём. И подражать потоком одной плотности потоку с меньшей плотностью - удачи, расскажите потом сколько кбит/с у вас на источник данных в итоге выходит.
Любой контакт, что вы не инициировали - скорее всего развод (начальник/родственник/скамер/и т.д. нашёл лоха для своих целей). В телеге постоянно пишут (в качестве развлечения можно пописать в ответ с помощью чат гопоты какой-нибудь, но быстро надоедает).
Схема простая - перегрузить мозг данными и пока он пытается вытянуть из них информацию отдавать команды почти без обработки мозгом. DoS + усиливающаяся из-за этого уязвимость в виде непрямого управления. А если там DDoS по нескольким каналам, то ещё хуже (эмоциональных людей лучше изолировать от себя при любых серьёзных контактах, т.к. они будут мощной доп. нагрузкой из-за которой вас могут развести как лоха).
Т.е. защититься от этого сложно (сам когда-то давно попался на развод, хоть и контакт инициировал сам и там схема с подменой целевого контакта была, но мозг так работает, что можно им управлять извне в опр. условиях), если команды в мозг отправляют довольно простые по нагрузке (мозг любит экономить на вычислениях): кликни здесь, напечатай под диктовку / по буквам (если нужно самому где-то вычитать и печатать [много], то уже мозг получит время подумать "а нафига? нормально же было, ничего не делал, что тут началось?") и т.п. простые операции. Но современные сервисы даже в критических местах спроектированы под простоту и скам процветает. Но это нужно через регуляторов продавливать, чтобы на автопилоте нельзя было работать с критичными данными/доступами.
Лучше на железку арбузы кидать, т.к. это материальное что-то, а не ссылка динамическая. Бороться с доменами довольно бесполезно (хотя РКН пытается, уровень компетенций печален).
7 1800X (старый обычный Zen).
256MiB (со всем, что я там наделал. с prefetcht0 на 0.2-0.35ms дольше исполняется чем с prefetchnta, а так стабильно предзагрузка лучше)
AVX2 normal assembly sum: Sum=134216776.000; best time = 57.612553ms
AVX2 prefetch assembly sum: Sum=134216776.000; best time = 56.600445ms
цикл развёрнут на все 16 регистров (предзагрузке чуть хуже становится, обычному варианту на % лучше):
AVX2 normal assembly sum: Sum=134225120.000; best time = 57.081848ms
AVX2 prefetch assembly sum: Sum=134225120.000; best time = 56.624981ms
Рандом (одинаково или так):
Random load NO prefetch : 216 cycles
Random load WITH prefetch: 180 cycles
Improvement: +16.67 %
Тогда `prefetchnta` (и положить в регистр) и просто не мусорить в кеш. Это намного быстрее, чем мусорить в кеш с помощью железки.
Но также как и железка этот вариант будет добавлять DRAM refresh задержки в общую обработку случайным образом, т.к. окно (только понял, что это основное, что хотел донести изначально) предзагрузки слишком маленькое, чтобы оно не влияло на результат.
Предзагрузка - чтобы работать как конвеер из стиралок и сушилок, а не как стиралка-сушилка (железный вариант обязателен для старого софта, а так - часто мешает, вспомнить хотя бы мусорные кеш линии для ограждения данных потоков). Задача - скрыть время доступа к внешней памяти.
Сомневаюсь, что железный предзагрузчик может скрыть почти 1us DRAM refresh (некоторые работы в этой области намекают, что точно не может и все решения memory bound задач просто живут с этими непредсказуемыми задержками), т.к. типичный доступ к памяти не занимает много сотен наносекунд. Если взять доступ L1d за 4-5 циклов, то на 5GHz ядре один DRAM refresh это провал по времени почти в 1000000 кеш линий (почти 64KiB, если обработка <1 цикла на кеш линию), а т.к. там нужна синхронизация на это время все полученные параллельно из памяти кеш линии для ядра будут ждать "неудачную" (попала в банку с DRAM refresh) предзагрузку кеш линии. И если нет предзагруженного буфера почти в 64KiB хотя бы в L3 работа будет просто останавливаться на сотни наносекунд.
Будем мы их сразу использовать или нет не имеет значения. Там LRU, поэтому при нагрузке на кеш предзагрузка теряет свою эффективность настолько, что предзагружать много кеш линий задолго до их обработки становится вредно (т.к. железная предзагрузка ещё добавит нагрузки на кеш).
Запрет вытеснения это хорошо, но что-то всё равно будет вытеснено, а магия это плохо.