Pull to refresh
-1
0
Send message

Мне не нравится функция reduce. Она делает код нечитаемым. Надо вдумываться, мысленно представлять, как перемещаются данные, чтобы понять, что хотел сказать автор кода. Обычный цикл в разы проще прочесть. Когда видишь reduce, то складывается ощущение, что автор хотел не писать понятный код, а посоревноваться в знании экзотических конструкций.


Вот пример нечитаемого кода из статьи, в который надо долго вглядываться, чтобы понять, как он выполняется:


arr.reduce((count, x) => predicate(x) ? count + 1 : count, 0)

И вот, как его надо переписать:


countWhere(arr, predicate);

Либо:


count = 0;
for (x of arr) {
    if (predicate(x)) {
        count ++;
    }
}

Этот вариант занимает больше строк, но глаз сразу цепляется за for/if и видит суть кода. Тот, кто написал исходный код, хотел показать, какой он умный и как он умеет пользоваться функциональным подходом, но фактически он показал, что он глупый, так как не додумался вынести код в функцию с понятным названием countWhere.


Давайте не забывать, что функции вроде map/reduce пришли из функциональных языков, где нет нормальных циклов и приходится искать обходные пути. Это по сути костыли. В императивных языках циклы есть и надо ими пользоваться.


Цикл еще и быстрее, чем функции вроде map/forEach/reduce, так как нет накладных расходов на вызов функции.


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

Хейтеры "усложнений" скорее напишут так:


$post = [
'status' => 'draft',

];


И сиди потом гадай, какие еще статусы бывают.

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

Так и процессор не может узнать, пока не вычислит значение, от которого зависит ветвление. И вынужден угадывать ветвление по предыдущему опыту.


где будет зависимость между инструкциями

Это как раз известно еще на этапе компиляции.

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


Но x86 как раз пример ужасной архитектуры. Она была придумана для 16-битного процессора с последовательным выполнением команд и очень плохо подходит для современных процессоров. Одна команда может быть закодирована кучей разных способов, используются префиксы. Можно только представить, каких усилий инженерам Интел стоит ее поддержка.


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


Я также замечу, что в последнее время перестали расти частоты процессоров. Значит, нужно проектировать архитектуру под "медленные" процессоры и искать выигрыш в чем-то другом — например, в большем распараллеливании. Традиционные программы, где команды выполняются по очереди, больше не ускорить. Прирост, который дает Out-of-order execution и спекулятивное выполнение, тоже ограничен, и нужны новые подходы. За счет Ooo вы можете выполнить 3-4 операции за такт при удачном стечении обстоятельств, но не больше. Если вы хотите выполнять вычисления быстрее, вы должны либо иметь множество ядер (десятки-сотни) и многопоточную программу, либо придумать способ выполнять за один такт множество команд — 10, 20, 30.


Это, кстати, объясняет, почему архитектура x86 бесперспективна — ее нельзя адаптировать под "медленные", но широко параллельные процессоры.


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


Объективно я вижу два недостатка у Эльбруса:


  • непредсказуемость времени обращения к памяти может остановить конвейер. Наверняка с этим что-то можно сделать. Ведь такая же непредсказуемость есть и в Интеловских процессорах И они точно так же могут остановиться. А в Эльбрусах, как я помню, есть возможность фоновой предзагрузки данных из памяти.
  • отсутствие поддержки Эльбруса в JIT-компиляторах. Браузеры на лету компилируют JS-код в ассемблер, регулярные выражения компилируются в ассемблер, ява-код компилируется, базы данных компилируют код. И все они не поддерживают Эльбрус.

При этом, я вижу определенную несправедливость. Вышел Мак на ARM — переоцененное, бесполезное, не нужное железо с проприетарным закрытым софтом по завышенной цене. И все спешат адаптировать свои программы под него, выполняя бесплатно работу для самой богатой корпорации в мире. А для нашего Эльбруса никто ничего адаптировать не хочет.


При этих недостатках, у Эльбруса много хороших решений. Глупо было бы терять эти наработки.


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


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

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


"Жирный" код, ведущий к повышенным кэш-миссам кода

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


Дополнительная нагрузка на кэш данных в следствие спекулятивного исполнения кода

Та же проблема есть у Интела.


Фактическая непереносимость кода между версиями процессора

Не вижу проблемы перекомпилировать код. Современные ОС вроде nix позволяют выполнить компиляцию из исходников и установку программы одной командой.

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

Я против этой статьи.


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


Также, нельзя распространять персональные данные других людей.


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

Насколько природный иммунитет падает от ограничения поступления вирусов/бактерий

Маска защищает не вас, а окружающих от вас. Вы высказываете типичную позицию "мне плевать на окружающих".


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

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


Вот посмотрите, например, сколько вокруг людей без масок. Даже если ты антипрививочник, что тебе мешает надеть маску? Очевидно, что никакой опасности в ней нет. Но нет — не надевают. Не потому, что маска опасна, а просто потому что наплевать на окружающих. Наплевать, что могут их заразить. Не хотят принимать участие в общей борьбе с болезнью. А ведь победить ее можно только сообща.


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


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


Или посмотрите на ТВ. Между гостями в студии нет стеклянных перегородок, гостей не рассаживают на безопасное расстояние друг от друга. То есть, включив ТВ, россиянин видит, что другим тоже наплевать на пандемию. А зачем тогда ему что-то делать, если все вокруг игнорируют правила? А вот на японском ТВ есть и перегородки, и социальная дистанция. Да что там на ТВ, блогеры в Ютуб-каналах носят маски на улице. Совсем другое общество.


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

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


Если мы будем разрешать такие статьи, то что будет завтра? Статья о пользе гомеопатических средств на личном опыте? Список лучших колдунов России?


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

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

То есть, это бояре плохие, а царь хороший, просто никак порядок навести не может?

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


Хотя, какая разница, вступило или не вступило. В рамках борьбы с Телеграм Путин блокировал миллионы IP-адресов тоже без всяких законных оснований, и никто не был за это наказан. В России закон это просто ничего не значащие слова на бумаге.


Граждане других стран смогли договориться и придти к выводу, что обществу выгоднее и справедливее, когда все живут по законам. Русский же не хочет соблюдать законы или справедливости, он хочет лишь обмануть других, подняться над ними и урвать что-нибудь для себя. Человек урвал хорошую работу в РКН и его не беспокоит, что он выполняет незаконные распоряжения и нарушает права тысяч граждан. Его беспокоит лишь его высокая зарплата, ведь он не хочет возвращаться на обычную работу с МРОТ в 12 000 рублей.

Современные языки лучше. Сегодня у нас есть Питон с numpy, scipy, simpy. А на вашем Паскале, чтобы рассчитать фильтр низких частот или решить уравнение, надо все писать с нуля. Или, например, Питон из коробки поддерживает числа бесконечной точности, дроби, а в Паскале опять же надо сначала написать для них библиотеку. В Питоне можно клонировать объект произвольной вложенности одной строчкой, а в Паскале возможно ли?


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


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


Напишите преимущества Паскаля перед Питоном или Го.

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


когда уже во всю вышел нормальная 5 версия без jQuery

Не понял претензии. CSS-код Bootstrap 4 требует jQuery для работы? Я думаю, он нужен для интерактивных виджетов, а CSS можно использовать и без jQuery.


Кстати, что касается CSS, на Гитхабе сейчас объем CSS около 900 Кб. Справедливости ради, он у них немножко разбит по разделам, но все равно 900 Кб — многовато, чтобы просто отобразить список файлов и README, согласитесь? Также, если зайти в приватном режиме на главную Гитхаба, там столько анимаций, что у меня браузер тормозит при прокрутке.


орнул с иконки медведя

Когда придраться не к чему.


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

Почему он "убогий", в статье почему-то не написано. Нечего написать?


Если немного копаться в коде, то можно увидеть такие вот комментарии, которые наталкивают на мысль, что сервис пишет команда школьников

Не понял, что не так с комментариями.


Интерфейсные решения соответствуют очень давнему 2008 году.

А 2021 год — это как Гитхаб, анимации, подвешивающие браузер?


Версионность фреймворков оставляет желать лучшего.

А что меняет версия (не версионность) фреймворка? У вас примитивное мышление в стиле "Bootstrap 4 плохой, bootstrap 5 хороший". По моему, так они оба плохие:


1) бутстрап очень громоздкий и перегруженный. Это можно решить, если вручную импортировать только нужные компоненты, но никто почему-то так не делает, просто берут много-сотен-килобайтный файл и копируют в папку assets. Или к примеру, если надо поменять базовый шрифт, вместо того, чтобы переопределить его на уровне компонентов, просто берут и в CSS дописывают правила. Получается в итоге два правила, задающих шрифт — первое из бутстрапа и второе, перекрывающее его. А зачем тогда нужно первое? Почему вы его не уберете? Не хотят думать и оптимизировать, хотят лепить как попало.


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


В общем, использование бутстрапа это скорее минус к сайту. Одно дело вы делаете админку и надо делать быстро, а другое дело — сайт, рассчитанный на огромную аудиторию. Я считаю, для второго бутстрап плохо подходит по описанным выше причинам.


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

Идея интересная. Вот недостатки, которые я вижу:


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

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


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


Одно печально — если эту идею кто-нибудь реализует, в России введут ответственность за майнинг и финансирование некоммерческих организаций.

Если ассемблер так хорош, почему же мы не видим десктопных программ на нем? Компиляторов? СУБД?


Потому что это сложные программы, работающие со сложными данными (массивы, структуры, хеш-таблицы). В Си мы пишем index.fields[FIELD_NAME].offset, а в ассемблере вы будете сидеть вручную высчитывать смещение от указателя. Вы потратите в разы больше времени. И какой смысл этим заниматься?


Или Питон. В Питоне мы пишем [some_dict[x] for x in values if x > 0], а в ассемблере вам надо написать кучу строчек, чтобы сделать тот же объем работы.


Вдобавок, ваша программа будет работать только на одном процессоре и не будет переносима на другие платформы. Она просто умрет, когда процессор выйдет из употребления.


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


Даже если нужна высокая производительность, то глупо руками писать код на ассемблере. Умно — написать эффективный транслятор, который будет без потерь транслировать высокоуровневый код в ассемблер. И примеры есть: регулярки транслируются в ассемблер, SQL-запросы, JS-код. Вот где искусство — преобразовать сложный запрос в набор низкоуровневых команд. А не сидеть часами переставлять mov и inc местами.


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


Вы пишете, что ассемблер позволяет обходиться "без стандартных библиотек". Опять же, это глупо — переходить на ассемблер ради сокращения программы. Умно — переделать компилятор, чтобы он умел выкидывать неиспользуемые функции. gcc это более-менее умеет. Ну и без библиотек тоже плохо. Что вы будете делать, когда вам понадобится множество, словарь и другие структуры данных? Что вы будете делать, когда понадобится применить к данным фильтр низких частот? Я, например, просто возьму scipy и решу проблему за пару десятков минут.


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

И компьютер способен сделать это лучше человека. Почитайте про "супероптимизацию". Кратко: человек написал программу, которая генерирует все возможные комбинации ассемблерных команд, чтобы получить эквивалент данной на вход программы. Например, компьютер смог найти эквивалент из 4 команд для программы из 9 команд. Супероптимизация — это умно. Сидеть руками переставлять байты — глупо.


В продолжение, вот еще работа, где супероптимизатор использовался для оптимизации реальных программ. Выигрыш в размере составил до 4%. В том числе супероптимизатор смог применить SSE инструкции.


Ещё одна интересная область применения ассемблера – создание файлов данных с помощью макросов и директив генерации данных.

Питон это делает лучше.


Для внедрения кода в другие процессы
создания различных антиотладочных приёмов
Блоки распаковки, защиты кода
Эта дрянь не нужна. Это верный способ ввести труднообнаружимые баги или нарушить переносимость программы на другие ОС или другие версии ОС. Пример: вы используете какую-то недокументируемую функцию или смещение, а в новой версии ОС оно поменялось. Также, из-за таких любителей "защищать" код часто игры не работают под Wine. То есть, это значит что в будущем, когда Windows перейдет на другую архитектуру, их ни на чем нельзя будет запустить.

Отдельно хочется сказать про систему команд Интел. Она безнадежно плоха из-за необходимости совместимости с 8086. 8086 вышел по моему в 70-х годах, в нем 16-битные команды исполнялись строго по очереди, и с тех пор все поменялось радикально: процессоры стали 64-битные, в них используется out-of-order параллельное исполнение команд, а Интел должен тянуть это дремучее легаси. Ну представьте, например, как сложно процессору определять зависимости команд (то, что команду add dl, 1 нельзя выполнить параллельно с mov rdx, [rdi]). Команда занимает от 1 до 15 байт, с кучей префиксов. Регистры могут быть указаны в куче разных мест кучей разных способов. Данные могут читаться 1, 2, 4, 8 байтами без выравнивания. Или флаги: они тоже здорово мешают параллельности.


Лучшее, что можно сделать с архитектурой x86 — это выкинуть ее на помойку. Опять же, если брать Эльбрус, то система команд там намного современнее и логичнее, жаль только, что команды очень жирные.


Комп — это же не просто универсальный девайс для работы с информацией, а в первую очередь свобода. Важная часть которой — я могу любую программу нажать правой кнопочкой, выбрать «открыть в дебаггере» и поправить всё что мне не нравится.

Это не свобода, а насмешка. Свобода — это Линукс, где вы можете открыть нормальный читабельный исходник. Единственное, что огорчает в Линуксе: для Си нет нормального менеджера зависимостей, там на полном серьезе предлагают скачать исходники в tar.gz и до сих пор используют страшные нечитаемые Makefile.


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

Заголовок желтоват. Не "ФБК слили все данные всей оппозиции", а оставили открытый доступ к такой-то админке, через которую можно получить доступ к таким-то данным. Ощущение, что мы не на Хабре, а в Яндекс-новостях.

То есть, этот Kubernetes Web View не имеет по умолчанию никакой авторизации, и при внимательном поиске сотни сайтов должны попасть в наши умелые руки? Странно, поиск в Гугле, Яндексе и DuckDuckGo ничего особо не выдает. Как это объяснить? Где мои сотни сайтов с открытыми админками?


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


Например, ГУ МВД по Москве, которое указано в метаданных одного из файлов с утечками и редакторы Телеграм-каналов, выкладывающих данные. Ранее РКН не мог ничего сделать, так как Телеграм был заблокирован, но сейчас его разблокировали и РКН может приступить к своим обязанностям.

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


Вот, например, в Японии не разговаривают по телефону в транспорте, и вообще громко не разговаривают. Что же, россиянин менее культурен, чем японец? Или меньше заслуживает тишины и покоя?

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


Для тех, кому хочется поговорить, существует купе.

Information

Rating
Does not participate
Registered
Activity