Как получить результат целочисленного деления списком?

Почитай исходники perl и поймёшь, что выигрыш в эти 5 тактов ровно никакой погоды не сделает.

ну для С по идее оптимизирущие компиляторы вызывают div один раз, когда требуется и частное и остаток от тех же делимого и делителя

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

Стало интересно проверить это утверждение. Написал простенький код и прогнал его дизасемблером.

int main(int argc, char *argv[])
{
  int y = argc / 153;
  int z = argc % 153;
  return 0;
}

Там вообще не было вызова div. Вместо div вызывается imul.

покажи выхлоп дизассемблера что ли, да и y, z должны потом где-то использоваться, иначе компилятор может вообще всю программу до return 0 соптимизировать

Разобрался, дело было в делении на константу. Такое деление заменяется на imul, который в 1.5 раза быстрее. Если подсунуть

 
int a = random();
  int y = argc / a;
  int z = argc % a;
  printf(" %d %d \n",  y, z);

То без оптимизации div вызывается 2 раза, если с -O2 то 1.

Так что вы правы.

Что значит нигде не используется? В лиспе, само собой, используется.

Я реально не могу припомнить, когда бы мне надо было и то и другое одновременно.Городить огород ради 0.0000001% случаев, когда ИРЛ в средней перл-программе из-за неоптимального использования " вместо ' на несколько порядков больше времени теряется?

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

Perl убог. Посмотри в ЛNSP truncate и values.

в средней перл-программе из-за неоптимального использования " вместо ' на несколько порядков больше времени теряется

Enjoy your perl

Перл — это тебе не форт

5 тактов? 5тактов? Эти пацаны, эти пацаны.

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

Рили, пару тактов, да вас тут целый стак. Это наверное модно быть дауном и балаболить про пару тактов везде, где только можно, да?

На Nehalem throughput 7-17 тактов, а что? Подумай сколько уйдет на конструирование списка. А вообще твоя ирония слишком тонка, я не могу понять к чему ты клонишь.

из-за неоптимального использования " вместо ' на несколько порядков больше времени теряется?

там прямо такая ОГРОМНАЯ разница?

btw, а что лучше "var = $a" или 'var = ' . $a? а если "var1 = $a ; var2 = $b" или 'var1 = ' . $a . ' ; var2 = ' . $b?

Был немало удивлён тому факту, что такая полезная особенность CISC-архитектуры Intel нигде не используется!

Ну в той же сишке используется, в ЛNСПе тоже.

там прямо такая ОГРОМНАЯ разница?

Огромная-не огромная, но её хоть померить можно (у меня в районе 5-7% получилось). Лишний div же за пределы статпогрешности не выйдет.

btw, а что лучше

Сам выбирай, что тебе важнее - 5% или читаемость :)

То без оптимизации div вызывается 2 раза, если с -O2 то 1.

Сдаётся мне, что в перле и близко такого нет.

Хотя показанная Вами оптмизация совершенно очевидна и то, что программы на Си компилируются как раз с использованием div - весьма симптоматично. Не сомневаюсь, что там деление на степень двойки заменяется на shr.

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

Да, тем, кто тут насчёт списка прошёлся - я зря конечно назвал так тему и немудрено, что меня неправильно поняли. Смысл в том, чтобы целочисленное деление возвращало два значения: частное и остаток. Как это будет реализовано на практике - совершенно неважно. Можно передавать две ссылки на переменные, можно возвращать частное как результат выполнения функции и опционально записывать остаток по ссылке на переменную.

Огромная-не огромная, но её хоть померить можно (у меня в районе 5-7% получилось).

Я оптимально использую кавычки, поэтому могу уже оптимизировать на уровне div'ов :)

Эта лалка порвалась - несите следующую.

В сортах пёрла не разбираюсь (надо внутрь смотреть), но Math/BigInt: $i->bdiv(BINT) return (BINT,BINT) division (quo,rem) just quo if sc .

На Nehalem throughput 7-17 тактов, а что?

Ну вопервых 7 у тебя ~никогда не будет. Во вторых throughput? рили? на перле?

Во вторых выйграет он вообще в районе нуля, но это не важно. Говори «весь выигрыш от сего действа нивелирует ущербность перловской конструкции, в которой ты собрался отдавать результат».

Подумай сколько уйдет на конструирование списка.

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

А вообще твоя ирония слишком тонка, я не могу понять к чему ты клонишь.

Я ни к чему не клоню. Я против балабольства про такты.

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

Какая именно лалка порвалась?

весь выигрыш от сего действа нивелирует ущербность перловской конструкции, в которой ты собрался отдавать результат

this

Понятно, же о чем речь. В чем смысл спора тогда? Еще 100 комментариев будем такты считать?

Капча «platinum pertics» намекает.

С синусом и косинусом такая же ситуация, их можно одной командой посчитать.

Понятно, же о чем речь. В чем смысл спора тогда? Еще 100 комментариев будем такты считать?

Такие балаболы уродуют психику зелёных. Т.е. если человек поверит в эти «а чё там пара тактов», то он становится просто не способен к программированию.

А потом получается так, что у пацана там поиск catch на глубину 100, парой тысячи вызовов фри в котором минимум один спинлок в каждом - выполняются пару тактов. Или пхп array стоит «пару тактов». Пацана на всё отвечают, - «да что там пару тактов», «пару тактов», «пару тактов».

Пацаны начинают верить в то, что всё говно решается «парой тактов». Кидаются «парой тактов» через каждое слово.

Этот пацан хоть «5тактов» написал, рядовой же ушлёпок написал «пара тактов» по заветам предков, как собственно сделал анонимус выше.

Это тотальные ублюдки, которые достойны тотальной аннигиляции.