Прошу прощения за некропост. Решил немного погрузиться в ностальгию и программирование под DOS, и дошел до разборок с моделями памяти. В принципе все оказалось элементарно, кроме разницы между Large и Huge.
В справке BC++3.1, которым я пользуюсь, рассказано про это минимально. Уже измучил и поисковики, и нейросети (GhatGPT, DeepSeek, Qwen) своими попытками выудить что-то конкретное. Перепробовал десятки разных примеров в обоих режимах.
Как и в этой статье, многократно утверждалось, что Huge "допускает создание массивов и структур, занимающих в памяти по 64 КБ и более". В действительности, в BC++3.1 ни в одной из моделей, даже в Huge, нельзя создать глобальный или статический массив размером больше 64K без использования слова huge. Но со словом huge, такие массивы можно создать в любой модели кроме tiny.
Также, как и в этой статье, утверждалось про отличия в работе указателей. Но что я только не делал с массивами и указателями (обычными, near, far, huge), одинаковый код скомпилированный в моделях Huge и Large всегда давал строго одинаковый результат. Нейросети с десяти попыток каждая не осилили придумать пример, который дал бы разный результат при переключении модели с Large на Huge. Встроенная справка говорит, что при Huge "All function and data pointers assumed to be far.", почти то же, что и про Large: "All function and data pointers are far by default".
Единственное реальное отличие, которое я вычитал в справке Turbo C 2.0 состоит в том, что в Large можно выделить 64Kb глобальных и статических данных на всю программу, а в Huge по 64Kb на единицу трансляции ("source module" в оригинале). И действительно, в BC++3.1 код двумя исходниками по 40Kb в каждом компилируется только в Huge, а в Large дает ошибку.
В остальном Large и Huge практически идентичны, не считая мелочи что в Huge можно при одном файле на совсем крохи больше выделить, не вызывая "DGROOP exceeds 64K", при этом добавление еще щепотки приводит к "Too much global data defined in file".
Собственно, вопрос. Я пришел к верному выводу, или у меня лыжи как-то не так едут?
На этом скриншоте все прекрасно. Утечка это вообще отдельный разговор, но тут почти каждая программа может потреблять в 10 раз меньше памяти без потери функционала, и для этого даже не нужно быть Джоном Кармаком.
Проблема может и нишевая, но знания по ней широкие. Прямо сейчас расспросил и перепроверил, знают подробно и про regulatory domain, и про конкретные ограничения по странам, и как менять, и какие потенциальные проблемы, и т.д. и т.п.
не ясно почему до сих пор сброс навыков или вообще недоступен или сопряжён с какими-то проблемами
Тут на самом деле все просто. Жадный издатель хочет, чтобы игрок проходил игру заново и набивал часы в метриках каждый раз, когда хочет попробовать другой билд.
Список на половину состоит из вкусовщины помноженной на непонимание геймплейного замысла элементов.
Та же подсветка противников нужна, чтобы игрок играл в тактическую головоломку и контроль хаоса, а не симулятор тысячи ползков/тыков, который ввиду энергозатратности может вырождаться в попытку прохождения в стиле рембо. У разработчиков есть свое видение геймплея, и эта механика ему содействует.
Подсветка лута это вообще мастхев во многих играх. Хорошо там, где она есть, и очень плохо, где ее не хватает. Когда гамма разнообразная с множеством мелких деталей на сцене, как в том же новом Wolfenstein, глаза вытекут высматривать предметы без помощи.
Каким бы медленным не казался RDR2 в начале, к концу прохождения понимаешь, что именно так в нем все и должно быть. А поднимать в прыжке левитирующие в воздухе патроны можно например в думе. Это не вопрос "лучше или хуже", это вопрос соответствия.
Скорость света никто не ограничивает, просто это вообще единственная существующая скорость. Только движение происходит не просто в пространстве, а в пространстве-времени. Когда направление движения смотрит строго вдоль оси времени, как у неподвижного объекта, получаем нулевые компоненты скорости в пространстве, и скорость света в компоненте времени. Когда направление строго ортогонально оси времени, как у фотонов, получаем скорость света в компонентах пространства, и нулевую скорость в компоненте времени.
То, что мы субъективно воспринимаем как изменение скорости на самом деле является изменением направления движения в ПВК.
Не знаю что имелось в виду под "импульс в объеме квадратной скорости света", но если бы у тела была скорость света, у него уже была бы бесконечная энергия. На массу тогда можно уже и не умножать, да и квадрат не нужен.
Все еще хитрее. Энергия передается не движущимися электронами в проводнике, а электромагнитными полями внутри и рядом с проводником. А квантом электромагнитного поля является фотон.
Ага-ага, с планетой Земля в качестве своего ядра, как в геоцентризме. Даже если гипотеза о вселенной внутри ЧД верна, ее границы не будут иметь ничего общего с границами нашей наблюдаемой вселенной, потому что наблюдаемая вселенная у каждой позиции в пространстве своя собственная.
Было бы замечательно иметь production ready синтезатор голоса для диалогов с заданной тегами интонацией и произношением. Чтобы актеры озвучки обеспечивали сколько-то там часов семплов, а дальше можно было бы пилить тексты без ограничений по количеству или даже создавать на ходу, при этом без раздувания объема игры на диске.
Заголовок и подача: хороним растеризацию и рейтрейсинг. Содержимое: тормозный косячный прибитый гвоздями к полу способ отрендерить статическую сцену 3D-хелловорлда 20-летней давности.
Нейросети хорошо применимы там, где алгоритм сложно или невозможно формализовать. Например, в задаче находить на картинке котов. Существующие реализации растеризации и рейтрейсинга это уже лучшая, дико оптимизированная на всех уровнях, от архитектуры приложения и распараллеливания и до байтоложества и особенностей аппаратной архитектуры версия того, что когда-либо способно сложиться под капотом в весах нейросети. Которые при этом еще и детерминированно выдают результат, не теряя ни единого пикселя даже при анимации.
Ценность в этом пока видится разве что исследовательская.
Мне всегда звонили прямо на телефон с российских номеров. А что касается СКАМа, как якобы безопасной альтернативе телеграма, то мошенники могут с него уже прямо сегодня звонить и сообщения слать, на сервисах смс-активации он уже доступен, причем номера стоят дешевле чем для телеграма.
Учтите контекст, я тут не утверждал что бинарный поиск по массиву в миллион элементов медленней. Я утверждал, что в большинстве языков где в стандартной библиотеке используется сортировка вставками (а это в QuickSort), используется линейный поиск, потому что его замена на бинарный делает хуже, даже на сортируемом массиве в миллионы элементов. А это именно то, что вы и просили - конкретный пример, где бинарный поиск показывает себя хуже.
Я же дал ссылку на его доклад, даже с таймстампом, там бинарному поиску посвящено минут пять максимум. Оптимальным получилось отказаться от бинарного поиска, которого в изначальной реализации тоже не было, потому что он замедляет QuickSort на 13%. Он даже пробовал разные его вариации, включая branchless. Конкретно в этом случае порог был 32, но он сказал, что пробовал и другие, в том числе больше, и становилось только хуже.
Неужто и правда миллион элементов вставками сортируется?
Еще раз. Сортировка вставками используется под капотом QuickSort. Само собой в стандартной библиотеке ни одного из языков не используется голая сортировка вставками как реализация sort.
Если они продаются, значит кто-то их покупает, и куда-то ставит.
Прошу прощения за некропост. Решил немного погрузиться в ностальгию и программирование под DOS, и дошел до разборок с моделями памяти. В принципе все оказалось элементарно, кроме разницы между Large и Huge.
В справке BC++3.1, которым я пользуюсь, рассказано про это минимально. Уже измучил и поисковики, и нейросети (GhatGPT, DeepSeek, Qwen) своими попытками выудить что-то конкретное. Перепробовал десятки разных примеров в обоих режимах.
Как и в этой статье, многократно утверждалось, что Huge "допускает создание массивов и структур, занимающих в памяти по 64 КБ и более". В действительности, в BC++3.1 ни в одной из моделей, даже в Huge, нельзя создать глобальный или статический массив размером больше 64K без использования слова huge. Но со словом huge, такие массивы можно создать в любой модели кроме tiny.
Также, как и в этой статье, утверждалось про отличия в работе указателей. Но что я только не делал с массивами и указателями (обычными, near, far, huge), одинаковый код скомпилированный в моделях Huge и Large всегда давал строго одинаковый результат. Нейросети с десяти попыток каждая не осилили придумать пример, который дал бы разный результат при переключении модели с Large на Huge. Встроенная справка говорит, что при Huge "All function and data pointers assumed to be far.", почти то же, что и про Large: "All function and data pointers are far by default".
Единственное реальное отличие, которое я вычитал в справке Turbo C 2.0 состоит в том, что в Large можно выделить 64Kb глобальных и статических данных на всю программу, а в Huge по 64Kb на единицу трансляции ("source module" в оригинале). И действительно, в BC++3.1 код двумя исходниками по 40Kb в каждом компилируется только в Huge, а в Large дает ошибку.
В остальном Large и Huge практически идентичны, не считая мелочи что в Huge можно при одном файле на совсем крохи больше выделить, не вызывая "DGROOP exceeds 64K", при этом добавление еще щепотки приводит к "Too much global data defined in file".
Собственно, вопрос. Я пришел к верному выводу, или у меня лыжи как-то не так едут?
На этом скриншоте все прекрасно. Утечка это вообще отдельный разговор, но тут почти каждая программа может потреблять в 10 раз меньше памяти без потери функционала, и для этого даже не нужно быть Джоном Кармаком.
ChatGPT, DeepSeek, и Qwen. Просто они не могут увязать описанные симптомы с корнем проблемы.
Он ведь только для 802.11b с его 11 Мбит/с, разве нет?
Проблема может и нишевая, но знания по ней широкие. Прямо сейчас расспросил и перепроверил, знают подробно и про regulatory domain, и про конкретные ограничения по странам, и как менять, и какие потенциальные проблемы, и т.д. и т.п.
Есть. В ЕС вроде 12 и 13 каналы разрешены только на ограниченной мощности передатчика.
Тут на самом деле все просто. Жадный издатель хочет, чтобы игрок проходил игру заново и набивал часы в метриках каждый раз, когда хочет попробовать другой билд.
Список на половину состоит из вкусовщины помноженной на непонимание геймплейного замысла элементов.
Та же подсветка противников нужна, чтобы игрок играл в тактическую головоломку и контроль хаоса, а не симулятор тысячи ползков/тыков, который ввиду энергозатратности может вырождаться в попытку прохождения в стиле рембо. У разработчиков есть свое видение геймплея, и эта механика ему содействует.
Подсветка лута это вообще мастхев во многих играх. Хорошо там, где она есть, и очень плохо, где ее не хватает. Когда гамма разнообразная с множеством мелких деталей на сцене, как в том же новом Wolfenstein, глаза вытекут высматривать предметы без помощи.
Каким бы медленным не казался RDR2 в начале, к концу прохождения понимаешь, что именно так в нем все и должно быть. А поднимать в прыжке левитирующие в воздухе патроны можно например в думе. Это не вопрос "лучше или хуже", это вопрос соответствия.
Скорость света никто не ограничивает, просто это вообще единственная существующая скорость. Только движение происходит не просто в пространстве, а в пространстве-времени. Когда направление движения смотрит строго вдоль оси времени, как у неподвижного объекта, получаем нулевые компоненты скорости в пространстве, и скорость света в компоненте времени. Когда направление строго ортогонально оси времени, как у фотонов, получаем скорость света в компонентах пространства, и нулевую скорость в компоненте времени.
То, что мы субъективно воспринимаем как изменение скорости на самом деле является изменением направления движения в ПВК.
Не знаю что имелось в виду под "импульс в объеме квадратной скорости света", но если бы у тела была скорость света, у него уже была бы бесконечная энергия. На массу тогда можно уже и не умножать, да и квадрат не нужен.
Все еще хитрее. Энергия передается не движущимися электронами в проводнике, а электромагнитными полями внутри и рядом с проводником. А квантом электромагнитного поля является фотон.
Ага-ага, с планетой Земля в качестве своего ядра, как в геоцентризме. Даже если гипотеза о вселенной внутри ЧД верна, ее границы не будут иметь ничего общего с границами нашей наблюдаемой вселенной, потому что наблюдаемая вселенная у каждой позиции в пространстве своя собственная.
Даже не так. "Если дать ресурсов в тысячу раз больше, то результат станет чуть лучше".
Если честно, то визуально похоже на груди.
Было бы замечательно иметь production ready синтезатор голоса для диалогов с заданной тегами интонацией и произношением. Чтобы актеры озвучки обеспечивали сколько-то там часов семплов, а дальше можно было бы пилить тексты без ограничений по количеству или даже создавать на ходу, при этом без раздувания объема игры на диске.
Заголовок и подача: хороним растеризацию и рейтрейсинг.
Содержимое: тормозный косячный прибитый гвоздями к полу способ отрендерить статическую сцену 3D-хелловорлда 20-летней давности.
Нейросети хорошо применимы там, где алгоритм сложно или невозможно формализовать. Например, в задаче находить на картинке котов. Существующие реализации растеризации и рейтрейсинга это уже лучшая, дико оптимизированная на всех уровнях, от архитектуры приложения и распараллеливания и до байтоложества и особенностей аппаратной архитектуры версия того, что когда-либо способно сложиться под капотом в весах нейросети. Которые при этом еще и детерминированно выдают результат, не теряя ни единого пикселя даже при анимации.
Ценность в этом пока видится разве что исследовательская.
Мне всегда звонили прямо на телефон с российских номеров. А что касается СКАМа, как якобы безопасной альтернативе телеграма, то мошенники могут с него уже прямо сегодня звонить и сообщения слать, на сервисах смс-активации он уже доступен, причем номера стоят дешевле чем для телеграма.
Учтите контекст, я тут не утверждал что бинарный поиск по массиву в миллион элементов медленней. Я утверждал, что в большинстве языков где в стандартной библиотеке используется сортировка вставками (а это в QuickSort), используется линейный поиск, потому что его замена на бинарный делает хуже, даже на сортируемом массиве в миллионы элементов. А это именно то, что вы и просили - конкретный пример, где бинарный поиск показывает себя хуже.
На всякий случай ссылка на доклад на рутубе.
Я же дал ссылку на его доклад, даже с таймстампом, там бинарному поиску посвящено минут пять максимум. Оптимальным получилось отказаться от бинарного поиска, которого в изначальной реализации тоже не было, потому что он замедляет QuickSort на 13%. Он даже пробовал разные его вариации, включая branchless. Конкретно в этом случае порог был 32, но он сказал, что пробовал и другие, в том числе больше, и становилось только хуже.
Еще раз. Сортировка вставками используется под капотом QuickSort. Само собой в стандартной библиотеке ни одного из языков не используется голая сортировка вставками как реализация sort.