LINUX.ORG.RU

Деление целых на 2 через битовый сдвиг - архаизм?

 


1

3
#include <iostream>
using namespace std;

int main()
{
	int v = 0;
	for(int i = 0; i < 2000 * 1000 * 1000; ++i) {
		v ^= i >> 1; /* i / 2 */
	}
	cout << v << endl;
	return 0;
}

Если битовый сдвиг заменить обычным делением, то время выполнения не изменится. Обе операции насколько мне известно занимают 1 такт. Запускал на x64.
Существуют ли архитектуры (arm, mips, ...), для которых эти и другие известные трюки - полноправная оптимизация?

UPD: при делении на 3, разница между сдвигом и делением ощутимая. Вопрос: как так, ведь обе инструкции за 1 такт выполняются?



Последнее исправление: nerdogeek (всего исправлений: 2)

Ответ на: комментарий от drBatty

ну скажем так - в общем случае не может. Константа она на то и константа, что при компиляции известна, а с переменной как повезет

marvin_yorke ★★★
()
Ответ на: комментарий от marvin_yorke

ну скажем так - в общем случае не может. Константа она на то и константа, что при компиляции известна, а с переменной как повезет

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

drBatty ★★
()
Ответ на: комментарий от i-rinat

Это, в общем, самая горячая точка в драйвере reiserfs.

ну а если насильно заменить на сдвиг, то что получится?

drBatty ★★
()
Ответ на: комментарий от i-rinat

Не знаю, не пробовал. Зачем тебе это вообще?

ну говоришь, много времени занимает. Просто странно всё это, gcc много лет без проблем такие вещи делает.

drBatty ★★
()
Ответ на: комментарий от drBatty

Даже так это доли процента от общей загрузки, даже когда ничего CPU-ёмкого не запущено. Мне не мешает.

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

INSTRUCTION LATENCY AND THROUGHPUT - раздел, там есть таблички - сколько у каждой интрукции задержка, и какой throughput. Для основных семейств - там ты всё найдёшь. В интернете есть сборники с интел и амд мануалов.

osh5pntp8
()
Ответ на: комментарий от arturpub

У меня не маздайная студия, но ты почти угадал. Адекватно значит есть несколько критериев, например скорость исполнения, занимаемая память, количество ошибок, наличие требуемого функционала, выпуск релиза как реальный факт. Бабаболка ты, так как я не зассу собирать с -O0, и никогда не переключался с Debug на Release — все три утверждения очень даже факт.

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

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

Да, так люди и делают. Но суть в том, что оптимизации нужны вам, ибо без них ваш код даже работать нормально не будет. Особенно на ваших ООП языках. И чем больше оптимизаций в конпеляторе - тем быстрее работает ваш код. А 95% кода пишите вы. Из-за оптимизаций конпелятора - у меня не будет тормазить ваш сайтец и т.п.

Ну и не забудь, что вся добавленная ценность в так называемой последней миле, а не битое*ских либах, которые и в глаза никто не видел ;)

Да, вы не видели эти либы, как ты не видел stdlib своего языка, но именно эти либы, и менно эта stdlib жрёт 90% процессорного времени и делают 99% полезной работы.

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

osh5pntp8
()
Ответ на: комментарий от arturpub

Оу, и расскажи мне, как умный конпелятор, кроме оптимизации деления сдвигом, использует префетчи, паттерны доступа к памяти, отправляет IO в aio, и вообще сам делает тебе везде хорошо? А то тут высокие технологии, а про конпелятор, с которого все началось, ты лихо забыл.

Конпелятор тут не причем - конпелятор должен давать фичи и предсказумость тем, кто пишет код. Оптимизации нужны не мне, а вам, ибо все эти оптимизации я могу сделать руками - мне не сложно, и это не тратит моё время. Вы не можете, ибо ваш ЯП/стиль написания(парадигма, абстракции и прочее)/уровень знаний/понимания не даёт вам предсказуемость, возможность и фичи - поэтому конпелятор и должен оптимизировать этот код.

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

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

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

Уж позволь полюбопытствовать, на каком языке ты собираешься писать без оптимизаций?

Waterlaz ★★★★★
()
Ответ на: комментарий от drBatty

Константа в контексте нормального конпелятора - это всё, что он может вычислить - гцц в этом царь, единственное, с чем у него хреново - это с массивами указателей, локальными функциями и прочим.

Всякие плюсовики и рядовые сишники путают const, который в 99% случаев не имеет семантики для конпелятора вообще, кроме типачекера. И на это фейлятся, и да - ты прав, нормальные тесты пишутся так, что значения переменных конпелятор не сможет вычислить.

Но многие не понимаю силу гцц, и питушт что-то типа uint64_t i = 100500 + (rand() % 2); - это для гцц тоже константа, и если ты заюзаешь такой счётчик, то велик шанс, что гцц выпилит 100500 итераций и оставит 1итерацию с test.

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

ICC пошел ещё дальше - и выпиливает вообще всё, поэтому на нём очень сложно писать тесты( в сишке очень сложно написать не тормазящую конструкцию, которую бы конпелятор не выкинул. Единственная возможность - это кастыли на volatile, но он тормазит - его тоже нельзя юзать в 70% бечах). Но вот код некоторых личностей( в частности всяиких там не гуманитариев, старых фортранщиков, которые еле-еле осилили примитивные конструкции сишки/плюсов) оптимизирует прексно.

osh5pntp8
()
Ответ на: комментарий от i-rinat

Даже так это доли процента от общей загрузки

не, я согласен, просто как-то странно. Ну там же явно константа 2 прописана. Может этот кусок с -O 0 компиллится? Хотя вроде и на -O0 тоже должно.

drBatty ★★
()
Ответ на: комментарий от Waterlaz

Уж позволь полюбопытствовать

не корми, лопнет.

drBatty ★★
()
Ответ на: комментарий от osh5pntp8

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

всё нормально. x-- - --x скомпилируй.

drBatty ★★
()
Ответ на: комментарий от Waterlaz

Знаешь почему -O0 так тормазит? Не потому, что конпеляторы так сильно оптимизирует - а потому, что их кодоген так устроен. Они гинерят настолько пессимизированный код, что без оптимизатора смысла его юзать просто нет.

Это равносильно глабальному volatile. Volatile не выключает потимизацию, а делает кое что другое - он не даёт коду юзать нормальной регистры,кеш и конвейер - а именно это основа производительности на том же х86. Ибо выхлоп -O0 ничем не отличается от примитивного байткода.

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

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

Поэтому всё это возможно, но это убивает мейнстрим - и этого в мейнстримных конпеляторах никогда не будет, поэтому я и не против оптимизаций в мейнстримных конпеляторах.

А язык без оптимизаций - это макроассемблер.

osh5pntp8
()
Ответ на: комментарий от drBatty

С делением да, но я и написал, что в среднем. С остальной частью алу ничего не менялось уже лет 7.

osh5pntp8
()
Ответ на: комментарий от drBatty

Это примитивный случай. Это просто выражение - гцц это считать умеет. И результат его будет x - (x-2); Хотя это уб и так никто не пишет, причем это примитивное, каноническое УБ, которое не имеет смысла.

Берутся подвыражения и для каждого значения юзает is_constant(t). Всё, что можно вычислить - гцц заменяет на константы, остальное оставляет.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Это примитивный случай. Это просто выражение - гцц это считать умеет. И результат его будет x - (x-2); Хотя это уб и так никто не пишет, причем это примитивное, каноническое УБ, которое не имеет смысла.

смысло оно конечно не имеет, но вот компилятор его может в два потока посчитать на одном ядре. Не такой уж и простой случай. А с -O2 дык вообще константный 0 делает.

Берутся подвыражения и для каждого значения юзает is_constant(t). Всё, что можно вычислить - гцц заменяет на константы, остальное оставляет.

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

drBatty ★★
()
Ответ на: комментарий от osh5pntp8

А тебе не кажется, что риальный торамаза возникает, когда например план неправильно построился, или кто-то заюзал массив вместо сета, или стал искать в нем перебором среди over9000 элементов? Уверен, что проблема риальны тормаза именно в -O0? Про O() слышал?

Я вот помню время 386, sx/dx, mxx, pro, и как-то не было проблем с тем, что частоты на полтора порядка меньше чем сейчас, OoO был в зачаточном состоянии, а кеш был съемным чипом на материнке. И прикинь, были энтерпрайз БД, числодробилки, и анскильная 1с.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

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

arturpub ★★
()
Ответ на: комментарий от drBatty

смысло оно конечно не имеет, но вот компилятор его может в два потока посчитать на одном ядре. Не такой уж и простой случай. А с -O2 дык вообще константный 0 делает.

Какие такие потоки? Конпелятор ничего не может. Из чего он делает 0?

Это очень простой случай.

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

Ну опиши случаи - какие там могут быть случаи - это выражение вычисляется не сложнее, чем x = x - x;

Так ты говоришь какую-то несвязную глупость.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Я еще знаешь чего в толк не возьму? Вот разные процессоры, разные особенности. Но конпелятор, или мартышка с ассемблером (упаси б-г), упорно генерит префетчи, паттерны, анроллы и тому подобную байду, даже не спрашивая себя: «а какого размера кеш-линия?», «а сколько их?», «а что там с mop-кешем, длиной очереди?», «а какова латентность кешей разных уровней на этой системе?», «а какая статистика по всем этим механизмам?». Я может глупые вопросы задаю, давно не интересовался этой темой, но не должен ли тот или иной алгоритм, прежде чем говорить «я оптимизирован, йоу», узнать параметры текущей системы и от них уже зарываться в разные свои ветки? Кстати особенности branch prediction тут тоже можно учитывать, если оно плавает между разными линейками чипов. С чего конпелятор взял, что размер линии такой, а трейс-кеш вот такой, поэтому... ну ты понел?

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

Конпеляторы можно писать с уже правильным кодогеном - которому не нужна оптимизация

Ждём osh5pntp8сс и osh5pntp8++.

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

просто как-то странно.

Ты не поверишь, но этот пример я привёл, потому что это «как-то странно».

i-rinat ★★★★★
()
Ответ на: комментарий от arturpub

А тебе не кажется, что риальный торамаза возникает, когда например план неправильно построился, или кто-то заюзал массив вместо сета, или стал искать в нем перебором среди over9000 элементов? Уверен, что проблема риальны тормаза именно в -O0? Про O() слышал?

Это только у касты 95%, который программисты домохозяйки. В этом мире всё массив, и твой сет тоже. Твои ООП-примитивы, и примитивные O-нотация, не учитывающая время на n=1, а так же кол-во n.

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

Я вот помню время 386, sx/dx, mxx, pro, и как-то не было проблем с тем, что частоты на полтора порядка меньше чем сейчас, OoO был в зачаточном состоянии, а кеш был съемным чипом на материнке. И прикинь, были энтерпрайз БД, числодробилки, и анскильная 1с.

Да, тогда были БД, которые выполняли сотни запросов - и то, лишь потому, что ООП было в зачаточном состоянии. Сейчас ООП бд даже 50запросов не выдаст на старье.

Да и писать тогда было проще.

Поэтому да, всё было, но из-за ООП и касты 95% всё вернулось в поднулевые.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

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

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

Да, тогда были БД... ООП... касты 95%

Поверь мне, тогда (около '00) оопнутых было не меньше, это сишка++ слегка задержалась со своей больной на голову реализацией, а вот делфисты, лисперы, смаллтакеры и прочие тиклеры и джаверы вполне себе были и писали рабочий софт.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

В общем, девяностые я провел в сознательном возрасте, и могу тебе уверенно сказать, что +10% никогда и ни у кого не было самоцелью, все всегда сводилось к минимизации O(). Не гони про ООП, я его тоже в сиплюшевом виде считаю шляпой, но это реально ничего не поменяло. Firebird был вроде переписан на плюсах — ускорился.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

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

Ты что хотел этим сказать? Звучит как-то противоречиво

nerdogeek
() автор топика
Ответ на: комментарий от arturpub

Это было, раньше. Сейчас от этого не особо есть профит, ибо кеша и братия не менялись уже лет 8. Процессоры работают с одинаковой скоростью уже те же лет 8. Меняется только память, всякие новые фичи, а ведро новомодного хасвела нихрена не быстрее тухлой коры2, даже кеш меньше и медленней.

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

Анролл на больше, чем кешлайн данных не приносит особого профита - для всех камней, но вот правило «чем больше анролишь - тем быстрее работает» - работает для всех х86, если это помещается в l1i.

Условные переходы тоже самое - один хрен он промахивает, и чем меньше их - тем меньше оверхеда. Поэтому выпил их работает для всех х86.

Вобщем 97% оптимизаций работает для всех х86, поэтому конпелятор как-то кладёт на особенности данного камня. В глибц есть фича, которая динамически меняет функции в зависимости от фич камня - это максимум, что можно придумать - тут ты прав.

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

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

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

А так да, норм пацаны об этом думают, но это требует очень много знаний и опыта, да и по х86 нормального мануала нет - поэтому половина инфы - метод тыка - это стоит очень много времени. Поэтому проще взять основные примитивные вещи, аля O-нотация, разделение на кеш/оператива и забить на всё остальное.

osh5pntp8
()
Ответ на: комментарий от arturpub

Ну что сет массив это не открытие, а вот с/д-лист не очень массив

Индексированный массив. Бревно тоже индексированный массив.

Фишка вся в том, что время на н=1 ничтожно, и вырасти может только засчет быстрорастущей функциональной зависимости от н.

http://raid6.com.au/~onlyjob/posts/arena/ - > O(n^3) реализация на сишке сливает все реализации с O(n^2) в худшем случае. Цена н имеет значение, особенно на х86.

Допустим у есть массив байт, и тебе надо проверить все значения, но у тебя есть алгоритм и такие данны, для которых надо проверить каждый 64-й байт. Вроде в 64раза быстрее, но на х86 работает так же, даже медленнее. И обычно между нормальными алгоритмами разницы не больше - порядки на приемлемых n, а канонический примеры, аля n^n vs n в реальном мире никто не юзает.

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

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

Поверь мне, тогда (около '00) оопнутых было не меньше, это сишка++ слегка задержалась со своей больной на голову реализацией, а вот делфисты, лисперы, смаллтакеры и прочие тиклеры и джаверы вполне себе были и писали рабочий софт.

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

osh5pntp8
()
Ответ на: комментарий от arturpub

В общем, девяностые я провел в сознательном возрасте, и могу тебе уверенно сказать, что +10% никогда и ни у кого не было самоцелью, все всегда сводилось к минимизации O().

Никому не интересно твоё O() - это для детей. Люди берут конкретно n, как константу, ибо в овер80% случаев оно константа. И пишут нормальную реализацию, с наиболее меньшей ценой n=1.

Вот как ты напишешь strchr()? Будет так же рассуждать, что раз уже O(n) - то всё? Только вот хоть разница между реализациями - пару порядков. И до сих пор ниодна реализация не приблизилась к скорости памяти, хотя должна.

Не гони про ООП, я его тоже в сиплюшевом виде считаю шляпой, но это реально ничего не поменяло.

ООП и ООП говного мозга - разные вещи. ООП - это сбор итак, 50лет используемых всеми моделей запила. Только вот когда люди говорят, что ООП - это круто, а остально фуфло - это идиотизм, ибо нормальный программист мыслит вне порадигм. И это не значит, что он не юзает какие-то вещи, который ООПешеры себе присвоили.

Повлияло. Просто ты этого не замечаешь. Сколько в бородатые года выходило нормальный программистов? Много, а сколько сейчас? Единицы на тысячу, ибо всех хотят сидеть на жопе, нихрена не делать и думают, что всё запилят за них, а они и дальше будут юзать примитивные кубики.

Когда поколение бородатых годов отойдёт в мир иной - ты это увидишь, и поймёшь, что это поменяло.

Firebird был вроде переписан на плюсах — ускорился.

В БД полезной работы минимум - основная работа - это парсинг недоязыка, оптимизация запросов, хранение дампов и сохранность данных - производительностью там и не пахнет. Поэтому это не показательный пример - возмножно люди переписав её - просто убрали тысячи кастылей, которые оставались с бородатых годов.

osh5pntp8
()
Ответ на: комментарий от nerdogeek

То и хотел - готовые, обощенные контейнеры из ООП языков тормазное фуфло, которое не принято юзать в нормальном коде, который притендует на «производительность».

osh5pntp8
()
Ответ на: комментарий от arturpub

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

Выжимать 10% в ущерб отлаживаемости глупое занятие, тут проще подождать полгода.

Ну далеко не 10%. Суть в том, что всё это легко отлаживать. Одно детло, котогда у тебя своя маленькая реализация массивчика, со своим аалокатором - простая как топор - в ней нечего отлаживать. А другое дело когда у тебя стл-вектор на 2к строк, в котором чёрт ногу сломит. Ассемблерный выхлоп конпелятора смотреть невозмножно, ибо функции называются как попало - код и 30строк превращается в 3000, которые абсалютно нечитаемы.

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

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

O(n^3) реализация на сишке сливает все реализации с O(n^2) в худшем случае

Примечательно, что в слившихся кейсах нет понятия мутабельности строк + строки интернятся + интернинг подлежит gc. Ни один идиот не станет писать на Lua что-то вроде:

for i = 1, n do
    text = text .. suffix
end
Хотя я согласен, это похоже на пример принципиально медленного н=1. Но мимо кассы, это вырожденный случай, для этого есть table.concat(). Уверен, в остальных случаях аналогичная картина. Показательно, что питон сливает даже с мутабельными строками, но это привет питонщикам :)

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

И сколько времени и нервов уйдет на это? Кто это оплатит? Ты серьезно такой хакер-киллер, или просто ни разу не делал проект 20-100 тыс. строк? (твоих строк там наверное 100-500).

Они были, но никому в голову не приходило писать БД на них

Я ж говорю — firebird на второй версии был конкретно переписан и ускорился. Исключение?

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

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

Это свойство возраста, а не поколения. Молодежь стремится развиваться, средний возраст уже все за****. Программисты постарели, сюрприз?

arturpub ★★
()

UPD: при делении на 3, разница между сдвигом и делением ощутимая. Вопрос: как так, ведь обе инструкции за 1 такт выполняются?

Сюрприз, деление компилятор за тебя на сдвиги заменит. И умножение на 5 заменит на какое-нибудь lea eax,[esi * 2 + eax]

anonymous
()
Ответ на: комментарий от anonymous

Там выше по треду таки не заменяет даже в хотлупе, а lea уже давно пережимает конвейер, вроде как у интела читал, что ребята не надо.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

стл-вектор на 2к строк

Юзай тогда нормальную либу адт, зачем тебе эта шаблонная пакость? Сбалансированные call/ret уже давно стоят копейки.

arturpub ★★
()
Ответ на: комментарий от osh5pntp8

готовые, обощенные контейнеры из ООП языков тормазное фуфло, которое не принято юзать в нормальном коде, который притендует на «производительность».

Тебя ждет большой сюрприз

nerdogeek
() автор топика
Ответ на: комментарий от arturpub

Примечательно, что в слившихся кейсах нет понятия мутабельности строк + строки интернятся + интернинг подлежит gc. Ни один идиот не станет писать на Lua что-то вроде:

В любом случае,O(n^2) на другом ЯП сольём O(n^3) сишке, из-за того, что n=1 дороже.

И сколько времени и нервов уйдет на это? Кто это оплатит? Ты серьезно такой хакер-киллер, или просто ни разу не делал проект 20-100 тыс. строк? (твоих строк там наверное 100-500).

Минимум. Вот тебе пример почти идеальных строк, накиданных за пару минут: http://pastebin.com/g2PzH2CY - это нормальный вариант того Сишного ужаса, который по ссылке.

Проект на 100тыс строк - это либо гуйня, либо ненужность.

Я ж говорю — firebird на второй версии был конкретно переписан и ускорился. Исключение?

Значит был написан как говно, и как я уже говоорил - 90% процессорного времени в СУБД занимает оверх самой СУБД.

osh5pntp8
()
Ответ на: комментарий от osh5pntp8

Какие такие потоки? Конпелятор ничего не может. Из чего он делает 0? Это очень простой случай.

поищи за моим никам на LF. Я там писал, пионерам в назидание. Асмовый код имеется.

drBatty ★★
()
Ответ на: комментарий от arturpub

Это свойство возраста, а не поколения. Молодежь стремится развиваться, средний возраст уже все за****. Программисты постарели, сюрприз?

Молодёшь не стремится развиваться. 95% программистов понимает компутер на уровне домохозяки - где тут развитие? Это примитивные конвейерные рабочии уровня третьего мира. Никакого развития нет. В бородатых годах молодёшь вынуждена была развиваться, ибо небыло халявного кубисобирательства за еду. Сейчас все мачтают нихрена не делать - тогда люди себе не могли такого позволить.

Программистов нет, всё держится до сих пор на бородачах из бородатых годов.

osh5pntp8
()
Ответ на: комментарий от arturpub

Мне проще написать своё, которое будет лучше любой либы, да и быстрее. И 2к строк шаблонов мне отлаживать не надо.

osh5pntp8
()
Ответ на: комментарий от nerdogeek

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

osh5pntp8
()
Ответ на: комментарий от nerdogeek

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

KivApple ★★★★★
()
Ответ на: комментарий от ziemin

Транзисторы нынче мелкие и дешёвые, так что глупо их экономить. Скорость важнее. И двоичный сдвиг быстрее на ЛЮБОЙ двоичной архитектуре, чем деление. Тупо потому что его можно выполнить за 1 такт, а деление не возможно.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.