Как аддрессовать не 2Gb, а 4Gb памяти?

← →
Prok186 © (2011-06-20 20:08) [0]

Без дополнит. ухищрений под Win7 64bit удаётся писать на Delphi XE приложения, использующие до 2Gb оперативной памяти. Судя по мануалу, можно расширить диапазон до 4Gb : http://docwiki.embarcadero.com/RADStudio/XE/en/Increasing_the_Memory_Address_Space
Однако ж, указанный флаг установить в *.dpr файл проекта мне не удаётся: компилятор пишет, что такого не знает. Что делать?
Вот этот флаг:
{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

← →
Eraser © (2011-06-20 20:13) [1]

> [0] Prok186 © (20.06.11 20:08)

не мучайся, подожди 64 битный компилятор или устнови бету.

← →
KilkennyCat © (2011-06-21 00:37) [2]

http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html#p2

← →
MBo © (2011-06-21 05:41) [3]

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

← →
Prok186 © (2011-06-21 20:53) [4]

С флагом разобрался сам: его константа описана в Windows.pas, так что Windows надо перед установкой флага прописать в Uses.
А где можно скачать пробную Delphi 64-bit? Она ведь уже вышла.

← →
Германн © (2011-06-22 02:05) [5]

> Prok186 © (21.06.11 20:53) [4]

А ответить на вопрос
> MBo © (21.06.11 05:41) [3]
>
> А есть ли смысл?

что мешает?

← →
Prok186 © (2011-06-22 04:41) [6]

Смысл 2Гб --> 4Гб? Конечно есть. Мы на работе используем Delphi для создания приложений расчётной гидродинамики: там есть и базы данных, и графика OpenGL для 3D визуализаций, и обычная, и создание анимаций (AVI-Server тоже написано на Delphi). Приложения - многопоточные (расчётов много), причём очень критичные к объёму памяти. Удвоение доступной памяти - весьма заметно: память, есс-нно, выделяется динамически: вдовое больший её объём означает возможность применения вдвое более подробной (по одной координате) расчётной сетки... К сожалению, многие участники форума не понимают, что Delphi - не только для написания красивой обёртки для БД. По быстродействию (расчётные методы) код на Delphi лишь немного уступает Visual C++, и опережает примерно в 1.5раза Builder. Критичные к времени куски кода написаны у нас на Visual Studio C++ в виде DLL.

← →
MBo © (2011-06-22 05:35) [7]

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

← →
Ega23 © (2011-06-22 08:10) [8]

> К сожалению, многие участники форума не понимают, что Delphi
> - не только для написания красивой обёртки для БД.

Спасибо, поржал. Заряд хорошего настроения с утра - отличный подарок на ДР! :)))

← →
KilkennyCat © (2011-06-22 08:20) [9]

книжку что ли написать... "Нетрадиционные методы. Использование Делфи без БДЕ и не для БД"

← →
Prok186 © (2011-06-22 08:39) [10]

Прежде чем книжку писать, надо научиться читать: выше сказано, что приложения ВКЛЮЧАЮТ в себя базы данных. В серьёзных научных приложениях они тоже нужны: для хранения исходных данных в виде связанных таблиц для различных вариантов задачи, и для хранения результатов расчётов (и ссылок).

← →
sniknik © (2011-06-22 10:17) [11]

> код на Delphi лишь немного уступает Visual C++
ноги, крылья... хвост! вот что главное. © известный мультфильм.

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

> Критичные к времени куски кода написаны у нас на Visual Studio C++ в виде DLL.
да, да знаю такой подход... одно время меня к нему тоже "склоняли", была задача где клиент сказал "главное скорость!", ну а раз скорость то - "давай вставки, пиши на С", и т.д. (слова С-шника), только там была еще важна скорость разработки, а С я не очень... ну могу конечно, но не то (дольше будет. + кроме этой были задачи, связанные), поэтому ему сказали "а напиши ка ты это сам"... ну он и написал, обработка 5 часов, очень быстрыми методами, с сортировками/поиском по самым быстрым хешам, и т.д. (нафига? если поиск используется максимум пару раз (в лучшем случае вообще ни разу), зачем хеш на все данные? ну и т.д.). ну он убрал, оптимизировал - 3,5 часа... сказал "все. лучше нельзя, данных все таки много"... ага, особенно если по ним вместо нужного делать кучу быстрого...
в итоге закончил свое, и вместо "вставки" написал по своему, на "чистом" дельфи, с другим алгоритмом (а разница? если в итоге тоже самое)... получилось где-то 11-30 сек... это было даже не смешно.
но положительные моменты от этого были, хотя бы в том, что ламер/апологет С перестал его превозносить, и "опускать" дельфи на каждом углу. при мне по крайней мере. но не убедился - "не, а если бы я сделал также, только на С" (кто мешал? ты же делал задачу, а не перевод) "было бы быстрее" (давай проверим? бери мой код переводи в С и посмотрим) "не, ну тут вот этого нет, и вот такого нет, не получится прямо вот как" (ну еще бы, а самописные им аналоги почему то медленнее. ну не верю что он не пробовал, просто не получилось иначе все бы об этом знали) "и вообще работать нужно, а не фигней маяться. С все равно самый быстрый" (а смысл в его быстроте, если он из-за этого такой сложный что конкретно ты с ним не справляешься?)

← →
Ega23 © (2011-06-22 10:44) [12]

> По быстродействию (расчётные методы) код на Delphi лишь
> немного уступает Visual C++, и опережает примерно в 1.5раза
> Builder.

Сомневаюсь. Если с умом к делу подходить, то скорость примерно одинаковой должна быть.
Ну а если совсем супер-пупер оптимизация и скорость расчётов нужна, то выбор Windows в качестве ОС надо бы сменить.

← →
Игорь Шевченко © (2011-06-22 12:04) [13]

> опять имхо, т.к. сталкиваюсь только с таким)

ты какую часть слона нащупал ? ;)

← →
Inovet © (2011-06-22 13:08) [14]

> [11] sniknik © (22.06.11 10:17)
> если он из-за этого такой сложный что конкретно ты с ним не справляешься?

Так это проблемы конкретно у него.

← →
sniknik © (2011-06-22 14:02) [15]

> ты какую часть слона нащупал ? ;)
заднюю похоже...

> Так это проблемы конкретно у него.
спасибо Кэп! как бы я это без тебя понял... очевидно же, пусть пишу это прямым текстом, но понимания факта "ни в зуб ногой".

← →
Loginov Dmitry © (2011-06-22 22:19) [16]

> К сожалению, многие участники форума не понимают, что Delphi
> - не только для написания красивой обёртки для БД.

На основании чего сделан столь категоричный вывод о многих участниках форума? Не исключаю, что есть и такие. Любят задавать вопросы в конференции "начинающие", но в обсуждениях, как правило, не участвуют.
Те кто, принимают участие в обсуждениях, оказывают реальную помощь своими советами, прекрасно все понимают.

> По быстродействию (расчётные методы) код на Delphi лишь
> немного уступает Visual C++, и опережает примерно в 1.5раза
> Builder.

Плюс/минус полтора раза - это ерунда (как правило). Купив более мощное железо, можно обеспечить еще большее ускорение.
Гораздо большее восхищение (по крайней мере у меня) вызывает оптимизация библиотек BLAS и Lapack, используемых как основа почти любого современного математического пакета (Matlab, Mathcad, Scilab и др.).
Например, скорость работы стандартного алгоритма матричного умножения, реализованного в библиотеке BLAS (обычно это Atlas.dll) может запросто оказаться в 100 раз выше, чем у стандартного алгоритма матричного умножения, реализованного на языках программирования Delphi / C++, а тем более .NET.

← →
Prok186 © (2011-06-22 22:35) [17]

> Ну а если совсем супер-пупер оптимизация и скорость расчётов
> нужна, то выбор Windows в качестве ОС надо бы сменить

Пробовали переходить на Linux (какой именно - не помню): быстродействие абсолютно не меняется. Специально написали тестовые программки на C++ для Линукса и Винды (обработка больших массивов - заполнение арифметикой или функциями). Так что кроме гимора от линуха в расчётных приложениях толку ноль.

← →
KilkennyCat © (2011-06-23 01:25) [18]

> Так что кроме гимора от линуха в расчётных приложениях толку
> ноль.

смелое заявление.
но глуполамерное.

← →
Германн © (2011-06-23 03:14) [19]

> Смысл 2Гб --> 4Гб? Конечно есть. Мы на работе используем
> Delphi для создания приложений расчётной гидродинамики

Ну и?
Вы же работаете в той же ОС как и все многие. В ОС Windows. А она и только она распоряжается памятью. А как она ею распоряжается вам, имхо, пока не известно.
Вы пробовали и Линукс. Вот только как пробовали вы не знаете.
Ну и о чём тут говорить?
При "расчётной ..." первое дело обратить внимание на алгоритм расчёта. А уж потом на свойства системы.

← →
Slym © (2011-06-23 08:11) [20]

если доступ к массиву данных более менее линейный (не рандом),
почему бы не MMF с динамическим окном?

← →
Prok186 © (2011-06-23 08:28) [21]

> смелое заявление.
> но глуполамерное.

Можете подтвердить примером расчётной программки (именно расчётной - с большим количеством вычислений), которая под Линухом хотя бы на 10% быстрее будет работать, чем её аналог под Винду? Если нет - это пустая болтовня с важным раздуванием щёк про "преимущества линуха".
------------
Алгорим расчёта, многими здесь упоминаемый, оптимизирован и так уже до предела. Наш программный код для одной и той же задачи минимум вдвое быстрее и в 5 раз экономичней по памяти, чем известный америкосовый продукт Flow-3D от фирмы Flow Scince. Но как всегда, хочется большего... (тема начиналась вопросом про расширение адресации памяти: Flow-3D как раз 64-битная, а вот 64-битная Delphi всё ещё на подходе). Кстати, наша фирма (РусГИДРО) имеет единственную по Северо-Западу офиц. коммерческую (не учебную!) лицензию этого Flow-3D и под Линух, и под Винду. Линухом пользуемся редко: повторюсь, кроме лишней головной боли он (как показал двухлетний сравнительный оптыт) НИЧЕГО не дал.
------------
В расчётных методах помимо распараллеливания на потоки (а в Delphi оно сделано очень удобно и эффективно), сейчас интересное направление - использование библиотек OpenCL (не путать с OpenGL) и (абревиатуру могу путать) CUDA. Т.е., когда основная арифметика переносится на процессоры графических карт.

← →
Anatoly Podgoretsky © (2011-06-23 09:14) [22]

> Prok186 (23.06.2011 08:28:21) [21]

А ваша фирма к Саяно Шушенской ГЭС никакого отношения не имеет?

← →
sniknik © (2011-06-23 09:34) [23]

> Алгорим расчёта, многими здесь упоминаемый
ну, если что, на всякий случай, я упоминал не алгоритм расчета, а Алгоритм решения задачи/выбранный метод которым решили добиваться цели. т.е. более глобально. расчет тоже важен, но не настолько.
можно сколь угодно долго совершенствовать метод пузырьковой сортировки, менять его на быструю сортировку и совершенствовать его и т.д. до бесконечности, но это не даст такого выигрыша как Алгорим позволяющий исключить эту сортировку вообще. причем в частном случае алгоритм расчёта может и "пострадать" усложнится/стать более медленным если это выгодно для общего (ну там получать попутно значения нужные дальше и которые без этого пришлось бы рассчитывать дополнительно. т.е. "лучше день потерять, потом за пять минут долететь... " © мультфильм, если потом "летать" придется много и долго, то почему бы и нет? хотя в частном случае "расчета" "день+5 мин" хуже чем "час пешком".)

← →
Игорь Шевченко © (2011-06-23 10:37) [24]

> Линухом пользуемся редко: повторюсь, кроме лишней головной
> боли он (как показал двухлетний сравнительный оптыт) НИЧЕГО
> не дал.

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

← →
Ega23 © (2011-06-23 11:19) [25]

> Можете подтвердить примером расчётной программки (именно
> расчётной - с большим количеством вычислений), которая под
> Линухом хотя бы на 10% быстрее будет работать, чем её аналог
> под Винду? Если нет - это пустая болтовня с важным раздуванием
> щёк про "преимущества линуха".

Вообще-то распределённые вычисления - это целая прикладная область. И 10 средненьких дешёвых компов, объеденных в ферму, могут выдать производительность в несколько раз выше, чем супер-пупер дорогой сервер. Т.к. процессоров тупо больше.
Это дело можно и под Виндой реализовать. Просто под *никсами, ЕМНИП, таких "готовых" решений - вагон и маленькая тележка.
Если есть желание - могу у ребят в ОИЯИ уточнить, они этим делом уже второй (если не третий) десяток лет занимаются.

> В расчётных методах помимо распараллеливания на потоки

Фигли толку большие вычисления на разные потоки параллелить, если процессор один? Это имеет смысл, когда идёт большое вычисление, а ты в это время пасьянс раскладываешь или порно-рассказы читаешь.

← →
Prok186 © (2011-06-23 16:20) [26]

> Фигли толку большие вычисления на разные потоки параллелить,
> если процессор один?

Почему один? У меня даже на рабочей станции их 12х2 = 24
> А ваша фирма к Саяно Шушенской ГЭС никакого отношения не
> имеет?

Наш больной. Сейчас выздоравливает.

Удалено модератором
Примечание: Выражения выбираем, не в пивной

Удалено модератором
Примечание: И не цитируем

← →
han_malign (2011-06-23 17:45) [29]

> почему бы не MMF с динамическим окном?

- если распараллеливание непрерывными блоками, то - MMF и старый добрый fork через CreateProcess() ...

← →
Дмитрий Белькевич (2011-06-26 11:52) [30]

> Почему один? У меня даже на рабочей станции их 12х2 = 24

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

Распараллеливать шину к памяти нужно.

← →
димка на (2011-07-02 05:23) [31]

а почему никто не предложил создать еще один пустой процесс и использовать- его- память? :)

Здравствуйте. Это мой первый пост. Сначала по существу.

Задействовать 4 Гб под 64-битным Windows (начиная от XP) РЕАЛЬНО. Имею собственный опыт. В Delphi компилируешь как обычную программу, отключив проверку на выход допустимых значений ($R-). Затем с помощью утилиты editbin.exe из Visual C++ нужно внести в полученную exe-программу коррективы:

editbin.exe /LARGEADDRESSAWARE <program.exe>

Ключ LARGEADDRESSAWARE позволяет задействовать в Win32 до 3 Гб в ОС, запущенной с ключом /3GB, а приложениям Win32 в Win64 - до 4 Гб. Правда, не сплошной кусок в 4 Гб, а 2 куска по почти 2 Гб - один до границы до 2Гб-64Кб, а другой от границы в 2 Гб.

Кстати, в Visual C при компиляции 64-битных программ этот ключ по умолчанию отключен и программа может адресовать лишь до 2 Гб - в целях совместимости при переходе из Win32 в Win64 старого программного обеспечения. Даже если этот ключ явно указан, в программе для массивов есть ограничение - они могут иметь в совокупности память лишь до 2 Гб. Большие массивы можно создавать лишь динамически - через VirtualAlloc и ей подобные функции.

P.S. Боже мой, только сегодня узнал о проекте KOL и был потрясен. А я-то обходился Win32 API. Но вот теперь у меня вопрос - как насчет миграции на 64-битную платформу? Я опробовал различные компиляторы и могу сказать что наименее ошибочные - это ассемблеры (GoAsm, fasm, masm64 and etc). Из не ассемблеров - только Visual C. Пробовал Free Pascal - не доведено до ума. Когда начал разбираться в глюках на ассемблерном уровне - увидел, что при передаче 64-битных параметров в функции Win64 они обрезаются до 32-битных значенй - похоже, это издержки при миграции с Win32 на Win64.
И еще, помимо того что для Win64 Visual C не позволяет делать ассемблерные вставки, так еще предельно затрудняет компиляцию выделенных в ассемблерный файл функций - приходится использовать внешний компилятор в командной строке. Даже полученный результат в виде DLL невозможно задействовать классическим способом - только через LoadLibrary с явным указанием имен функций.

> [32] Valentin © (07.07.11 20:11)
> компиляцию выделенных в ассемблерный файл функций - приходится
> использовать внешний компилятор в командной строке. Даже
> полученный результат в виде DLL невозможно задействовать
> классическим способом - только через LoadLibrary с явным
> указанием имен функций.

А прилинковать нельзя что ли?

Линковать win32-программы в штатном режиме могу, а с win64 - проблемы. Пробовал и так и эдак. Пока остановился на варианте с DLL-компоновкой, где в главной программе надо использовать LoadLibrary & GetProcAddress. Возможно, я пока чего-то не догоняю или это пока болезни роста при переходе из win32 в win64.

> [34] Valentin © (08.07.11 06:22)
> Линковать win32-программы в штатном режиме могу, а с win64 - проблемы.

Как же они работают без линковки?

← →
федор (2011-07-13 18:13) [36]

К стати на днях стала доступна бета х64 дельфи + компиляция под мак ос
http://www.sql.ru/forum/actualthread.aspx?tid=865483

> компиляция под мак ос

опоздали. под мак мне софт лет десять назад заказывали.

← →
федор (2011-07-14 15:34) [38]

Не нравится. Иди дальше. Походи по рынку посмотри где дешевле и лучше.

Как аддрессовать не 2Gb, а 4Gb памяти? Найти похожие ветки