Вышла новая версия программы для поиска документов RFC с интерфейсом на curses — 0.4.
Новые возможности:
Обновление базы документов RFC:
rfcreader -update
>>> Подробности
Сразу скажу, не уверен, что такое вообще существует в природе, ибо требования у меня противоположны всему, что сейчас воспринимается как мейнстрим. В общем, нужна CMS для сайтов, которые заведомо _не_ относятся (и никогда не будут относиться) к категории «высоконагруженных». При этом имеются два совершенно категорических требования:
1) свободное распространение и использование без ограничений (в том числе без всяких обязательных ссылок и т.п.)
2) ничего тьюринг-полного на стороне клиента; JS, HTML5, CSS3 запрещены под страхом смертной казни, то есть если CMS генерит что-то из перечисленного, то она не рассматривается вообще, вот то есть даром не нужна; в идеале — генерит XHTML и использует мелкий CSS-файлик на десяток классов;
Кроме того, есть ещё несколько более мягких, но тоже существенных пожеланий:
3) Язык реализации. В идеале она вообще должна быть написана на C или C++ с использованием минимума (лучше — zero) внешних библиотек, но такого, скорее всего, не бывает. PHP я терпеть ещё готов, Perl с его системой библиотек и dependecny hell — уже с трудом, что касается Питона, Руби, Джавы и прочей экзотики — мне проще будет её самому написать. Или без сайта обойтись.
4) Хранилище. Идеальная с моей точки зрения CMS не использует никакие СУБД вообще от слова совсем, то есть даже SQLite. Для хранения всего и вся — обычные текстовые файлы в обычных директориях.
5) Кастомизация. Сменные темы, среди которых есть что-нибудь лёгкое и НЕ привязанное к конкретной ширине экрана.
При этом она должна обязательно поддерживать настраиваемую навигацию, блоки, появляющиеся на определённых страницах (на всех или на некоторых), а также пользовательские комментарии (крайне желательно, чтобы пользователи могли заходить со своими OpenID — да, я имел в виду именно OpenID, а не OAUTH).
Если кто видел что-то подобное, киньте ссылочку :-)
Дистр - manjaro, i3wm. В настройках есть галочки про хинтинг, но не помогает. Подцепил репы bohoomil infinality - а в них, внезапно, версии пакетов старее.
На экране сейчас просто невероятная радуга. Вот как оно сейчас выглядит.
Никогда не сталкивался с настолько жёсткой ситуацией. Ну и как правило, обычно было достаточно обновиться с реп infinality, да выбрать fc-preset.
Этот раздел форума, как подсказывает описание, был создан «для обсуждения научных и инженерно-технических тем». Несмотря на то, что критерии «научности» разработаны уже довольно давно, и используются весьма эффективно, раз за разом в S&E появляются одни и те же споры на одни и те же не совсем научные темы.
Здесь я попытаюсь привести список самых популярных. Я понимаю что это конечно же никого не остановит от того чтобы не повторить эти темы в пятнадцатый раз, но по крайней мере это поможет не повторять одни и те же аргументы в одних и тех же спорах, а сразу давать ссылку сюда.
Итак, платиновые треды S&E (пока только современная фундаментальная физика, специалисты из других областей приглашаются добавить свои наболевшие баяны, если таковые имеются):
Никогда вопросов глупых
Сам себе не задавай,
А не то еще глупее
Ты найдешь на них ответ.
Если глупые вопросы
Появились в голове,
Задавай их сразу взрослым.
Пусть у них трещат мозги.
Привет ЛОР!
Мы с товарищами из FutureBiotech решили тут делать научпоп в формате стримов, посвященных всему, что связано с современной биологией: открытия, лекарства, технологии. Это такие апгрейженные онлайн-трансляции, где мы очень внимательно читаем комментарии в чатах и отвечаем на вопросы зрителей. Форматы бывают достаточно разные - стримы прямо из лабораторий, интервью с людьми «в теме», трансляции интересных мероприятий из области.
В этот раз мы стримим лекцию и воркшоп по биоинформатике:
Наверняка вы слышали кучу страшилок про то, что антибиотики скоро перестанут работать и человечество вымрет под гнетом инфекций от суперустойчивых бактерий. Но как же это происходит? Почему бактерии приобретают устойчивость и как они ее передают.
Сегодня в об этом расскажет обворожительная Анна Костикова, PhD в области вычислительной биологии и сравнительной геномики, University of Lausanne, Switzerland. В вводной лекции она раскроет роль облачных вычислений в биоинформатике, а в ходе воршкопа каждый сможет самостоятельно попробовать что это такое - использовать топовые научные инструменты для анализа геномов бактерий.
Ждем вас в физическом воплощении в Ключе или в 19:30 на наших канал на SC2TV и YouTube.
P.S. Записи прошлых стримов можно посмотреть на YouTube.
P.P.S. И да, смотреть можно в HTML5 а для стриминга а используется опенсорсный OBS Studio иногда даже и на онтопике.
Вот тут:
https://yadi.sk/d/1ncHf4zCmCRTJ/effective_qt.mp4
узнал такую новость.
Оказывается, QList неоптимально работает, и его собираются выпиливать из Qt. Типа, из-за того, что QList содержит указатели на хранимые значения, то значения разбросаны по памяти и плохо кешируются процом.
И в Qt6 решили выпилить QList, QStringList и заменить их stl-ным вектором. Тогда типа все будет хорошо.
Я понять не могу, а что, если вектор будет хранить указатели на хранимые значения, то будет легче? Он же не сможет хранить непосредственно сами объекты, например QString, в виду разного обжектсайза у разных строк, которые к тому же могут меняться.
Если хочешь сделать продукт, а умение внятно и просто описывать страдает? Описать что-то и я смогу, но это не лучший вариант.
Вот Спуфинг, например, могет)
Кстати, если у кого-то есть информация о том, как самому научиться нормально излагать мысли, поделитесь :)
Перемещено leave из development
Вышло обновление набора программ проекта QKkmServer — кроссплатформенного кассового сервера для ФР, использующих протокол управления ФР Штрих-М.
Возможности:
( Подробности )
>>> Сайт проекта
Скажите, какое оно? Как можно помочь проекту (и стоит ли)? Спрашиваю, ибо уже не первый год ходят разговоры о том, что вымирает постепенно коллектив. Да и сам вижу, что многие приложения давно не обновляются. Тот же blender, например.
В последнее время всё реже обновляю систему, потому что обновлений всё меньше. Есть пара команд (KDE, например), которые занимаются поддержкой, но всё дерево как будто уже не так живо, как лет 5 назад, скажем.
Я тут читаю умную книжку и автор уверенно заявляет, что #define для лох^W сишников, а плюсовики должны использовать const type var = 0;
А у меня уши растут с Си и поэтому у меня вопрос к тем, у кого сильна теоретическая плюсовая база.
Если с #define всё ясно — препроцессор просто пробежится по тексту, то с константой у меня вопрос. Будет ли выделяться под неё память? В принципе компилятор вполне может выполнить работу препроцессора и заменить встречающуюся константу на её значение. В идеале мы получим и проверку типа и никаких накладных расходов.
Или я что-то упускаю? Или я всё правильно думаю, но компилятор всё равно всё сделает через жопу?
Расскажите.
Перемещено mono из talks
Поглядел я тут на пацанов и увидел прогресс в их глазах. Поэтому я решил вести тут свой бложик, в котором я буду толкать матчасть, разбирать/разрушать всякие мифы и легенды, а так же их обсуждать с пацанами. Банить меня не надо - тут всё будет очень культурно.
Это будет формат для самых маленьких, где я буду показывать как что-то пилится по-пацаночке. Его задача - на примерах пересказать штеудмануал тем, кому лень его читать, но кто очень любит спорить про код, перфоманс и матчасть. Ну и просто интересные наблюдения.
Изначально я хотел написать про то: что такое бесплатные вычисления на примере is_range() + сумма елементов массива, но тут выявилась смешная особенность, поэтому пока без is_range().
Начнём с простого - сумма елементов(float) массива. Как написать её быстро? Обычный крестопоц сделает так:
auto summ = accumulate(begin(vec), end(vec), 0.)
Этот код выдаёт 5.6GB/s(мы всё бенчим в л1д 32килобайта массив). Казалось бы, если бы мы слушали всяких «гуру», которые нам говорят: accumulate() - оптимизирован, «ты что умнее создатели stl"а?», «конпелятор умнее тебе - сам всё делает оптимально», «руками что-то делать слишком сложно и не нужно» - то мы бы там и остались с этими 5.6ГБ, но мы пойдём дальше и поймём почему так, и является ли это тем, что намн ужно.
Но посмотрев на код - он не векторизован:
addq $4, %rdx
vcvtss2sd -4(%rdx), %xmm2, %xmm2
vaddsd %xmm2, %xmm1, %xmm1
Почему? Патамучто это основная флоатпроблема: Он не ассоциативен - флоат не имеет в себе точных представлений всех чисел входящих в диапазон его «представления» т.е. порядкопроблемы.
Поэтому конпелятор НЕ ВЕКТОРИЗУЕТ флоат по умолчанию, ну никак. Даже такую банальщину.
Для решения этих проблем - есть ключик -funsafe-math-optimizations, который входит в -ffast-math, который кладёт на точность при вычислениях. Добавив его мы получаем уже 44.9GB/s.
Но теперь мы получаем ещё одну проблему - надо думать: «как бэ сунуть эту ключик не повредив там, где этот ключик не нужен».
Поэтому ноцанам, которые хотят быстро и не хоятт рандомных жоп из-за тупости конпелятора - пишут всё руками. Допустим на той же сишке это пишется так:
double memadd_autovec(buf_t buf) { //5.609465GB/s, либо 44.969652GB/s с ffast-math
float * it = buf_begin(buf), * end = buf_end(buf), summ = 0.;
do {
summ += *it++;
} while(it != end);
return summ;
}
double hsumf(__v8sf v) {
return (v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7]);
}
double memadd_vec(buf_t buf) { //45.652002GB/s и класть на ffast-math
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ += *it++;
} while(it != end);
return hsumf(summ);
}
Т.е. разницы никакой нет, кроме нужной нам реализации горизантального сложение вектора. Когда я говорил пацану: «векторную сишку для написания быстрого кода юзать намного проще, чем плюсы» - поцан нипонимэ, да и любые пацаны скажут - ну дак с -ffast-math оба выдают по 45гигов - нахрен эта сишка нужна?
А вот зачем:
double memadd(buf_t buf) { //132.878440GB/s
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ += *it++;summ += *it++;summ += *it++;summ += *it++;
} while(it != end);
return hsumf(summ);
}
Это называется пацанский анролл копипастой, а вот заставить конпелятор нормально что-то разанролить очень сложно.
Если бы мы слушали всяких «гуру», которые нам вещают: «анрол говно и не нужен» - мы бы так и седели с 45-ю гигами, а так мы сидим с 132.878440GB/s. Т.е. анролл нам дал немного не мало ~300%.
Но основная мысль, которую толкают всякие «гуру» - это не надо следить за тактами/считать такты и прочее. Но мы о5 сделаем наоборот и посмотрим что будет.
Т.к. наш юзкейс упирается на 99% в throughput и дёргается одна инструкция, то нам достаточно просто считать теоретическую производительность для моего камня. 4.5(частота камня)*8(т.е. у нас камень с avx, то там вектор 32байта, либо 8флоатов.)*1(throughput нашей инструкции - в данном случае vpaddps из интел мануала). Т.е. 36гигафлопс, либо ~144гига. Т.е. мы сняли овер 90% теоретической производительности - остальные 10% у нас ушли в наши циклы, всякие горизонтальные суммы вектора и прочее, ну и конечно же чтение данных из кеша.
Но самое смешное - на моём хасвеле умножение имеет throughput 0.5 - т.е. на хасвеле умножение быстрее сложения. Это новая забористая трава у интела.
Казалось бы - какой жопой сложнее оказалось медленнее умножения - а вот так, на всяких штеудах производительность уже давно зависит не от каких-то технических возможностей, а от маркетинга и хотелок.
Поэтому очень смешно слушать, когда какие-то пацаны говорят: «float point имеет такую же производительность как и инты» - нет, оно имеет такоу же производительность лишь по причине того, что на штеуде инты тормазят так же, как и float.
И чтобы окончательно в этом убедится - мы взглянем на fma(вариации умножения со сложением/вычитанем), которые имеют throughput 0.5 - да, да - на хасвеле умножение+сложение в 2раза быстрее просто сложения. Это уже не просто трава - это что-то принципиально новое.
У целочисленного сложения же throughput 0.5 и казалось бы, если мы поменяем в нашей функции float на int - у нас будет сложение работать в 2раза быстрее, но это не так. Оно выдаёт те же 130гигов, а почему?
Вообще у камня есть такая фича, допустим у нас:
add $1, %reg0//вот тут инструкция add залочит регистр reg0
add $1, %reg0//а эта инструкция уйдёт в лок до особождения предыдущей инструкцией регистра reg0
Чтобы такой жопы небыло - есть специальная фича:
add $1, %reg0//lock reg0
add $1, %reg0//И тут вместо того, чтобы уйти в лок - камень вместо reg0 даёт инструкции любой свободный регистр.
Эта фича называется прееименование регистров, либо как-то так - мне лень гуглить.
Дак вот штука в том, что фича работает через жопу. Мне лень читать мануал и искать почему так, но штука в том, что она ограничивает throughput. На умножении и целочисленном сложении она огранивает throughput c 0.5 до 1.
И вот я решил заюзать сложении через fma:
__v8sf fmaadd(__v8sf a, __v8sf b) {
return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);// a + b * 1. == a + b.
}
double memadd_fma(buf_t buf) {
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ = fmaadd(summ, *it++);
} while(it != end);
return hsumf(summ);
}
Но меня ждала жопа: 27.347290GB/s, причем не анролл и ничего не помогал. Я уж подумал, что мануал наврал, но позже до меня допёрло: у неё latency 5тактов и ((4.5×8)÷5)×4 ~= 29гигов - т.е. я получаю производительность с её latency, но какой жопой оно так?
Потом я вспомнил, что гцц гинерит анрольный код вида:
add $1, %reg0
add $1, %reg0
//а не
add $1, %reg0
add $1, %reg1
Т.е. на неё вообще не работает переименовывание регистров - и инструкции постоянно в локе. Я это проверил и оказался прав. Ну и я написал такой мемадд:
__v8sf fmaadd(__v8sf a, __v8sf b) {
return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);
}
inline void fma_10way_finality(__v8sf * cache, __v8sf * it, __v8sf * end) {
switch(end - it) {
case 8:
*(cache + 7) = fmaadd(*(cache + 7), *(it + 7));
*(cache + 6) = fmaadd(*(cache + 6), *(it + 6));
case 6:
*(cache + 5) = fmaadd(*(cache + 5), *(it + 5));
*(cache + 4) = fmaadd(*(cache + 4), *(it + 4));
case 4:
*(cache + 3) = fmaadd(*(cache + 3), *(it + 3));
*(cache + 2) = fmaadd(*(cache + 2), *(it + 2));
case 2:
*(cache + 1) = fmaadd(*(cache + 1), *(it + 1));
*(cache + 0) = fmaadd(*(cache + 0), *(it + 0));
case 0:
break;
default: error_at_line(-1, 0, __FILE__, __LINE__, "bad_aligned");
}
}
double memaddfma_10way(buf_t buf) {
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = (__v8sf){};
__v8sf * cache = (__v8sf[10]){{}};
uint64_t i = 0;
while((it += 10) <= end) {
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
i = 0;
}
fma_10way_finality(cache, (it - 10), end);
summ = (*(cache + 0) + *(cache + 1) + *(cache + 2) + *(cache + 3) +
*(cache + 4) + *(cache + 5) + *(cache + 6) + *(cache + 7) +
*(cache + 8) + *(cache + 9));
return hsumf(summ);
}
Пришлось хреначить финалити, ибо тут «анролл» на 10, а почему на 10 - для максимального throughput"а - надо, чтобы каждый каждый регистр юзался через 5тактов - т.е. 10регистров.
И вся эта порятнка нужна для борьбы с тупостью конпелятора.
Это уже: 214.167252GB/s(раельно там в районе 250 - просто мой бенч говно). 107 гигафлопс на ведро. Из теоретических 144, но тут уже влияние кеша. Причем 50+ из которых выкидываются и просто бесплатные.
Теперь вопрос к пацанам - что нам дадут эти гагфлопсы, когда у нас будет массив не 32килобайта, а 32мегабайта? Зачем нужно выживать максимум, когда скорость памяти отсилы 20-30гигабайт и нам хватит даже С++ кода с ffast-math?
Ну и призываются упомянутые мною пацаны: 
mv - этот тот експерт, что вещал про «руками переименовывать регистры не надо» и «анрол ваще ненужен», emulek вещал про ненужность счёта тактов, и не понимал что такое «беслпатно», AIv - не понимал в чем проблема плюсов, ck114 - так же не понимал в чем проблема плюсов.
Бенчи: https://gist.github.com/superhackkiller1997/606be26fa158ef75501d - вроде я там ничего не напутал.
P.S. - не выпиливайте пж, пусть пацаны «нужно» или «не нужно». Мне интеерсно. Ну и там рекомендации пацанов.
Базовая система коммутации звуковых потоков:
Программы для звукозаписи и обработки звука:
Гитарные процессоры:
Синтезаторы:
Инструменты для создания трекерной музыки:
Драм-машины:
Наборы эффектов для обработки звука:
Нотные редакторы:
18 ноября 2014 года в Хакспейс Neuron прошла лекция ncrmnt о Linux-е во встраиваемых системах.
Лекция выложена .
>>> Подробности
Кто работает с данной связкой? Сборку я победил, даже сделал так, чтобы можно было как с Qt4 собирать, так и с Qt5. Проблема появилась с install частью. Для Qt4 я юзал следующий код:
FOREACH(LANG ${LANGUAGES})
INSTALL(FILES ${TRANSLATIONS_DIR}/${TARGET}_${LANG}.qm DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/)
INSTALL(FILES ${QT_TRANSLATIONS_DIR}/qt_${LANG}.qm DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/)
ENDFOREACH(LANG ${LANGUAGES})
IF(WIN32)
INSTALL(FILES ${QT_BINARY_DIR}/QtCore4.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${QT_BINARY_DIR}/QtNetwork4.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${QT_BINARY_DIR}/QtXml4.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${QT_BINARY_DIR}/QtSql4.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${QT_QJPEG_PLUGIN_RELEASE} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats)
INSTALL(FILES ${QT_QGIF_PLUGIN_RELEASE} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/plugins/imageformats)
INSTALL(FILES ${CMAKE_BINARY_DIR}/3rdparty/QtSolutions/src/qtservice/libQtService.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
FIND_PATH (MINGW_PATH "libstdc++-6.dll")
INSTALL(FILES ${MINGW_PATH}/libgcc_s_dw2-1.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${MINGW_PATH}/libstdc++-6.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
#INSTALL(FILES ${MINGW_PATH}/mingwm10.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
INSTALL(FILES ${MINGW_PATH}/libwinpthread-1.dll DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
ENDIF(WIN32)
Вот только для Qt5 QT_TRANSLATIONS_DIR, QT_BINARY_DIR и остальные данные пусты. Как теперь их доставать?
Насоветуйте какого-нибудь аниме о музыке. Только не о всякой попсе, вроде «Beck», а что-нибудь вроде «Nodame Cantabile».
Перемещено beastie из general
Господа!
Абсолютно подходящей темы не нашёл.
Я нахожусь на стадии работы над отчётом, на которой число источников (интернет-страницы, даташиты, научные книги, нормативные документы, внутренние документы предприятия, статьи из периодических изданий и сборников статей, патентов и прочего) перевалило за сотню. Неизбежно придёт время организовать это безобразие эстетически и эргономически (отчёт будет использоваться как справочный материал в том числе).
Использую TeX Live 20130722 (бекпортирован на wheezy из sid в конце августа). Пишу код в Kile, использую UTF8. Пока норм. Строго соответствовать ГОСТу нет необходимости, но было бы желательно. После первичного гугления назрели вопросы:
Заранее спасибо за терпимость и ссылки на литературу и конкретные посты в других темах!
| ← предыдущие |