Есть ли смысл переходить на 64бит в прогах на МиниГуи ?

Форум » Для флейма » Есть ли смысл переходить на 64бит в прогах на МиниГуи ? » Ответить

Есть ли смысл переходить на 64бит в прогах на МиниГуи ?

Andrey: Всем привет. Возвращаюсь опять к вопросу перехода с 32bit на 64bit. Сейчас использую МиниГуи на Borland 5.5.1 32bit. Ряд заказчиков давно используют 64bit Windows 2008 Server и Win10. Есть ли смысл пере собирать свою прогу на 64bit ? Что даст переход - ускорение выполнения программы, более высокую стабильность выполнения или ещё что то ? Можно ли собрать 64bit для Борланда ?

Ответов - 19

gfilatov2002: Andrey пишет: Что даст переход То, что для 64-битной оси это будет нативное 64-битное приложение. Ускорение выполнения программы составит не более 3-5%, что не существенно, так как не превышает погрешности измерения. Andrey пишет: Можно ли собрать 64bit для Борланда ? Да, если использовать лицензионный BCC 7.30 64-bit от Embarcadero Technologies

Sergy: Так понимаю, переход на 64 бита нужен, если требуется активная работа программы с памятью выше 2..3 Gb. Всё остальное, в тч "нативность" и ускорение на 3..5% - чистая блажь.

PSP: x64 позволяет очень сильно увеличить максимальное кол-во записей, а также максимальный размер базы и индекса.

Andrey: PSP пишет: x64 позволяет очень сильно увеличить максимальное кол-во записей, а также максимальный размер базы и индекса. Прога быстрей будет работать или нет ?

PSP: Andrey пишет: Прога быстрей будет работать или нет ? Запуск 32-битных программ на 64-битной системе осуществляется с помощью "прослойки" WoW64 (Windows-on-Windows 64-bit). Это вносит некоторую задержку при запуске. 64-битные программы запускаются сразу ОС. Т.е., будет заметно, что прога быстрее запускается. Работать быстрее она вряд ли будет. Минус 64-битной проги - ее нельзя запустить на 32-битной системе.

Dima: PSP пишет: x64 позволяет очень сильно увеличить максимальное кол-во записей, а также максимальный размер базы и индекса. Это ты про DBF ?

PSP: Да (что-то уже сомневаюсь)))

Sergy: PSP пишет: Да (что-то уже сомневаюсь))) И правильно делаешь. Структура DBF и NTX/CDX не зависит от разрядности приложения: 2014-10-17 14:55 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) * include/hbrddcdx.h * src/rdd/dbfcdx/dbfcdx1.c + added support for large index files over 4GB length. These are slightly modified CDX indexes which stores index page numbers instead of index page offsets inside index file. This trick increase maximum index files size from 2^32 (4GB) to 2^41 (2TB). This index format is enabled automatically when DB_DBFLOCK_HB64 is used. This is the same behavior as in DBFNTX and DBFNSX for which I added support for large indexes (up to 4TB) few years ago. Warning: new CDX indexes are not backward compatible and cannot be read by other systems or older [x]Harbour versions. If you try to open new indexes using older [x]Harbour RDDs then RTE "DBFCDX/1012 Corruption detected" is generated. When current Harbour *DBFCDX/SIXCDX RDD open index file then it automatically recognize type of index file so it will work correctly with both versions without any problem. In short words: People using DB_DBFLOCK_HB64 should remember that after reindexing with new Harbour applications old ones cannot read new CDX indexes. ; In next step I plan to add support for user defined page size in CDX index files.

PSP: Это я всё читал. Мне непонятно, будет ли работать схема DB_DBFLOCK_HB64 в 32-разрядном приложении.

PSP: С индексами понятно) А что насчет самих dbf, их размера и кол-ва записей? А?))

Dima: PSP пишет: А что насчет самих dbf, их размера и кол-ва записей? Если есть возможность , затести. Я бы так и сделал.

PSP: Ну, если никто не знает, то при случае затестю)

Dima: PSP я под ADS затестил при AdsLocking( .F. ) , четко держит базу в 4 гига , апосля четко падает )) ЗЫ 32 бита тестил

Pasha: PSP пишет: А что насчет самих dbf, их размера и кол-ва записей? А?)) Для 32-битных программ размер dbf-файла больше 4Г будет поддерживаться, если конечно позволит файловая система. А количество записей более 4 млрд (4294967295) - нет, так как и в заголовке dbf для количества записей выделено 4 байта, и во внутренних структурах тип данных для ulRecCount, ulRecNo - 32-битный HB_ULONG 64-битность тут не спасет, это ограничение самого формата.

PSP: Вот теперь всё понятно) Да, получается смысл в 64-битном приложении только в возможности использовании больших объемов памяти.

Andrey: PSP пишет: Да, получается смысл в 64-битном приложении только в возможности использовании больших объемов памяти. Получается, что для Харбора этого и не нужно ! DBF - 64бит не поддерживает. Единственное исключение наверное (если я не прав то поправьте меня) строковые переменные смогут быть больше ? Т.е. если файл закачать в строковую переменную для 32бит будет один предел, для 64бит будет больше.

Pasha: Различий конечно больше. Это скажем целочисленная арифметика. Для 32-х бит большие числа будут преобразованы в double с потерей разрядности. Для 64-х бит этого не будет. dbf - да, формат не поддерживает более 4 млрд.записей. Но на размер файла такого ограничения нет, кстати, что для 32, что для 64-разрядных приложений. Сама ОС конечно должна быть 64-битной, но сейчас думаю 32-битные ОС стоят только на старых компьютерах.

Sergy: Да, получается смысл в 64-битном приложении только в возможности использовании больших объемов памяти. Получается, что для Харбора этого и не нужно ! DBF - 64бит не поддерживает. Единственное исключение наверное (если я не прав то поправьте меня) строковые переменные смогут быть больше ? Т.е. если файл закачать в строковую переменную для 32бит будет один предел, для 64бит будет больше. Максимальный размер строковой переменной (как и массива) в Harbour лимитирован общим объемом памяти, который может быть выделен операционной системой одному процессу. Разумеется, что в x64 этот лимит выше, чем в x86 (32-bit) . Это как раз и есть то самое "использование бОльших объемов памяти".

Sergy: Скомпилировал простейшую программу под 64 бит:[pre2] FUNC Main() ? MEMORY(0), MEMORY(0)/1024/1024, "Gb" ? MEMORY(1), MEMORY(1)/1024/1024, "Gb" ? MEMORY(2), MEMORY(2)/1024/1024, "Gb" INKEY(0) RETURN[/pre2] Дает такие результаты: [pre2] 13498968 12.87 Gb 4194303 4.00 Gb 13498972 12.87 Gb[/pre2] Не знаю, с чем это связано, но даже под х64 одна строка не может быть больше 4 гигов.

полная версия страницы