Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Prok186 © (2011-06-20 20:08:00)
Без дополнит. ухищрений под 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}

федор (2011-07-14 15:34:00) [1]
Не нравится. Иди дальше. Походи по рынку посмотри где дешевле и лучше.

KilkennyCat (2011-07-14 03:15:00) [2]

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

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

федор (2011-07-13 18:13:00) [3]
К стати на днях стала доступна бета х64 дельфи + компиляция под мак ос
http://www.sql.ru/forum/actualthread.aspx?tid=865483

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

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

Valentin (2011-07-08 06:22:00) [5]
Линковать win32-программы в штатном режиме могу, а с win64 - проблемы. Пробовал и так и эдак. Пока остановился на варианте с DLL-компоновкой, где в главной программе надо использовать LoadLibrary & GetProcAddress. Возможно, я пока чего-то не догоняю или это пока болезни роста при переходе из win32 в win64.

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

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

Valentin (2011-07-07 20:11:00) [7]
Здравствуйте. Это мой первый пост. Сначала по существу.

Задействовать 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 с явным указанием имен функций.

димка на (2011-07-02 05:23:00) [8]
а почему никто не предложил создать еще один пустой процесс и использовать- его- память? :)

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

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

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

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

han_malign (2011-06-23 17:45:00) [10]

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

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

Ega23 (2011-06-23 16:38:00) [11]
Удалено модератором
Примечание: И не цитируем

Prok186 (2011-06-23 16:26:00) [12]
Удалено модератором
Примечание: Выражения выбираем, не в пивной

Prok186 (2011-06-23 16:20:00) [13]

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

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

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

Ega23 (2011-06-23 11:19:00) [14]

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

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

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

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

Игорь Шевченко (2011-06-23 10:37:00) [15]

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

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

sniknik (2011-06-23 09:34:00) [16]
> Алгорим расчёта, многими здесь упоминаемый
ну, если что, на всякий случай, я упоминал не алгоритм расчета, а Алгоритм решения задачи/выбранный метод которым решили добиваться цели. т.е. более глобально. расчет тоже важен, но не настолько.
можно сколь угодно долго совершенствовать метод пузырьковой сортировки, менять его на быструю сортировку и совершенствовать его и т.д. до бесконечности, но это не даст такого выигрыша как Алгорим позволяющий исключить эту сортировку вообще. причем в частном случае алгоритм расчёта может и "пострадать" усложнится/стать более медленным если это выгодно для общего (ну там получать попутно значения нужные дальше и которые без этого пришлось бы рассчитывать дополнительно. т.е. "лучше день потерять, потом за пять минут долететь... " © мультфильм, если потом "летать" придется много и долго, то почему бы и нет? хотя в частном случае "расчета" "день+5 мин" хуже чем "час пешком".)

Anatoly Podgoretsky (2011-06-23 09:14:00) [17]
> Prok186 (23.06.2011 08:28:21) [21]

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

Prok186 (2011-06-23 08:28:00) [18]

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

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

Slym (2011-06-23 08:11:00) [19]
если доступ к массиву данных более менее линейный (не рандом),
почему бы не MMF с динамическим окном?

Германн (2011-06-23 03:14:00) [20]

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »