• Самый медленный способ ускорить программу на Go
    0

    Справедливости ради, не ассемблерные вставки а интринсики — специальные архитеркутрно-зависимые функции в Си, почти всегда 1-в-1 транслируемые в конкретные инструкции процессора.

  • Самый медленный способ ускорить программу на Go
    +3
    Какая реализация может быть быстрее? Эталоном будет копирование памяти, которое занимает около 14 мс.

    Почему копирование, если на выходе у вас пишется в 4 раза меньше данных, чем читается? Эталоном будет скорость чтения 4х байт данных и записи х байт.


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

    Если скорость выполнения на одном ядре приближается к скорости копирования в памяти, то графический процессор вам точно никак не поможет, потому что скорость шины PCIe 3.0 16x в 2-3 раза ниже скорости памяти.

  • Знаковый символ: iOS denial of service
    +1

    На iOS 10.3 и MacOS 10.11.6 не воспроизводится.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    И нет никакой проблемы правильно экранировать их автоматически.

    Ну вы же сами показали пример, что есть.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –2

    Символ / встречается не только внутри строк, но и в самом скрипте (операция деления) и его экранированое с помощью \ приведет к порче скрипта.


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

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –1
    1. Вот вам известен язык в следующем теге? <script type="application/x-my-templates"> Но вы хоть погуглить можете, а библиотеке, которая собирает из DOM-дерева HTML что делать?
    2. ...
    3. Это необзательно неопределенное содержимое, просто модержмое может быть определено не в том месте, где формируется HTML-документ.
  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    про правильный эскейп просто НЕЛЬЗЯ забывать

    Давайте еще раз. Скрипт-тег все еще останется проблемой, если вы НЕ ЗАБЫВАЕТЕ про правильный эскейп. Его для тега script просто не предусмотрено.


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


    В отличие от него, тег script парсится по своим, совершенно отдельным правилам. Он не позволяет вставить в себя произвольный Javascript, даже если он на 100% валидный Javascript. Он накладывает дополнительные требования на содержимое встриваемых скриптов, которые в случае Javascript могут быть соблюдены только парсингом и модификацией Javascript, а в случае встраивания скрипта на произвольном языке в общем случае не могут быть соблюдены.


    А лучше просто класть foreign-inlput

    Лучше или хуже это другой вопрос. Я не о лучших практиках говорю, а о проблеме в спецификации. Спецификация допускает встраивание в HTML языков, синтаксис которых позволяет выходить за пределы встраеваемого жлемента и не дает никаких способов этот синтаксис экранировать. Вместо этого она говорит: «там этого контента быть не должно. Как и кто его будет оттуда доставать? Да мне плевать.». Из-за этого часто возникают уязвимости уже в реальных приложениях, когда контент в теге скрипт генерируется на лету.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0
    делающие <, >, ", & и прочее, ещё никто не отменял.

    И в результате у вас внутри строки Javascript будут именно &lt;, &gt;, &quot;, &amp;, а не <, >, ", &, которы были в исходной строке.


    И если забыть про правильный эскейп, то скрипт-тег будет далеко не единственной проблемой…

    Еще раз попробую донести свою мысль: скрипт-тег все еще останется проблемой, даже если не забыть про правильный эскейп. В случае тега script просто не предусмотрено никакого эскейпа для встраиваемого скрипта, на него просто наложены ограничения (причем с <!-- весьма извращенные), которых нет в Javascript.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    +3

    Нет, я как раз пытаюсь закрыть XSS

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0

    Что вы имеете в виду под работай в связке? Я написал на что конкретно он не расчитан: на встраивание в HTML.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    0

    Что вы имеете в виду под работой в связке?

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –4

    Попробуйте в целях повышения образованности написать библиотеку, которая бы вставляла произвольный Javascript в тег <script>.


    Задание со звездочкой: вставляла произвольный скрипт (не обязательно Javascript).

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –13

    Совершенно верно. Вставляйте в safescript :-)

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –2

    Экранирование <script> сложное, требует понимания синтаксиса встраиваемого скрипта, в общем случае не однозначное и не обратимое. Происходит по своим собственным законам.


    Экранирование <safescript> простое, однозначное, обратимое, не требует знать ничего о встраиваевом скрипте, такое же как во всем остальном HTML.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –3

    Экранирование невозможно в случаях, когда:


    1. Вы не знаете на каком языке встраивается скрипт
    2. Синтаксис этого языка не предусматривает экранирования не специальных символов (то есть \/ в строковых литералах будет означать \/, а не \).
    3. У вас нет средств для синтаксического разбора и модификации исходного текста встраиваемого скрипта.
  • Фундаментальная уязвимость HTML при встраивании скриптов
    –3
    Если разработчик вставляет в JS-код, встроенный в страницу, неэкранированный текст, он сам виноват.

    Хороший подход. А что если его вставляет не разработчик, а библиотека или сам барузер, как это описано в части А вы точно спецификация??


    Просто надо экранировать не только кавычки, но и угловые скобки.

    Это не всегда возможно, об этом я написал в части А вы точно спецификация?

  • Фундаментальная уязвимость HTML при встраивании скриптов
    –1
    почему бы просто не экранировать сразу в шаблонизаторе как рекомендует стандарт

    Это не всегда возможно, об этом я написал в части А вы точно спецификация?.

  • Фундаментальная уязвимость HTML при встраивании скриптов
    +2

    Совершенно верно, <safescript> это аналог <script defer>. Забыл об этом сказать.

  • Алгоритм выбора location в Nginx
    0

    Кучу лет пользуюсь nginx, и только сейчас узнал, что location могут быть вложенными! С одной стороны ни разу не было необходимости в таком, с другой предупрежден — значит вооружен. Спасибо!

  • Абсурдно быстрое кодирование и декодирование base64
    0

    Только прктические результаты в моей статье )


    https://habrahabr.ru/post/326900/
    Последние три абзаца.

  • Абсурдно быстрое кодирование и декодирование base64
    0
    ограничивается максимальная частота TurboBoost для ядер

    Это больше касается операций с плавающей точкой. А там:


    Our AVX2 decoder does not use floating-point numbers.
  • Абсурдно быстрое кодирование и декодирование base64
    +13

    Закончилось совершенно неожиданно. Это могло бы быть классным всуплением для интересной статьи.

  • Meltdown: влияет не только на производительность
    +3
    но еще и более горячий CPU (в среднем 10-15%)

    Очень интересно, как вы посчитали проценты от температуры. Неужели просто взяли количество градусов и разделили одна на другое? )


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

  • Десять вопросов о Node.js, на которые вы не сможете ответить
    0

    Так сколько потоков?

  • Десять вопросов о Node.js, на которые вы не сможете ответить
    –2

    Ровно один плюс еще пул это не ровно один.

  • Качественное уменьшение изображений за константное время
    0

    см https://habrahabr.ru/post/340966/#comment_10492298


    Я кстати попробовал RGSS (сэмулировал как мог), результат мне не понравился:


    # coding: utf-8
    from __future__ import division
    
    import sys
    from PIL import Image
    
    im = Image.open(sys.argv[1])
    
    w = 256
    h = int(w / im.width * im.height + 0.5)
    s = im.width / w
    
    im0 = im.transform((w, h), Image.AFFINE,
                       (im.width / w, 0, -s*.35, 0, im.height / h, -s*.15),
                       Image.NEAREST)
    im1 = im.transform((w, h), Image.AFFINE,
                       (im.width / w, 0,  s*.35, 0, im.height / h,  s*.15),
                       Image.NEAREST)
    im2 = im.transform((w, h), Image.AFFINE,
                       (im.width / w, 0,  s*.15, 0, im.height / h, -s*.35),
                       Image.NEAREST)
    im3 = im.transform((w, h), Image.AFFINE,
                       (im.width / w, 0, -s*.15, 0, im.height / h,  s*.35),
                       Image.NEAREST)
    
    Image.blend(
        Image.blend(im0, im1, 0.5),
        Image.blend(im2, im3, 0.5),
        0.5
    ).save('_out.RGSS.png')





  • Качественное уменьшение изображений за константное время
    0
    Основное применение данной техники — это генерация thumbnails.

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

  • Качественное уменьшение изображений за константное время
    0
    Потому что исходные картинки будут в .jpg или .png.

    Я не понял откуда взялось ваше «будут». Исходные картинки могут быть в .jpg или .png. Могут быть загружены час назад, могут быть сгенерированы на лету, может быть все что угодно. И все это никак не связано с ресайзом.

  • Качественное уменьшение изображений за константное время
    0

    А почему я должен «помнить» о декодированиии изображения, если речь о ресайзе?

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

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

  • Качественное уменьшение изображений за константное время
    +2

    Так. Размер исходного изображения поменялся, сложность и время нет. Значит сложность относительно исходного размера — константа. Верно же? Или у меня где-то не так написано?

  • Качественное уменьшение изображений за константное время
    +2
    Для него в доке

    Это PHP-стайл: когда делается полурабочая функция, а в документации пишется как именно она сломана. Не хочу никого обидеть, но почему-то в PHP такое встречается очень часто.

  • Качественное уменьшение изображений за константное время
    +2

    У вас в одном примере есть и «конечное» и «целевое» изображение. Я не понимаю откуда куда вы ресазите )

  • Качественное уменьшение изображений за константное время
    +1

    Тут нет опечатки. Время константное относительно разрешения исходного изображения. От разрешения конечного изображения время линейное.

  • Качественное уменьшение изображений за константное время
    0

    Спасибо, добавил в статью.

  • Качественное уменьшение изображений за константное время
    0

    Я ни разу не встречал, чтобы описанный метод назывался суперсемлпнгом (даже не встречал, чтобы он в принципе был где-то реализован). Но если подумать, что делает видеокарта при суперсемплинге? Она из бесконечного кол-ва точек (отренидирить сцену мы можем в бесконечном разрешении) выбирает 4 точки для каждого конечного пикселя, так что да, в каком-то смысле это и есть суперсемплинг.


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

  • Качественное уменьшение изображений за константное время
    +1
    Остались ещё разработчики графического софта, которые не знают, что при уменьшении изображений тупая интерполяция не работает?

    В статье есть не полный список ПО: OpenCV, канва в браузере. Еще я много раз видел, как браузеры используют его для обычных картинок для быстрой черновой отрисовки при изминении размеров, а уже через секунду отрисовывают на чистовую с помощью сверток. Ну а какой-нибудь ИЕ11 использует фиксированное ядро всегда.


    который можно описать гораздо короче

    Вы ошиблись в описании. Уменьшаем не в целое количество раз, а до размера в целое количество раз больше конечного.


    проблемы вызовут тонкие линии на изображении (станут прерывистыми)

    Это можно посмотреть на фотографии схемы метро, там действительно некоторые линии прерываются при 2x.

  • Качественное уменьшение изображений за константное время
    0

    Вот тут есть несколько вариантов, как выбирать точки: https://en.wikipedia.org/wiki/Supersampling#Supersampling_patterns


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

  • Качественное уменьшение изображений за константное время
    0

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


    >>> from PIL import Image
    >>> im = Image.open('pineapple.jpeg'); im.load(); im.size
    (2560, 1600)
    >>> %time im.resize((256, 170), Image.BICUBIC)
    Wall time: 33.2 ms
    
    >>> im = Image.open('space.jpeg'); im.load(); im.size
    (4928, 3280)
    >>> %time im.resize((256, 170), Image.BICUBIC)
    Wall time: 130 ms
  • Качественное уменьшение изображений за константное время
    0

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