Вопрос по приорететам и компилятору.

← →
AndreyS (2002-03-14 15:34) [0]

Я уже задавал вопрос по потокам. Спасибо за помощь тем кто ответил. Но задача сложнее
и для того, чтобы не писать много раз наверное лучше сразу описать задачу, чтобы отсеить
лишние варианты. Требуется программа которая будет обрабатывать сверхогромный массив
(более 150 мегабайт занимет он и сотоит из миллионов элементов). Нужна максимальная
скорость (тоесть весь в оперативку). Каждое обновление любого элемента массива зависит от
всех элементов предыдущего шага (в общем некая интерференция). Прога планируется
работать одна - специально комп для этого выделяется в течении месяцев. Нужно иметь восможность
приостанавливать процесс и просматривать промежуточные варианты. Итак вопросы всвязи с этим.
1) Какой компилятор создаст более быструю прогу (при прочих равных, ну конечно если
есть допвозможности, то с учетом их применения) DELPHI, Borland Bilder или С++.
Повторяю, что при прочих равных (ясно, что на Асме быстрее будет, только прверять и отлаживать
помрешь) 2) Нужно приостанавливать работу проги кнопкой на форме(другой отработчик получается).
Вариант с выделением потока для второй кнопки сомнителен Есть минимальный квант проверки
активности другого потока, а из-за всего лишь кнопки на останов это может вылится в неделю
увеличения времени расчета (не самый лучший вариант). Нужет финт без создания лишнего потока,
но так чтобы прога могла начать работать с прерванного момента без глюков и потери данных.
4) ДО скольки элементов массива понимает DElPHI (тип longint или INT64 поймет?)Ссылки
тоже не шибко решение. Ибо закон сохранения информативной вариантности никто не отменял.
И что нужно делать чтобы понял, ели нужны специальные директивы 3) Как указать системе, что
прога будет иметь высших или высокий приоретет в течении огромного времени и чтобы система успокоилась
(типа других задач нет и проверять нечего). Иначе будет сбой. И
вообще не быстрее будет в досе (хоть и 16 разрядная) в Борланд паскале. Зато никакой
ругани, тормозов и глюков из-за приоретета реального времени.
Спасибо за внимание.

← →
Alx2 (2002-03-14 16:27) [1]

>не быстрее будет в досе (хоть и 16 разрядная)
>в Борланд паскале. Зато никакой ругани, тормозов и глюков
>из-за приоретета реального времени.

В DOS быстрее считает. Но потоки реализовывть.... :).
И не BP. Лучше 32-х разрядные GNU C, Watcom C++, Zortech C etc

В 16 разрядной 150 мегов не засунешь. Хотя можно, используя DPMI, но тогда массив придется дробить по сегментам, что не очень удобно, да и тормозов накинет.

PS
Остальные вопросы более или менее подробно уже обсуждались в форумах.

← →
Виктор Щербаков (2002-03-14 16:39) [2]

Если операции с плавающей точкой, то Intel C++ стоит попробовать. Есть большая вероятность, что он всех сделает.

Почему не хочешь использовать отдельный поток? Не понятно!

Если поставить программе RealTime-приоритет, то большого выигрыша не получишь, но поьлзовательский интерфейс перестанет реагировать на пользователя. Ведь бОльшую часть времени потоки ждут пользовательского вода или других обытий/сообщений/объектов ядра, по этому не отнимают время процессора.

← →
Виктор Щербаков (2002-03-14 16:44) [3]

> Нужно иметь восможность
> приостанавливать процесс и просматривать промежуточные варианты.

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

← →
MAxiMum (2002-03-14 16:54) [4]

Не знаю, что лучше, но зачем же использовать массивы. Есть специально для этого потоки TStream, коллекции и прочее. Зачем поток для отдельной кнопки. Можно в цикле обработки массива поставить Application.ProccessMessage, которая и будет проверять нажатие кнопки и другий событий проги. Приоритет на процесс и на задачу поставь побольше.
Лучше, конечно, голый WinApi. Компилятор (Delphi, C) - в приципе без разницы - они показывают одинаковые возможности.
Говорят, C - проф. язык, но компилятор Delphi делает то, что делают ручками в C, а ведь, при этом не все же такие спецы.

← →
Fellomena (2002-03-14 17:19) [5]

2 AndreyS:
Хех... товарищь, у меня приблизительно похожая задача сейчас возникла - работа с огромными массивами данных. При этом надо, при накоплении 30 Mb, скидывать их на диск, что бы память не забивалась и не было paging-а, тормозящего работу.
После долгих тестов - выбрала VisualFortran 6.1.0
Прога работает в консоле - жрёт меньше всего ресурсов.
Многопоточность реализуется - но никаких компонент и библиотек огромных.
Настройки компилятора очень гибкие по отношению работы с массивами, с плавающей точкой, развёртка циклов хорошая, есть возможность настраиваться на определённую архитектуру компа.
Уровней оптимизации - огромное множество.
На громозких расчётах выигрышь в 2-3(!!!) раза перед Delphi, чуть меньше VC++

Очень рекомендую.
Сейчас вот начинаю разбираться с многопоточностью в VF 8)
Вливайся 8)

← →
Anatoly Podgoretsky (2002-03-14 22:16) [6]

AndreyS © (14.03.02 15:34)
4) До Integer, но тебя это не должно воновать, так как несколько миллионов значительно меньгу 2 миллиардов.

3) в 16 разрадной не будет быстрее, лимит 1 мегабайт на все и сегментная организация по 63 кб
Приоритет можешь не повышать если крутится только твоя задача, практически все время будет твое, на всякий случай убери все ненужные процессы и сеть. Памяти как я понимаю на машине будет по крайней мере 512 мб, потому что 256 может не хватить, хотя может и хватит.

← →
Alx2 (2002-03-15 10:09) [7]

>Anatoly Podgoretsky © (14.03.02 22:16)
>и сегментная организация по 63 кб
Пустяк, но червь сомнения залез :)
2^16=2^10*2^6=1k*64=64k или я что-то упустил?

← →
Виктор Щербаков (2002-03-15 10:12) [8]

Alx2 © (15.03.02 10:09)
Он наверно с нуля считает :)
Т.е. нулевой килобайт, первый килобайт, второй килобайт и т.д.

← →
Anatoly Podgoretsky (2002-03-15 21:53) [9]

Нет один про запас оставил :-)

← →
drpass (2002-03-15 22:57) [10]

>AndreyS
Нужно учитывать еще и свои возможности, как программиста. И под Delphi, и под Visual С++ программу нужно подгонять изначально. Например, в ресурсоемких программах на С++ нельзя использовать цикл for() - он реализован очень неэффективно, в то время как на Паскале он вкладывается в три ассемблерные инструкции.
Компилятор Delphi по возможности старается переменные делать регистровыми, в то время как С++ требует явного указания.
Вызов процедур по модели register в Delphi выполняется быстрее, чем fastcall в С++, в то время как stdcall - медленнее, и если прога интенсивно использует фукнции WINAPI, то лучше взять С++
И т.д. - нюансов множество, и на них нужно ориентироваться при написании программы.
Да, и не забудь сохраняться - если твой комп глюкнет за два дня до окончания расчета, будет очень обидно ;)

← →
Anatoly Podgoretsky (2002-03-16 10:10) [11]

Не вижу причин почему stdcall - медленнее, это взятие адреса и помещение его на стек, то есть или помещение его регистр, затем push или сразу напрямую PUSH

← →
evgeg (2002-03-16 10:19) [12]

Советую повнимательнее посмотреть на задачу. Может быть вовсе и не надо держать все пред. результаты в памяти?

Вопрос по приорететам и компилятору. Найти похожие ветки