• Топ VSCode расширений, которые ускорят вашу разработку на JavaScript
    0

    У меня Андроид студия столько же жрет, и никаких расширений ставить не пришлось:) Если мы говорим про экономию памяти — однозначно vim. Или Geany, он память не жрет и довольно много из коробки умеет.

  • Топ VSCode расширений, которые ускорят вашу разработку на JavaScript
    +2

    Добавлю ещё отличные плагины:


    • Color Highlight — показывает цвет цвета прямо в редакторе
    • EditorConfig — для поддержки одноименного формата
    • PlantUML — диаграммы прямо в редакторе
    • Script Commands — если лень писать свои плагины, можно цеплять абсолютно любые собственные скрипты к редактору
      Главное, что нет необходимости ставить 3 IDE, если время от времени нужно править код на Java/JavaScript/ObjectiveC/C++.
  • Используем Bash в SQL-стиле
    +3

    Хотя и сам не прочь крутить подобные портянки, хочу предупредить читателей, этот код — не пример для подражания. Выход за границу 80 символов — сама по себе проблема, и если скрипт "причесать" до читаемого состояния, то в нём будет уже не 9, а без малого сотня строк. И гарантировать, что этот скрипт не развалится от случайно затесавшегося неформатного файлика, в отличие от настоящего парсера, невозможно. А когда он развалится, отладка превратится в ад (если этот факт вообще кто-то заметит).


    Также для уменьшения времени работы, количества временных файлов да и просто вероятных ошибок, в Bash есть замечательная конструкция:


    while read -r line; do
      echo $((line**2))
    done < <(seq 123)

    В отличие от command | while ...do ... done она не создаёт новый сабшелл и позволяет избежать ошибок, связанных с потерей переменных.

  • Дюжина приемов в Linux, которые действительно сэкономят уйму времени
    +1
    чтение из разных конфигов, где я считываю значение переменных

    Если позволяет формат конфигов — то не знаю ничего быстрее чем source config.cfg, всё что было внутри конфига превратится в переменные баша. Такой способ используется повсеместно в initscripts. Все эти ifcfg-eth0 в RHEL по крайней мере — по сути шелл-скрипты.


    Ещё один способ, который годится для перегона нестандартного формата конфига — eval "$(sed ... config.ini)". Сед приводит конфиг в башеподобному виду, eval превращает в переменные.


    Обычно так делают студенты домашку, так как им показали ограниченный набор базовых команд.


    VAR1=$(cat file.cfg | grep var | cut -f2 | sed 's/"//')
    … и так десять раз

  • Дюжина приемов в Linux, которые действительно сэкономят уйму времени
    0

    Дело в подготовке данных (вы вызываете cut 1000 раз, а я один раз но для 1000 строк).

  • Дюжина приемов в Linux, которые действительно сэкономят уйму времени
    +1

    Если не можете выиграть битву, поменяйте поле:


    #!/usr/bin/env bash
    
    # prepare data
    for A in {1..1000}; do
        STRING+="Name$RANDOM Date$RANDOM Shell$RANDOM"$'\n'
    done
    
    echo "using cut"
    time cut -d " " -f 3 <<<"$STRING" > /dev/null
    
    echo "using shell"
    time while read a b c; do
        echo $c
    done <<<"$STRING" > /dev/null
    
    # using cut
    # real    0.006
    # у меня медленный компьютер, результат с echo аналогичен тому, что предлагает автор
    # using shell
    # real    0.026

    1. Когда нужно обработать много данных — пайпы лучше.
    2. Единичные случаи — да, эффективнее использовать bash-измы. Обратная совместимость пострадает, но мы вас предупреждали.
    3. С другой стороны, измерять эти миллисекунды имеет смысл, только когда данных много, следовательно см. п. 1.

    В последнее время cut работает хорошо. Не так давно в GNU coreutils cut работал так, что его обгонял awk.

  • AMD Ryzen — когда красные восстали из пепла
    0
    Попробуйте memtest прогнать. Такой же «баг» ловили на Intel, тоже падал компилятор только на крупных проектах вроде ядра или gcc, оказалось — битая плашка памяти, заменили и всё прошло. Много потоков -> много памяти -> выше шанс словить битую ячейку.
  • Роскомнадзор, как средство отражения DDoS
    0
    Поделитесь, пожалуйста, источником «остальных мер» — думаю, другим читателям будет полезно.
  • 10 мини-лайфхаков в Bash
    0
    .(){ bash -e "$1";}

    Подарите джуниорам бесценные часы отладки:) Можно добавить более весёлую шутку на свой вкус.

  • Bash-скрипты, часть 6: функции и разработка библиотек
    +3

    И это вы ещё поверхность не поцарапали...


    cd $dir
    rm -fr *

    Спойлер: представим, что $dir не существует или пустой.


    file=/etc/passwd
    foo() {
      # local file
      for file in /*; do # file теперь глобально видна всем
        :
      done
    }
    foo
    # ой!
    echo $file

    copy_file_to_tmp() {
      cp "$1" /tmp # работает ровно до момента появления файла с названием "-f"
    }

    Тысячи их.


    А ещё bash -ue script.sh.


    В целом хорошо, что появляются обучающие статьи про баш, плохо то, что учат они не тому. И не учат делать отступы в скриптах.


    P.S.


    count=$(( $count + 1 ))
    # так тоже работает
    ((count++))

    P.P.S. В systemd поняли ошибку и переписали всё с шелл-портянок на Си. Но в последний момент всё равно что-то пошло не так...

  • 10 мини-лайфхаков в Bash
    0

    У меня такая же есть на 32 Кб, всё думаю, может и правда сделать заметку "во что превратился мой .bashrc"?:)

  • 10 мини-лайфхаков в Bash
    0
    а вы при этом знаете, в чем будет отличие от bash ./commands.txt?

    лишний раз subshell не будет запускаться (вдруг и правда кому-то нужно)


    серьезно? А чем вас не устроил ab?

    тоже хотел узнать, что может быть проще ab, к тому же предлагаемый вариант ужасен — wget намусорит файлами вида index.html.*


    И если уж на то пошло, сильно укоротить можно: seq 1000 | xargs -I{} -P20 wget -qO/dev/null ya.ru (да простит нас Яндекс)

  • Настоящий Unix — не есть приемлемый Unix
    0

    В Shell другие правила экранирования спецсимволов, которые ls не учитывает. Более правильно экранирует printf %q. И всё же лучше не полагаться на это, а ls может оказаться без этих расширений (busybox). В идеале должно получиться вот так: $'troll\nfile'

  • Настоящий Unix — не есть приемлемый Unix
    0

    Не сочтите за грубость, но это тоже не будет работать:)


    touch 'troll'$'\n''file'

    Навскидку, как это правильно можно было бы сделать в bash (на самом деле так делать не надо, но демонстрация проблем с экранированием символов в шелле исчерпывающая):


    #!/bin/bash
    
    FILES=()
    SIZES=()
    i=0
    while read -rd $'\0' file; do
        FILES+=("$file")
        SIZES+=("$(wc -c < "$file") $i")
        ((i++))
    done < <(find -mindepth 1 -maxdepth 1 -type f -print0)
    for l in "${SIZES[@]}"; do
        echo $l
    done | sort -n | while read _ n; do
        printf '%q\n' "${FILES[$n]}"
    done

    Это из коллекции "1000 и один способ выстрелить себе в ногу в Shell". Если вы всё ещё полагаетесь в скриптах на вывод команды ls, настоятельно рекомендуется к прочтению, и это тоже.


    У некоторых людей такой юниксвейный подход к проектированию интерфейсов вызывает глубокую депрессию.

  • Настоящий Unix — не есть приемлемый Unix
    0

    И всё ещё неправильно. В имени могут быть пробелы и даже переносы строк. Правильно — переписать всё на Си, что в ls и сделали.


    Нет ничего удобнее, чем вбить ls -lrt и посмотреть последние изменения в каталоге. А ещё никто не мешает сделать удобные для запоминания алиасы:
    alias ListFilesSortedByLastModificationTime='ls -lrt'

  • Как устроен парсер Python, и как втрое уменьшить потребление им памяти
    0

    На самом деле, даже такая мелочь как потребление памяти "хелловордом" в Python крайне раздражает. Python, который ещё ничего не делает, съедает сразу 6 МБ. Если мне надо запустить сотню скриптов параллельно — это уже проблема. Или другой пример — минималка CentOS, куча демонов — postfix, imap, https, systemd, rsyslog, у всех потребление памяти ~ 6-10 МБ. И выделяется firewalld, который по сути ничего не делает и жрёт при этом 25 МБ. Подозреваю, тут уже не в интерпретаторе дело, а в каких-нибудь хэш-таблицах, сделанных через односвязный список...


    Но вот что интересно, если 100 человек отправит в апстрим аналогичный патч, снижающий потребление ОЗУ, то возможно сообщество прислушается?

  • Пять перспективных языков программирования со светлым будущим
    +1

    В большинстве случаев можно и без макросов обойтись, вот например шаблон, который ведёт себя также как и функция print в Питоне:


    template print*(x: varargs[string, `$`], file: File = stdout) =
      var res = ""
      for i in x:
        addSep(res, " ")
        if i != nil:
          res.add(i)
        else:
          res.add("(nil)")
      file.writeLine(res)

    или withFile, который сам закрывает дескриптор после выхода из блока:


    template withFile*(filename, body) {.immediate, dirty.} =
      block:
        var outfile: File
        template put(x: varargs[string, `$`]) = 
          outfile.writeLine(x)
        if open(outfile, filename, fmWrite):
          defer: close(outfile)
          body
        else:
          raise newException(OSError, "cannot open: " & filename)

    В результате Nim становится не намного многословнее баша.

  • Пять перспективных языков программирования со светлым будущим
    0

    А они и взяли pcre, но я никогда ещё такого медленного pcre не видел:


    # 4.5 sec
    import re
    let exp = re"agggtaaa|tttaccct"
    var c = 0
    for line in "in.txt".lines:
      if line.find(exp) != -1:
        c += 1
    echo (c)
    
    # 2 sec
    import pegs
    let exp = peg"'agggtaaa'/'tttaccct'"
    var c = 0
    for line in "in.txt".lines:
      if line.find(exp) != -1:
        c += 1
    echo (c)
    

    # 0.2 sec
    grep -cE 'agggtaaa|tttaccct' in.txt
    # 0.4 sec
    grep -cP 'agggtaaa|tttaccct' in.txt
  • Пять перспективных языков программирования со светлым будущим
    0

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

  • Пять перспективных языков программирования со светлым будущим
    +10

    Переписывал на Nim пару скриптов-парсеров (~1000 LOC) для собственных нужд с целью поднять производительность того же самого, написанного на Питоне. Привлекает анонсированные аналогичный синтаксис и сравнимая с C скорость, по факту — так и есть. Скорость разработки немного медленнее, так как до сих пор некоторых фишек не хватает, но благодаря макросам ему можно простить такие косяки.


    Что понравилось:


    • классы, объекты — всё это практически имеет нулевой оверхэд
    • сборка мусора работает довольно быстро
    • такой извращённой (в хорошем смысле) системы шаблонов и макросов я нигде не встречал
    • сборка через трансляцию в С, всегда можно его потюнить до производительности, сравнимой с C. К тому же можно распространять исходники в виде, оттранслированном в C — обфускация кода из коробки с неплохой переносимостью
    • хорош для разбора всевозможных xml/json и прочих разношёрстных конфигов с целью генерации отчётов
    • сравнительно безопасен, отстрелить ногу можно, но примерно с той же вероятностью, что и в питоне — по незнанию особенностей языка
    • легко подцепить функцию/библиотеку из C, если чего-то не хватает
    • очень легко собирается и самодостаточен, в плане переносимости лучшего варианта не сыскать
    • оптимизирующие шаблоны — отдельная песня. Можно целые куски кода, вроде "разделить строку по пробелам, взять подстроку длиной 10 символов от первого элемента" по мере необходимости переписывать на более оптимальные, с меньшей нагрузкой на сборщик мусора, при этом читаемость кода никак не пострадает. Эти шаблоны прячутся где-нибудь и ждут подходящего паттерна.

    Что не понравилось:


    • баги — проклятье данного проекта. Их уже более 700, количество растёт, сообщество не успевает их фиксить.
    • удручающие решения в стандартной библиотеке. Ещё недавно чтение файлов работало посимвольно, через fgetc. Потоки (streams) — до сих пор небуферизованные, работают посимвольно и не спеша.
    • печальное состояние поддержки юникода и вообще какой-либо работы с языками, отличными от английского, отдельного упоминания достойна полная отсутствия поддержки переводов (по типу gettext)
    • биндинги к библиотекам сделаны на коленке любителями (см. GTK)
    • его пилит полтора человека, и ситуация не спешит меняться
    • регулярки прикручены наспех и работают медленнее, чем perl в десятки раз. Редкий язык, где реализация "в лоб" быстрее regexp.
    • отсутствует возможность использования рантайма, чтобы бинарники не пухли. Всё компилируется статически
    • сомнительная реализация исключений через longjump
    • из-за сборщика мусора нетривиально на нём разрабатывать библиотеки и модули к другим программам — требуется обязательное выполнение NimMain где-нибудь
    • коллеги смотрят на вас как на ненормального

    Несмотря на недостатки, хороший язык "для себя" и можно на нём переписать что-то, что раньше было написано на Баше или Питоне, где нужна скорость. Продакшн даже не пробуйте — где вы потом программиста на Nim искать будете?:)


    P.S. Подписываюсь на эссе по Nim от автора. Crystal пробовал — осталось впечатление, что он ещё более сырой, чем Nim.

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    0

    А, всё правильно. Он в отдельной ветке SDF, плюс я не успел новый класс внутрь fontrender-а засунуть.


    Резервный шрифт устанавливает операционная система. Надо либо делать свой движок рендеринга ttf, что довольно хлопотно, либо поискать как в ОС поменять резервный Arial на какой-то другой (в linux, например, за это fontconfig отвечает).

  • Рендеринг UTF-8 текста с помощью SDF шрифта
    +3

    Не стоит также игнорировать экспорт кернинг-пар — в экзотических шрифтах отсутствие кернинга ой как заметно.


    Минутку, в UBFG ведь есть встроенный Distance Field!
    Да, есть. Но результат получается заметно хуже. Возможно в обновлениях авторы UBFG это поправят.

    Странно. Раньше в алгоритме были ошибки и приближенное вычисление SDF, но в последнем коммите я пытался поправить SDF-генератор и вроде бы он не уступает по качеству BruteForce (см. тест, PSNR > 70 дБ).

  • Почему JavaScript работает быстрее, чем С++?
    +4

    Реализация PHP слишком хитрая — там читерство с потоками и она запутаннее, чем js. Найдётся умелец, который перепаяет js на потоки и расстановка сил снова изменится. А вообще в тесте соревнуются в скорости pcre-движков, только и всего, и учитывая что многие используют libpcre — разница Python, PHP и C++ должна быть минимальна. Аналогично, там есть тест с числом пи, где по сути сравнивают производительность очень оптимизированной библиотеки gmp саму с собой, которая написана, к слову, на Си и ассемблере.


    Но делать такие далеко идущие выводы на основе самого сомнительного бенчмарка (там ключевое слово — game)...


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

  • Zenity на службе у системного администратора
    0
    Попробуйте ещё yad — это форк Zenity, но более продвинутый и устраняет многие недостатки Zenity. Но главное — можно делать практически произвольные формы.

    Для проверки качества пароля используйте cracklib-check, она умеет сообщать вид «слабости» пароля, используется в стандартном PAM:

    $ cracklib-check <<< 123
    123: it is WAY too short
    

    Для отправки уведомлений можно использовать notify-send, там багов таких нет.
  • Вымогатель KeRanger для OS X: наш анализ
    +3
    Разработчики Transmission уже выпустили патч, удаляющий червяка. Ещё пару дней назад. Ну и регулярные бекапы + подписка на oss-security сделают вашу жизнь чуть более скучной:) Присоединяюсь к предыдущему вопросу о пути проникновения червя в подписанный инсталлятор на офф. сайт разработчика.
  • Пишем shell скрипты на Python и можно ли заменить им Bash
    +6
    Выглядит очень интересно, хотя я и привык к shutil и простой обертке над subprocess, но никогда не писал на питоне то, для чего шелл подошёл бы лучше. Из статьи непонятно, умеет ли библиотека делать конвейер? Ведь шелл-простыни зачастую намного сложнее, что-то вроде такого:

    while read a b c; do
      grep $(sed s/1/2/ <<< $a) ... && some_command || error_handler
    done <(find ... | grep ... | tr ... | sort -u)

    В "нормальных" языках как раз часто не хватает главной фичи юникс-вея — конвейеров и всех тех непонятных штук, которые знакомы администраторам 50-го уровня:).

    P. S. Интересно, кто-нибудь подсчитывал, сколько в приведённых трёх строчках шелла строк кода на Си (ну ладно, хотя бы на Питоне). Естественно, если делать по-честному, не прибегая к вызову system.
  • Обстоятельно о подсчёте единичных битов
    +1
    Результаты этого теста:

    Xeon E5-2680
    Bitslice(7)            2493617 us; cnt = 32500610
    Bitslice(24)           2209648 us; cnt = 32500610
    Lauradoux              1224743 us; cnt = 32500610
    SSE2 8-bit              773552 us; cnt = 32500610
    SSE2 16-bit             746455 us; cnt = 32500610
    SSE2 32-bit             906400 us; cnt = 32500610
    SSSE3                   500734 us; cnt = 32500610
    16-bit LUT             1180070 us; cnt = 32500610
    8-bit LUT              1233562 us; cnt = 32500610
    gcc popcount            298926 us; cnt = 32500610
    gcc popcountll          171961 us; cnt = 32500610
    FreeBSD version 1      2614572 us; cnt = 32500610
    FreeBSD version 2      1890065 us; cnt = 32500610
    Wikipedia #2           1290699 us; cnt = 32500610
    Wikipedia #3            882481 us; cnt = 32500610
    HAKMEM 169/X11         2994177 us; cnt = 32500610
    naive                 19328131 us; cnt = 32500610
    Wegner/Kernigan       13590515 us; cnt = 32500610
    Anderson               5804584 us; cnt = 32500610
    8x shift and add      12111373 us; cnt = 32500610
    32x shift and add     14550016 us; cnt = 32500610
    OpenMP Bitslice(7)            5874879 us; cnt = 32500610
    OpenMP Bitslice(24)             83787 us; cnt = 32500610
    OpenMP Lauradoux                54328 us; cnt = 32500610
    OpenMP SSE2 8-bit               37482 us; cnt = 32500610
    OpenMP SSE2 16-bit              39181 us; cnt = 32500610
    OpenMP SSE2 32-bit              43241 us; cnt = 32500610
    OpenMP SSSE3                    31971 us; cnt = 32500610
    OpenMP 16-bit LUT               70153 us; cnt = 32500610
    OpenMP 8-bit LUT              7236100 us; cnt = 32500610
    OpenMP gcc popcount             34359 us; cnt = 32500610
    OpenMP gcc popcountll           35332 us; cnt = 32500610
    OpenMP FreeBSD version 1       281157 us; cnt = 32500610
    OpenMP FreeBSD version 2       198496 us; cnt = 32500610
    OpenMP Wikipedia #2            156282 us; cnt = 32500610
    OpenMP Wikipedia #3            114159 us; cnt = 32500610
    OpenMP HAKMEM 169/X11          230414 us; cnt = 32500610
    OpenMP naive                  1674378 us; cnt = 32500610
    OpenMP Wegner/Kernigan         654721 us; cnt = 32500610
    OpenMP Anderson                960991 us; cnt = 32500610
    OpenMP 8x shift and add       1583529 us; cnt = 32500610
    OpenMP 32x shift and add       957853 us; cnt = 32500610


    Core i7-3770
    Bitslice(7)             620813 us; cnt = 32500610
    Bitslice(24)            588943 us; cnt = 32500610
    Lauradoux               343854 us; cnt = 32500610
    SSE2 8-bit              258616 us; cnt = 32500610
    SSE2 16-bit             263849 us; cnt = 32500610
    SSE2 32-bit             301500 us; cnt = 32500610
    SSSE3                   177150 us; cnt = 32500610
    16-bit LUT              604952 us; cnt = 32500610
    8-bit LUT               857176 us; cnt = 32500610
    gcc popcount            234420 us; cnt = 32500610
    gcc popcountll          151301 us; cnt = 32500610
    FreeBSD version 1      1581670 us; cnt = 32500610
    FreeBSD version 2      1112433 us; cnt = 32500610
    Wikipedia #2            675289 us; cnt = 32500610
    Wikipedia #3            532715 us; cnt = 32500610
    HAKMEM 169/X11         1568815 us; cnt = 32500610
    naive                 12706907 us; cnt = 32500610
    Wegner/Kernigan        9730186 us; cnt = 32500610
    Anderson               3546174 us; cnt = 32500610
    8x shift and add       8769728 us; cnt = 32500610
    32x shift and add     10844191 us; cnt = 32500610
    OpenMP Bitslice(7)             917011 us; cnt = 32500610
    OpenMP Bitslice(24)            721363 us; cnt = 32500610
    OpenMP Lauradoux               883048 us; cnt = 32500610
    OpenMP SSE2 8-bit              230228 us; cnt = 32500610
    OpenMP SSE2 16-bit             117210 us; cnt = 32500610
    OpenMP SSE2 32-bit             131941 us; cnt = 32500610
    OpenMP SSSE3                   248196 us; cnt = 32500610
    OpenMP 16-bit LUT              486344 us; cnt = 32500610
    OpenMP 8-bit LUT               380845 us; cnt = 32500610
    OpenMP gcc popcount            266826 us; cnt = 32500610
    OpenMP gcc popcountll          108274 us; cnt = 32500610
    OpenMP FreeBSD version 1       839581 us; cnt = 32500610
    OpenMP FreeBSD version 2       906064 us; cnt = 32500610
    OpenMP Wikipedia #2            918286 us; cnt = 32500610
    OpenMP Wikipedia #3            593741 us; cnt = 32500610
    OpenMP HAKMEM 169/X11         1054673 us; cnt = 32500610
    OpenMP naive                  3531085 us; cnt = 32500610
    OpenMP Wegner/Kernigan        2340468 us; cnt = 32500610
    OpenMP Anderson               1557932 us; cnt = 32500610
    OpenMP 8x shift and add       3044832 us; cnt = 32500610
    OpenMP 32x shift and add      3624641 us; cnt = 32500610


    POWER
    Bitslice(7)            1360812 us; cnt = 32500610
    Bitslice(24)           1271885 us; cnt = 32500610
    Lauradoux               447454 us; cnt = 32500610
    16-bit LUT             1249726 us; cnt = 32500610
    8-bit LUT              2103832 us; cnt = 32500610
    gcc popcount            431113 us; cnt = 32500610
    gcc popcountll          220803 us; cnt = 32500610
    Wikipedia #2            982466 us; cnt = 32500610
    Wikipedia #3            763969 us; cnt = 32500610
    HAKMEM 169/X11         2067571 us; cnt = 32500610
    naive                 24156131 us; cnt = 32500610
    Wegner/Kernigan       22806373 us; cnt = 32500610
    Anderson               3879566 us; cnt = 32500610
    OpenMP Bitslice(7)             814847 us; cnt = 32500610
    OpenMP Bitslice(24)            112392 us; cnt = 32500610
    OpenMP Lauradoux               131094 us; cnt = 32500610
    OpenMP 16-bit LUT              120421 us; cnt = 32500610
    OpenMP 8-bit LUT               109915 us; cnt = 32500610
    OpenMP gcc popcount            142351 us; cnt = 32500610
    OpenMP gcc popcountll          154243 us; cnt = 32500610
    OpenMP FreeBSD version 1       126954 us; cnt = 32500610
    OpenMP FreeBSD version 2       126668 us; cnt = 32500610
    OpenMP Wikipedia #2            113159 us; cnt = 32500610
    OpenMP Wikipedia #3            122584 us; cnt = 32500610
    OpenMP HAKMEM 169/X11          134424 us; cnt = 32500610
    OpenMP naive                   747296 us; cnt = 32500610
    OpenMP Wegner/Kernigan         409483 us; cnt = 32500610
    OpenMP Anderson                216775 us; cnt = 32500610

  • Обстоятельно о подсчёте единичных битов
    0
    Осталось дождаться, когда Microsoft сделает Windows для power:)
  • Обстоятельно о подсчёте единичных битов
    0
    Померил для 32битного int — popcnt быстрее самого быстрого варианта с таблицей на 64К в 2 с небольшим раза (на core i5). Всё подряд предлагаемое прогнать нереально:) Ждём когда автор доберётся до гитхаба. Или найти в гугле готовые тесты… Например, вот этот: http://www.dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html
  • Обстоятельно о подсчёте единичных битов
    0
    Пользуясь случаем, сообщу, что runexe по ссылке мертва, а ещё меня терзают смутные сомнения, что я смогу повторить запуск этих тестов, например, на power.
  • Обстоятельно о подсчёте единичных битов
    +2
    Я немного не об этом. Нельзя загрузить этот код, выполнить make и получить такую же табличку, верно? У меня есть возможность протестировать код на совершенно разных машинах, но нет времени его детально изучать. Но по крайней мере я выяснил, что ваш код считает время пустого цикла:) Быстрый взгляд показывает, что в программе не хватает интерфейса чтобы прогнать все тесты разом.

    Именно поэтому код следует выложить на GitHub, так как его ещё дорабатывать и дорабатывать. Чтобы не считать время пустого цикла я использовал разворот цикла на 8, после чего время, затрачиваемое на перебор значений, стало ничтожно мало.

    > гарантированно пройдя по всем значениям

    А почему цикл от 0 до N не пройдёт гарантированно все значения?

    > чтобы компилятор вообще не удалил цикл за ненадобностью

    есть volatile.

    Но хабр не для Pull Requesto-в. А про гитхаб уже сказали.
  • Обстоятельно о подсчёте единичных битов
    0
    POPCNT не будет использоваться, если не указать флаг -msse4.2, что означает либо компиляцию под определённую платформу либо шаманство с weak-функциями и потеря производительности на вызове функции. Если это узкое место, то нужно отдельно компилячить кучу версий — одну для sse4.2, одну для sse4.1… и так до sse2 который гарантированно поддерживается для 64-разрядной архитектуры.

    К сожалению представленные на ЯД исходники не позволяют мне проверить все варианты, так как я не понял, что с ними нужно делать. Могу сказать только, что на i5 __builtin_popcount выдаёт 0.1 сек для 100000000 итераций с типом int для sse4.2 и 0.3 сек без него. На Xeon паршивый результат даже с sse4.2 — 0.25, без sse — 2 секунды. На core i7 лучший результат — 0.08 сек. На power хоть и есть инструкция popcntw, но её результат тоже не впечатляет — 0.3 сек.
  • Обзор и сравнительное тестирование ПЭВМ «Эльбрус 401‑PC». Часть четвёртая — бенчмарки
    +1
    А учитывалось ли в Java-тестах то, что на Intel она использует JIT-компилятор, который по понятным причинам не поддерживает платформу Эльбрус? Тогда стократная разница — это нормальная разница интерпретатора и JIT. На эльбрусах Java будет не быстрее питона:)
  • Баг драйвера видеокарты может раскрыть просмотренное в режиме инкогнито
    +1
    Всё в порядке, уязвимость присутствует. Вообще баг не относится к какому-то конкретному браузеру — утекают изображения из офиса, просмотрщиков изображений и прочее, прочее.
  • Атака на пользователей Linux или как собрать ботнет руками админов
    0
    hotfix: перед вставкой кода напечатать ( или `.
  • Драйвер видеокарты: так чей же баг?
    0
    Проверил на разных машинах. В драйвере 358 пофикшено, в 352 ещё не пофикшено (с помощью этой программы можно получить остаточные буферы памяти). В драйверах Intel и VESA проблемы нет.
  • Драйвер видеокарты: так чей же баг?
    +1
    Если я правильно понял, то эта оптимизация имеет отношение к блоку clearMemory, но не readpixels, к тому же автор оставил блок clearMemory опциональным. Мне же было интересно сохранить весь дамп VRAM для последующего изучения. Есть вероятность что драйвер «оптимизировал» также и чтение из только что аллоцированного пустого блока. Наверное, стоит попробовать рисовать небольшой прямоугольник поверх этого буфера, чтобы драйвер пометил его как «грязный». Попробую ещё потестить с разными драйверами.
  • Баг драйвера видеокарты может раскрыть просмотренное в режиме инкогнито
    +1
    Разве непривилегированное приложение может слить дамп ОЗУ на современных ОС? Тут же речь о том, что любой Вася может даже под другим юзером запустить эту программу и увидеть содержимое вкладок браузера другого пользователя или ещё чего интересное. Вот здесь более развёрнуто.
  • Драйвер видеокарты: так чей же баг?
    +1
    В современных операционных системах принято занулять память перед тем как отдать её приложению. Это это очень хорошо, так как при выполнении malloc «мусор» в буфере окажется мусором освобождённой памяти текущего приложения, а не какого-то другого. Зануление при освобождении, как правило, не происходит (в угоду производительности) и используется на параноидальных сборках ядра Linux с патчами PAX/Grsecurity.

    Я на скорую руку переписал тест автора бага на Си: github.com/scriptum/vmem_test (go активно отказывался компилироваться). Проверил на двух драйверах под Linux: nouveau и nvidia 358.16. В драйвере nouveau эффект присутствует (да какой — данные сохраняются даже после перезагрузки), в случае же с последним актуальным проприетарным драйвером nvidia 358.16 — возвращается чёрный экран.

    Достаточно обратиться к /dev/mem по известному из вывода утилиты «lspci» офсету.

    Это очень плохая «фича». Я очень рад, что моя система запрещает обращаться к /dev/mem не только кому попало, но и руту. Так, на всякий случай.

    Проблема в том, что непривилегированный процесс, используя штатные механизмы (в данном случае — запрос видеобуфера из памяти через OpenGL), может получить данные, которые ему не принадлежат.
  • Скрипт для быстрой оценки состояния Linux систем
    0
    С фигурными можно такие финты проделывать:

    [[ $a == $b ]] && { echo "error" >&2; exit -1; }
    

    Тогда if не нужен. Ну и пользователи не-bash, скорее всего, будут ругаться.

    Или даже такие:

    {(
    	sleep 15
    )& disown;} 2>/dev/null
    THREAD=$!