Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)

Balancer> Для 12x12 я приводил.

Для 12x12 результаты совпали тоже.

Balancer> Я с этим на тестах рекурсивного Аккермана сталкивался. Уровень вложений не высокий, но много "ждущих" вызовов. И при передаче всего трёх int'ов на их значениях, типа (3,8,8) уже полумегабайта оперативки не хватает. Одни только вызовы...

В смысле, на каждом цикле создается несколько "глобальных" экземпляров каких-нибудь объектов? Вроде, в данном случае такого не будет. Все переменные "автоматические", runtime знает, что их можно тут же освобождать, и наверняка освобождает. Т.е. получается нормальный поиск в глубину, соответственно стека нужно только на максимальный уровень рекурсии, ни байтом больше.
По крайней мере, если я без проверки поворотов запускаю, памяти тратится совсем мало, по предварительным прикидкам - как раз на results. А вот с поворотами - попа начинается.

Сергей-4030> static int power2(int x) {
Сергей-4030> int count = 1;
Сергей-4030> for (int i = 0; i < x; i++)
Сергей-4030> count *= 2;
Сергей-4030> return count;
Сергей-4030> }
Очень интересный код.

Сергей-4030>> static int power2(int x) {
Сергей-4030>> int count = 1;
Сергей-4030>> for (int i = 0; i < x; i++)
Сергей-4030>> count *= 2;
Сергей-4030>> return count;
Сергей-4030>> }
Eretik> Очень интересный код.

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

Сергей-4030> Вам недоступно, почему такой код, а не вызов библиотечной функции? Объясняю - я думал, что полезно будет кэшировать результаты данной функции, потому и вынес ее в отдельную процедурку - а также я не знал, как ведет себя библиотечная функция, может она считает логарифмы и поэтому работает долго. В процессе тестирования оказалось, что кэширование не дает практически никакой выгоды, а поэтому вернулись к тому, с чего начали. Понятнее вам теперь?
Нет, ни разу понятнее не стало почему такой код. Наоборот, всё стало запутаннее. Кэширование... У меня складывается впечатление, что вы не в теме, т.е. не в теме кода. Ничего личного. Может вы что-то забыли и перепутали? Если не хотите продолжать разговор, давайте замнем и забудем.

Сергей-4030>> Вам недоступно, почему такой код, а не вызов библиотечной функции? Объясняю - я думал, что полезно будет кэшировать результаты данной функции, потому и вынес ее в отдельную процедурку - а также я не знал, как ведет себя библиотечная функция, может она считает логарифмы и поэтому работает долго. В процессе тестирования оказалось, что кэширование не дает практически никакой выгоды, а поэтому вернулись к тому, с чего начали. Понятнее вам теперь?
Eretik> Нет, ни разу понятнее не стало почему такой код. Наоборот, всё стало запутаннее. Кэширование... У меня складывается впечатление, что вы не в теме, т.е. не в теме кода. Ничего личного. Может вы что-то забыли и перепутали? Если не хотите продолжать разговор, давайте замнем и забудем.

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

А с разговором - да чего бы не продолжить, продолжим. Что именно вам не нравится? Вам хочется битовым сдвигом это сделать? Или библиотечной функцией? Можно было и так и так. Можно оставить как есть, это решение тоже работает. Видите ли, когда я писал эту функцию я еще не знал, как конкретно будет имплементироваться мое решение, в частности, не знал, не придется ли мне имплементировать операции над очень длинными целыми, длиннее чем long (и соответственно не знал, смогу ли я использовать битовый сдвиг). Поэтому я написал заглушку, работающую и предоставляющую схему для дальнейшего рефакторинга. Рефакторинга в итоге не понадобилось, вот и все. Имплементация этого участка кода совершенно не влияет на общую задачу. Если бы оптимизация конкретно этого участка мне понадобилась бы - эта оптимизация была бы сделана, при том не повлияла бы на остальной код. Доступно теперь? Или у вас все всегда выходит на 100% чисто? Вы сами не смогли алгоритм придумать и имплементировать, и теперь цепляетесь к частностям? Или вам просто не терпится "отомстить" после того, как вас в лужу помакали с вашими неандертальскими предрассудками? Не самая лучшая стратегия, надо признать. Вы вроде не такой глупый человек, должны бы признаться, хотя бы самому себе, что не подумав несли херню и в том, что потом вас немного повозили виноваты только вы и никто более.

Сергей-4030> Вы в смысле не знаете и что такое кэширование тоже? Для вас кэширование - это только когда файлы с диска в оперативную память подчитываются заблаговременно? Табличные функции - слыхали такое?
Внимательно перечитайте, что вы написали. Кэширование с диска - это отнюдь не "заблаговременно". "Заблаговременно" - это префетч. Табличные функции - это еще не кэширование и далеко не всегда кэширование.

Сергей-4030> А с разговором - да чего бы не продолжить, продолжим. Что именно вам не нравится?
поскипано

Много слов и ничего по делу.
Кэширование в данном случае(power2) вообще от балды взято. Это ясно любому, кто удосужится разобрать немного код. Разберитесь еще раз.
Сама же функция просто смехотворна равно как и оправдания. Последний раз я видел такие "фокусы" когда разговаривал с "я-тоже-программистами от Басика" желающими взяться за С++. Они выдавали такие же секвенции кода. Признайтесь, Сергей, это не ваш код. У вас написано, что вы - С++ и вы - ФПМ! Т.е. этого не может быть никогда.

Balancer> Eretik, обратите внимание на мой код на Питоне. Там используются многоразрядные сдвиги. Это решение одно из первых в голову приходящее. В Питоне они есть на уровне языка. В Java и Си - нет.
Я не знаю Питона, да и в ваш код не заглядывал. Заглянул в код Сергея( я его просил не публиковать пусть и в шуточной форме), и почесал репу.

Balancer> Вопросы по отдельной сдвиговой функции ещё остаются?
О, их, как минимум два или три. И все сильно флеймоопасные. Поэтому пока что воздержусь. А то опять начнется крик.

Balancer> Вы, всё же, напишите вариант на Си. А то со стороны ситуация смешной кажется...
Во-первых, это уже обсуждалось.
Во-вторых, до сих пор условия оглашены не были.

Eretik> Внимательно перечитайте, что вы написали. Кэширование с диска - это отнюдь не "заблаговременно". "Заблаговременно" - это префетч. Табличные функции - это еще не кэширование и далеко не всегда кэширование.

В данном случае - кэширование. Вернее, было думано о кэшировании и сделано под кэширование. Все равно недоступно?

Eretik> Кэширование в данном случае(power2) вообще от балды взято. Это ясно любому, кто удосужится разобрать немного код. Разберитесь еще раз.

У меня с кодом проблем нет. У Балансера и Муркта - вроде, тоже нет. Ваше мнение - неважно, после всей мути, которую вы насочиняли.

Eretik> Сама же функция просто смехотворна равно как и оправдания. Последний раз я видел такие "фокусы" когда разговаривал с "я-тоже-программистами от Басика" желающими взяться за С++. Они выдавали такие же секвенции кода. Признайтесь, Сергей, это не ваш код. У вас написано, что вы - С++ и вы - ФПМ! Т.е. этого не может быть никогда.

Это мой код.

ЗЫ Кстати, посмотрел в CVS, оказывается у этого модуля три версии засубмичено, забыл уже за 4 месяца. Первый вариант был такой:

VeryLong power2(int x) {
VeryLong count = new VeryLong(1);
for (int i = 0; i < x; i++)
count = count.cloneMul(2);
return count;
}


Уже во второй версии я убрал VeryLong, потому как доска размером вплоть до 16 влезает в обычный long и мне VeryLong не понадобился.
Впрочем, это не в порядке извинения. Я ничуть не считаю текущий вариант проблемным в том контексте, где он используется. В рабочем проекте он бы не прошел, но вовсе не по тем категориям, которые, видимо Еретику не нравится. А потому, что вносит ненужные зависимости. Вообще, надо было подумать о стандартном BigInteger.

Eretik> Я не знаю Питона, да и в ваш код не заглядывал. Заглянул в код Сергея( я его просил не публиковать пусть и в шуточной форме), и почесал репу.

Вы не помавайте руками, вы напишите, какие конкретно претензии. На все ваши вопросы будут даны совершенно определенные ответы.

Balancer> Eretik, обратите внимание на мой код на Питоне. Там используются многоразрядные сдвиги. Это решение одно из первых в голову приходящее. В Питоне они есть на уровне языка. В Java и Си - нет.
В С сдвиги есть.

hsm> В С сдвиги есть.

Я про произвольную разрядность

Balancer> Я про произвольную разрядность
А в С не совсем произвольная что ли?

pokos> А в С не совсем произвольная что ли?

В Си нет целых типов более 64 бит.

Питон:

print 1<<256

115792089237316195423570985008687907853269984665640564039457584007913129639936

Balancer> В Си нет целых типов более 64 бит.

А в Питоне есть целые типы более 65536 бит?

Balancer>> В Си нет целых типов более 64 бит.
pokos> А в Питоне есть целые типы более 65536 бит?

На сколько оперативки хватит. Точнее - Int там машинный, т.е. 32 или 64 бита, а Long - неограниченный. Выведение типов - утиное.

pokos> Чудо! Чудо. Прямо так и просится дисер на тему "Риски сбоев в системах неограниченной разрядности". Сколько занятных и неуловимых глюков можно рассмотреть!

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

Можешь сюда, ещё Хаскелл добавить, у которого тоже встроенная неограниченная разрядность через GMP.

Balancer> Разъясни, чем целый (машинный) тип Питона хуже целого типа Си,...
Чо ж тут непонятного? Для простого примера берём обычный рекурсивный фильтр. При сбое в одной операции его легко может понести вразнос. Если разрядность ограничена, то эта херня длится всего несколько циклов, потом всё упирается в разрядность и происходит устаканивание. А если разрядность неограничена, то фильтр засрёт всю память до упора, и программа умрёт ВСЯ. "Очередной КА убит софтом".