Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+161
function FindPosOfStr(str1, str2) {
for (i = 0; i <= str1.length; i++) {
comp = str1.substring(i, str1.length);
comp = comp.substring(0, str2.length);
if (comp == str2) {
return i;
break;
}
}
return -1;
}Вот такое вот веселье встретилось в одном проекте. Кто-то был сильно пьян и забыл про indexOf
Запостил: 
_rMX_,
22 Мая 2014
Follow us!
конечно там будут проблемы с 7b-7f.
Способ для англосаксов и юзеров унылых оджнобайтовых кодировок? С русским в utf-8 такое явно не прокатит, да и с остальными тоже.
Ох ты ж! Меня только что осенило почему grep -i работает в десяток раз медленее тупой регулярки grep -E.
Особо заметно на гигабайтных логах.
>Способ для англосаксов и юзеров унылых оджнобайтовых кодировок?
Будто это что-то плохое. Вон PHP6 не взлетел отчасти из-за UTF-16.
Ну сделай мне переход по индексу за O(1). В пейсоне в юникоде имхо не utf-8
Однобайтовые - koi8-r, cp1251, cp866 и прочие.
http://stackoverflow.com/questions/13819635/why-is-grep-ignore-case-50x-times-slower
Оказывается баг давно уже просили исправить, но нихера, вот пусть люди годами страдают:
https://bugzilla.redhat.com/show_bug.cgi?id=194471
Понятно что коды конвертации регистронезависимых локалей - наслоения говна (из-за дикой сложности вопроса), и как оказалось реализации тормозные.
Какие выводы можно сделать из этой истории?
Во-первых, регистронезависимые языки с возможностью давать имена переменным НЕ на латинице - отстой.
Во-вторых, как и недавний пример с yasmом, сиё в очередной раз подтверждает, что новое железо, его разгон и прочая требедень особо много не даёт. Нормальные алгоритмы и даже мелкий тюнинг существующих способны скоротать ожидание в десятки раз. То есть в умелых руках даже селерон Тараса может оказаться быстрее нового 4-х ядерника.
В этом вся и проблема. Оно оказывается постоянно! лазает за лоКАЛью в файлы /usr/lib/locale/locale-archive, /usr/lib/gconv/gconv-modules.cache
Во говно.
RC конечно не нужен.
Напомните если вдруг заметите, что он вышел.
У них нету твиттера или RSS?
Чем минт не убунта? Такое же быдлячество, только с нескушными обоями.
Убунта, так же как и xubuntu, lubuntu, kubuntu, edubuntu, huibuntu, pizdabuntu, djigurdabuntu и прочие.
Просто мне влом менять шило на мыло ставить другую ось из этого семейства. Тем более отличаются они только DE и WM, которые спокойно можно доустановить и выбирать при логине хоть каждый день.
P.S. Кстати есть забавный эффект - если поставить lxde, то на загрузке будет показываться, что это lubuntu. А xfce меняет надпись на xubuntu. Что как бы намекает ;)
Тоже видел такой эффект, у знакомого стояла kubuntu, а после перехода на унити k исчезла.
>Убунта, так же как и xubuntu, lubuntu, kubuntu, edubuntu, huibuntu, pizdabuntu, djigurdabuntu и прочие.
Ну так я и грю - та же убунта, только с нескушным оконным менджером, всё ведь тоже - linux, debian, dpkg, apt get.
Мне тоже друг пару лет втирал, что норм. А потом, внезапно, начал выбирать другой дистриб :)
Если говорить обо мне - то я в генте вообще никакого профита не вижу:
* Быстрее работает из-за тюнинга и -O3? Да хрен там, если прирост и есть, то на глаз не заметишь. А ту пару прог, где реально помогла бы оптимизация (сжатие видео и т.п.) в любой линухе можно пересобрать самому (если вдруг понадобится).
* Можно отключить флагами ненужные фичи? В большинстве случаев это только минус, т.к. добавляет возни, когда эта фича все-таки понадобится.
* Кастрированное Кастомное Ядро? Ну так это в любой линухе можно
сделать, но зачем? Полное ядро не так уж много памяти жрет, да и не так уж долго грузится, зато при покупке новых устройств его не надо пересобирать.
* Удобный пакетный менеджер? Зато вычисление зависимостей тормозное как говно (или уже пофиксили с тех пор?). А уж про скорость установки/обновления софта вообще молчу...
Ну оно ж еще через --march --mtune оптимизируется под конкретную тачку.
Однако тормоза крестокомпилера съедят при постоянном рекомпайле всего кода.
>А ту пару прог, где реально помогла бы оптимизация (сжатие видео и т.п.) в любой линухе можно пересобрать самому (если вдруг понадобится).
+100. и быстрее чем оно попадёт в офф репы, и свои патчи можно накатывать. Скорость нужна в совсем небольшом подмножестве программ, перекомпиливать вообще всё - неэффективно.
Так и живём.
На х86_64 не особо актуально.
Это почему?
Всё зависит от того какие SSE/AVX есть. Обычные сборки компилят march=i686, то есть самое распространённое, чтоб бинарник работал у всех.
На x86_64 первый SSE подразумевается (а может даже и второй до кучи), т.к. процов данной архитектуры без SSE просто не существует.
А вот с последними SSE и AVX march+mtune пригодятся, согласен.
?
А почему, блжад, не делать определение фич проца в рантайме и выполнение нужной ветки кода?
А так ведь делают. Вроде как в so можно запихать функции с одним именем, но разной реализацией. И компоновщик выберет нужную
Другое дело, что это имеет смысл только для небольшого числа функции, вроде кодеков.
Во-первых gcc компилит не только под х86, но и под армах, х86_64 и хрен знает что еще. Поэтому один бинарник под все подряд, увы, не сделать. march все равно понадобится.
Во-вторых, для большинства прог заточка под архитектуру нахер не нужна, т.к. у них производительность упирается в ожидание пользователя, а не в проц. И только гентушники, которым нечем заняться, собирают с максимальной оптимизацией каждую прогу...
В-третьих - эти проверки неплохо раздуют код, да еще и замедлят его. Поэтому вставлять их надо где-нибудь поближе к внешнему краю алгоритмов, до чего компилятор хер додумается даже с profile-guided optimization. Придется самому херачить ифы.
Ну и в-четвертых - никому не хочется возиться с этой сошкой-под-все-интелы. Собрать сошку и прогу под Комп Тараса (i686), по оптимизнутой сошке под каждую важную платформу и дать желающим исходники под остальные на порядок проще и надежней.
Это вопрос стандартизации мультибинаря.
> вставлять их надо где-нибудь поближе к внешнему краю алгоритмов, до чего компилятор хер додумается
ICC делает много бинарей в одном "под каждое" расширение платформы.
Ужс. Бинарники и так огромные, так еще и несколько копий внутри... Мультибинарники нинужны. Профита от них почти нету, а минусов полно (огромные, один хрен не учтешь все платформы (т.е. проблему они не решают), большая часть бинарника никогда не юзается, сборка такого бинарника - ад, ибо надо тулчайн под все платформы).
Лучше уж немного поправить репы, чтобы в них были бинарники под все важные платформы, и чтобы они выбирались автоматом, в зависимости от железа. Причем даже не надо для всего софта, достаточно только для той части, которой реально нужна скорость или плюшки процессора.
Или, если хочется революционного пути - развить идею .net с их ngen'ом: бинарник на неком абстрактном асме (который транслируется в целевой асм во время установки проги) + небольшие кусочки unsafe кода с реальным асмом целевых платформ (если нужна скорость или особые команды).
Сказал человек с восьмитерабайтным винтом.
У меня всего 2 терабайтника в компе. И те зеркалом включены.
У меня VPS-ка с гигабайтом места, тащемта. Поставил два-три приложения, поднял сервис, вот место и того.
Он и не нужен, но что мешает хотя бы под все x86 или x64? Судя по твоим коментам, ты просто не понял идею.
Ага, и попробуй недельку не обновляться - конфликтов десяток тебе накидает - сиди, разбирайся, красноглазый. И установка софта иногда часами длится, в бубунте даже тяжёлые пакеты практически моментально устанавливаются.
Бубунтоводы тоже, конечно, порой ведут себя как мудаки, но у них мейнстрим и развитая инфраструктура (т.е. многое наконец удобно). К тому же, они потихоньку слазят с пистона на плюсы + qt, что весьма положительно сказывается на производительности.
Я даже подумываю пару плагинов для бубунтового Dash падсибя на крестах написать.
Говнопоиск на govnokod.ru теперь прямо в вашем Даше
я даже было хотел поставить ubuntu-sdk и сделать всё по инструкции, но эти редиски умудрились воткнуть зависимость ubuntu-sdk -> unity8, который мне нафиг не упал. Придётся всё делать по старинке, тектовым редактором и консолечкой.
А какой в этом вообще смысл? Вы конечно будете смеяться, но
слакварь+crux4slack, вот это "всё делать по старинке". Зачем что-то еще? А так одну еблю заменяем другой, более навороченной и изощрённой.
желаю удачи при сборке ffmpeg с его сотнями зависимостей
И вроде как -O3 дает не всегда лучший результат, но тут надо уточнять у байтоёбов
>* Можно отключить флагами ненужные фичи? В большинстве случаев это только минус, т.к. добавляет возни, когда эта фича все-таки понадобится.
Я выпиливаю gtk3 при наличии рабочего gtk2
>* Удобный пакетный менеджер? Зато вычисление зависимостей тормозное как говно (или уже пофиксили с тех пор?)
Тут надо фиксить питон :)
Из плюсов могу добавить
* наличие 9999 пакетов;
* нет связи между ебилдами и тарболлами; ебилды и distfiles можно обновить простым копированием;
* легко написать свой ebuild;
* portage, который собирает пакеты в песочнице и ставит их во временную директорию, а потом мерджит с корневой фс. Так что оптимусы и кривые пакеты идут мимо и гарантировано не испортят систему;
* openrc поприятнее upstart или что там в бубунте;
* отсутсвие самодеятельности(никаких автозапусков, перезапусков сервисов итд);
* установленные заголовочные файлы в системе;
* в случае выпиливания интернетов, у меня будет куча исходников :)
Вот собирал недавно. Не смог прилинковать к проекту пока его a-файлы(lib). Это только в линкере gcc порядок библиотек важен? Вроде в студии такой проблемы нет. Они долбанулись? В студии даже из кода можно библиотеки прагмой подключать.
лог в студию
вроде всегда было пофиг на порядок. Я не разу не ловил из-за этого ошибки
ни разу не пофиг
Линковка идёт линейно слева направо, при этом каждый раз прилинковываются только недостающие символы. Поэтому если ты линкуешь с флажками -lA -lB, при этом либе B требуется либа A, ожидай ошибку линковки. Циклические зависимости между либами требуют повторений в цепочке линковки.
Ок, пришлю. Может вечером попинаю.
> Циклические зависимости между либами требуют повторений в цепочке линковки.
Это как и почему?Чтобы разрулить надо писать -lA -lB -lA -lB?
поскольку линкуются только недостающие символы, слинковать либу придётся несколько раз
> Чтобы разрулить надо писать -lA -lB -lA -lB?
да
В случае с gnu ld - вроде бы нет. Емнип, он просто отбрасывает те либы, на которые слева нет ни одной ссылки. И если хоть одна функция из либы пригодится хоть кому-то слева от нее - все ссылки разрулятся как надо, даже если есть цикл и каждая либа упомянута 1 раз...
P.S. О других *nix'овых линкерах я не знаю, не работал с ними. Может быть там и -lA -lB -lA -lB -lA -lB придется писать, при совсем уж неудачной зависимости ;)
у меня довольно старые сведения, но вроде они подтверждаются Про --start-group / --end-group не знал, занятно.
Провел эксперимент сейчас - оказывается, все сильно зависит от структуры либы. Отбрасываются, судя по всему, ненужные объектники, входящие в состав архива.
1) 1.a состоит из 1.o, 2.a состоит из 2.o, функция в 1.o юзает функцию из 2.o и наоборот, main.o юзает функцию из 1.o - работает порядок main.o 1.o 2.o, не работает порядок main.o 2.o 1.o (2.o отбрасывается).
2) 1.a состоит из 11.o и 12.о, 2.a состоит из 21.o и 22.о, функция в 11.o юзает функцию из 21.o, 21.о - 12.о, 12.о - 22.о, а 22.о - 11.о, main.o юзает функцию из 11.o - нужен порядок main.o 1.a 2.a 1.a 2.a (либо --start-group) т.к. в первый раз из 1.a отбрасывается 12.o, а из 2.a - 22.o.
P.S. А вообще, циклические зависимости нинужны. Ведь можно разбить либу на две, тем самым убрав цикл.
Согласен, я их в жизни и не видел никогда. Просто по случайности знаю, как их надо линковать.
Это "оптимизация", отбрасывающая "нинужные" либы. В старых ld такой херни вроде не было, они в любом порядке собирали :)
?
При этом все популярные дистрибутивы (включая бубунту) переезжают на systemd. Я сломал свою генту, пытаясь посмотреть на ней третий гном, у которого, как известно, systemd в зависимостях.
Место жалко? :)
> Тут надо фиксить питон :)
Так там вроде бы не столько в питоне говно, сколько в самой структуре репы - емнип, текстовые файлики без индексирования.
> легко написать свой ebuild
В дебианоподобных тоже. Правда пропихнуть в апстрим не так просто, но это, отчасти, даже плюс.
> установленные заголовочные файлы в системе
Ставишь соотв. deb пакет, и проблема исчерпана.
Дока у дебиана паршивая, нужно это признать. У бубунты тоже. Непросто собирать пакеты, по собственному опыту знаю.
Ну смотря для чего... Падсибя - не особо сложно. В репу убунты - так там сборка, скорее всего, будет меньшей из проблем. Хотя мне на домашнем ПК обычно лениво этим страдать, и я ставлю make install'ом в /opt или /home/opt.
man eix
>Место жалко? :)
часто флаги взаимоисключающие
>Так там вроде бы не столько в питоне говно, сколько в самой структуре репы - емнип, текстовые файлики без индексирования.
Да, и они еще обрабатываются bash
Но еще есть проблема - вся обработка идет в один поток
Да отлично он собирается. Я его даже в mingw собирал руками.
И не сотни их, а пару десятков. То что _реально_ используется наверняка в системе уже есть.
Большая часть тех зависимостей - ненужная херь, в принципе. Ну не слинкуется он с какой-то внешней либой, и что?
Тем более они выключены по дефолту и сборке основного кода не мешают. Нахера мне всё это, я даже не знаю что значит большая часть этих форматов:
Знаю только aac, но libfaac - бесперспективное, устаревшее дерьмо.
В досовксой поди?
Еще и досбокс ставить ради аськи? Мсье знает толк в извращениях.
P.S. А досовская аська вообще существует?
http://www.freedos.org/software/?prog=lsicq
Я всё больше убеждаюсь во мнении, что защитники природы должны устраивать не день Земли, который к слову порождает чудовищные перегрузки и скачки в энергосетях, не переводы часов на зимнее время, которые отнимают у нас здоровьё. Нет.
Им надо истово бороться за полное уничтожение данного дистрибутива. Сколько электричества было сожжено даром, а...
http://stackoverflow.com/questions/18527604/could-gpu-accelerate-gcc-g-compilation
When I'm building my gentoo system, my nvidia gpu is usually unused, can I make some use of it?
return i;
break;
}
а вдруг цикл дальше начнет выполняться
что делает comp = str1.substring(i, str1.length);?
>> а вдруг цикл дальше начнет выполняться
Поверьте, функция работает корректно. Просто она ужасна сама по себе. :)
>> что делает comp = str1.substring(i, str1.length);?
Отрезает от первой строки кусок с позиции счетчика цикла до конца.