рекурсия и итерация

не всё так просто — он должен. Мне — отдаёт.

Хоть в рот моча - все божья роса, ага.

у него 32-битный int, там такого числа нет.

Ах да, и вообще double — это вообще не вещественные числа. Это такое множество целых чисел, которое компьютер обрабатывает так, как будто бы они отображаются на определённые вещественные, а потом обратно.

как будто бы они отображаются на определённые вещественные

На рациональные.

или, если еще более точно - на диапазоны рациональных.

Да, my bad.

Это сложение вещественного и вещественного

Не гони!

int a = 2;
double b = 2.0;
double c = a + b;

Целое — частный случай вещественного

Опять гонишь! Сравни результат с сишечке 1/2 и 1.0/2.0. Если целое - частный случай вещественного, то результат должен быть один и тот же, а это не так.

Так что будет с твоим гениальным «сборщиком» когда кончится память?

тоже, что и с твоим.

Почему же? Может. Классы вычетов - вполне себе int.

не поле.

Если подумать, то можно и для флоатов найти модель. Хотя я уверен, что уже подумали, так что надо только погуглить

дык и погугли.

Таким образом, все твои отсылки к множествам чисел оставь при себе.

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

вообще-то тут про действия над double+int в языке C, неуч.

Какую структуру сохраняет описанная тобой

без ненормативной лексики ты не можешь? Ты пьян? Иди, проспись.

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

Наличие автоматических кастов типов целых чисел и автоматических кастов типов указателей — это черты слабой типизации.

и что?

36028801313931392 не представимо в IEEE754-double без потери точности.

я знаю.

Ах да, и вообще double — это вообще не вещественные числа.

угу. А int — это НЕ целые числа. Потому-что множество целых чисел бесконечно, а множество int — таки конечно.

Надеюсь, так тебе понятнее, что это сложение целого и вещественного. Здесь используется _неявное_ приведение типов.

это СЛОЖЕНИЕ double и double. Данный факт никак не противоречит тому, что ПЕРЕД этим происходит преобразование int --> double.

Джит никак не связан со сборщиком мусора.

Как это не связан, если карту корневых ссылок строит именно он?

Не будет.

Почему?

тут кричали, что у них GC — «только инкремент». Это довольно грустно, что в их коде — всё работает, а вот в моём — почему-то нет. Может ты мне объяснишь, как их сборщик умудряется выделять память «только инкрементом», причём она не кончается? И как он выделяет регистровую память?

А то мне — ещё грустнее, чем этому ослику...

это СЛОЖЕНИЕ double и double.

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

Но я человек, я вижу сложение целого и вещественного. Программа пишется для людей, ведь так?

так. Потому я и пишу:

double x;
int y;
double z = x + (double)y;

Как пишут разные быдлокодеры — меня не волнует.

С нормальным сборщиком мусора память от реконструкции дерева не закончится. А у тебя закончится.

не поле.

Не поле. И что дальше?

вообще-то тут про действия над double+int в языке C

еще раз, для особо одаренных - я отвечал на твой пост, где ты говорил про целые и вещественные числа. Об интах и флоатах не было никакого разговора.

Как это не связан, если карту корневых ссылок строит именно он?

А кто строит карту корневых ссылок в языке со сборкой, но без джита (интерпретируемых или компилируемых в машкод)?

Почему?

потому что не будет.

Может ты мне объяснишь, как их сборщик умудряется выделять память «только инкрементом», причём она не кончается?

Если будет кончаться - запустится сборка и память найдется..

А ты забываешь про jit, который сам по себе не бесплатен и оправдывает себя не всегда.

Какое отношение JIT имеет к GC? У всяких там какамлов с какашкелями JIT-ов нет, а GC есть.

И да, llvm, пара плагинчиков для clang'а и соответствующий рантайм и будет у тебя ЛЮБОЙ GC.

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

Вот только невостребован он в С и даже в С++, там немного другой подход к разработке

Там языки убогие настолько, что задача полного анализа pointer aliasing становится неразрешимой, и от GC будет мало пользы.

а затраты времени на перемещение в перемещающем GC ты конечно не считаешь, да? Он у тебя с помощью магии перемещает?

Выигрыш от компактификации многократно перевешивает накладные расходы на перемещение.

http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora086.html

нормального определения
канторовские сечения

Лол.

Да.

Нет.

И, еще раз, хватит говорить о том, в чем не разбираешься.

У меня для тебя плохие новости. То, что ты умеешь гуглить — не значит, что ты в чем-то разбираешься. Это значит лишь то, что ты умеешь гуглить.

С нормальным сборщиком мусора память от реконструкции дерева не закончится. А у тебя закончится.

тогда не говори, что «только инкремент». Пойми — либо крестик, либо трусы. Чудес не бывает в этом мире. Да, у меня рухнет этот код. У тебя — зависнет. Я такое наблюдал неоднократно. Бороться с нехваткой мозгов можно только покупкой новых мозгов. Повторяю — чудес не бывает. Кнут ещё в семидесятых это всё доказал, и у него есть пруфы, со строгим матаном. Ищи ошибку, если такой умный. Я верю Кнуту, а не тебе.

Не поле. И что дальше?

Всё. В не поле не определено умножение и деление. Оно не нужно на практике. В вычетах определено лишь сложение. (да и то со многими оговорками)

Доопределение например до поля Галуа приводит к чудовищному удорожанию операций, и тоже не нужно IRL (и только в некоторых особых приложений вроде связи с космическими аппаратами типа Вояджера применяется. Да и там решение берётся тупым перебором, ибо математики так ничего и не придумали лучше).

еще раз, для особо одаренных - я отвечал на твой пост, где ты говорил про целые и вещественные числа. Об интах и флоатах не было никакого разговора.

ОК. В таком случае, ты зря потратил своё время, доказывая мне очевидное. Меня не волнуют счётные множества ни целые, ни вещественные. Ибо в моей практике их нет. В последний раз они мне много лет назад были нужны, когда я учился. Я давно и успешно забыл эту ненужность.

В следующий раз помни, что _я_ пишу исключительно про множества, которые можно *посчитать*. А чего нет, того нельзя считать. Как этих твоих «целых чисел».

Может ты мне объяснишь, как их сборщик умудряется выделять память «только инкрементом», причём она не кончается?

Если будет кончаться - запустится сборка и память найдется..

за сигаретами сбегаешь? Пока твой GC всё повесил? Помни, что память *одна* в большинстве случаев, и ВСЁ ждёт, пока эта память занята. Например твоим GC. Намного лучше(дешевле!) повесить пару ядер на вычисление оптимального выделенного блока, чем вешать ВСЁ. Потому сишный malloc(3) предпочтителен в 95% случаев. А если ты не в состоянии сделать free(3) в нужный момент — вон из профессии. Никакая прокладка типа allways jit'а тебя не спасёт от течки. Смирись с этим.

Какое отношение JIT имеет к GC?

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

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

GC *всегда* непереносим. Ибо прибит гвоздями к машине(возможно — к виртуальной).

Там языки убогие настолько, что задача полного анализа pointer aliasing становится неразрешимой

это не баг, а фича. Не надо обсираться на каждом шагу, и всё будет хорошо. А если течка у тебя регулярная, то смирись, что ты — баба.

Выигрыш от компактификации многократно перевешивает накладные расходы на перемещение.

сиё есть бред и мечта. Доказательство опубликовано Кнутом более 30 лет назад.

http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora086.html

это я читал. Что дальше?

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

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

Там языки убогие настолько, что задача полного анализа pointer aliasing становится неразрешимой, и от GC будет мало пользы.

В проектах, использующих эти языки, скорее всего нет потребности в полном анализе. И от GC для указанных явно объектов толк быть вполне может.

Доказательство опубликовано Кнутом более 30 лет назад.

Я думаю, что тогда были совсем другие сборщики.

Я думаю, что тогда были совсем другие сборщики.

математика тогда тоже была совсем другой? Ну тогда извини...

Hint: матан «исправляется» только магией. А делить на ноль умеет только Б-г.

Алгоритмы сборки стали другими.

алгоритмы НЕ стали «другими». Они только развиваются и улучшаются. Причём почти всегда в сторону специализации. Т.е. старый алгоритм затачивают под новый случай. Но принципиально в них ничего не меняется.

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

а с wm тоже будет не переносим. Точнее, тебе придётся эту твою wm везде таскать для «переносимости». Т.е. это конечно ххорошо, если тебе её по любому надо таскать, как например в javascript, и мирится с её overhead'ом.

тогда не говори, что «только инкремент».

Хорошо, не только. Но этим «не только» можно полностью пренебречь. То есть 99.9% времени будет занимать именно инкремент.

Да, у меня рухнет этот код. У тебя — зависнет.

С чего же он зависнет? Ничего подобного.

Всё. В не поле не определено умножение и деление.

В кольце определено и сложение и умножение. Кольцо - не поле.

Оно не нужно на практике.

Конечно нужно. Вот твой int - как раз пример полезного кольца.

В вычетах определено лишь сложение. (да и то со многими оговорками)

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

Доопределение например до поля Галуа приводит к чудовищному удорожанию операций

А зачем?

и тоже не нужно IRL (и только в некоторых особых приложений вроде связи с космическими аппаратами типа Вояджера применяется. Да и там решение берётся тупым перебором, ибо математики так ничего и не придумали лучше).

На полях Галуа основан матаппарат самокорректирующихся кодов. Без них не будет работать цифровая связь и твои инторнеты.

ОК. В таком случае, ты зря потратил своё время, доказывая мне очевидное.

Чего же ты спорить начал, ебанашка?

Пока твой GC всё повесил?

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

Помни, что память *одна* в большинстве случаев, и ВСЁ ждёт, пока эта память занята.

Открой для себя конкурентные инкрементальные сборщики.

Потому сишный malloc(3) предпочтителен в 95% случаев. А если ты не в состоянии сделать free(3) в нужный момент — вон из профессии.

К сожалению, маллок/фри - это медленно, сильно медленно. Зачем делать программу, которая будет работать медленнее в тысячи или даже миллионы раз?

Только благодаря ей твой GC имеет нужную информацию о переменных в периметре GC.

Нет, не благодаря ей. Есть куча языков без джита, но с ГЦ.

сиё есть бред и мечта.

Только выигрыш в сотни тысяч раз перед дефолтными аллокаторами доказан практикой.

Доказательство опубликовано Кнутом более 30 лет назад.

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

Hint: матан «исправляется» только магией.

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

Причём почти всегда в сторону специализации.

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

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

Хорошо, не только. Но этим «не только» можно полностью пренебречь. То есть 99.9% времени будет занимать именно инкремент.

ага. В синтетических тестах, где для массива в 1000 эл-тов имеется 64Гб RAM. На боевом сервере это всё начинает тупить и тормозить, хотя там тоже 64Гб, но массивов там 100500, и размером они по 100500.

С чего же он зависнет? Ничего подобного.

так и будет, когда твой перемещающий GC начнёт _перемещать_. Включи голову и осознай, что для этого нужно ВСЁ останавливать.

ИЧСХ, если у тебя этот твой GC будет НЕ работать 99.9% времени, то когда он таки включится, работы накопится в тысячу раз БОЛЬШЕ, чем если-бы он работал на каждой аллокации. Но ты же 999 аллокаций делал только инкремент. А теперь — страдай и жди.

Повторяю: чудес не бывает, если ты отложил работу, то ты НЕ СДЕЛАЛ работу. Так вот, GC именно ОТКЛАДЫВАЕТ работу по наведению порядка.

Фигасе, сколько страниц срача из-за такого пустяка...

В кольце определено и сложение и умножение. Кольцо - не поле.

может ты самостоятельно освежишь свои знания?

Сложение определено безо всяких оговорок.

6часов + 6часов == сколько часов?

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

3часа*4часа == сколько часов? А сколько 6часов*6часов?

Доопределение например до поля Галуа приводит к чудовищному удорожанию операций

А зачем?

затем, что оно(умножение/деление) _неоднозначное_. Даже если делитель не равен нулю. Т.е. если в целых/вещественных «делить на ноль нельзя», то в вычетах делить ВООБЩЕ нельзя, кроме некоторых специальных случаев (например можно умножать и делить на 1).

Доопределение до поля Галуа снимает проблему неоднозначности, но возникает проблема дебиловрядовых программистов, которые стройными рядами уходят в лечебницы для психов. Ибо понять 2*2==1 они почему-то не могут.

На полях Галуа основан матаппарат самокорректирующихся кодов. Без них не будет работать цифровая связь и твои инторнеты.

я в курсе. А работать будет, просто медленнее.

В случае малого дерева сборка будет быстрее, чем вызов одного маллока.

докажи это странное заключение.

Открой для себя конкурентные инкрементальные сборщики.

они освобождают какую-то другую память?

К сожалению, маллок/фри - это медленно, сильно медленно.

это пока сборка не запустилась, а откладывается. Да, тогда malloc медленный. Вот только работа GC всё равно только ОТКЛАДЫВАЕТСЯ.

Нет, не благодаря ей. Есть куча языков без джита, но с ГЦ.

ага: bash, php...

может ты самостоятельно освежишь свои знания?

Ага, замечательно. Быстро мне определение кольца - только без подсказок из гугла!

6часов + 6часов == сколько часов?

Я не знаю, какая мат. структура у тебя на часах. может Z_12, может Z_24, может N, может что еще изощреннее. Я мысли читать не умею.

затем, что оно(умножение/деление) _неоднозначное_.

Ну ради бога. Все равно все пользуются интами и довольны. Умножение и деление кстати вполне однозначны, только деление не всюду определено (только если делитель с модулем взаимно просты).

то в вычетах делить ВООБЩЕ нельзя, кроме некоторых специальных случаев (например можно умножать и делить на 1).

Немного наоборот - делить можно всегда, кроме тех случае, когда делитель не взаимно прост с модулем.

я в курсе. А работать будет, просто медленнее.

Да нет, вообще не будет. Допустим, проконтролировать прохождение пакета ты еще как-то сможешь по заголовку (но медленно, да), а вот не сломалось ли что-то в области данных пакета - уже не проконтролируешь никак. Так что очень медленно пакеты доходить будут - но чуть менее чем все с порченными данными.

Только выигрыш в сотни тысяч раз перед дефолтными аллокаторами доказан практикой.

тут главное, что-бы сборка не включилась во время теста.

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

область применимости описана — когда памяти не хватает, и приходится запускать GC (или когда maloc(3) уже не справляется, и тратит слишком много времени на поиск)

А когда памяти как грязи — мой super_malloc работает ничуть не хуже, и не медленнее. Особенно в 64х битах и со свопом (куда и будет складываться автоматически ненужный мусор)