Форум » [x]Harbour » Как сделать программу 64битной ? » Ответить

Как сделать программу 64битной ?

Andrey: Всем привет ! Только не пинайте сильно за вопрос... Пока только разбираюсь.... Как готовое приложение под хХарбором (терминалка) пересобрать на 64bit под новые системы Win 7 ? Оно конечно и так там работает, но хотелось бы узнать что это даст ?

Ответов - 57, стр: 1 2 3 All

Pasha: Надо собрать харбор каким-нибудь 64-битным С-компилятором: msvc64, Intel, Pelles C, mingw64 А что это даст - операции с типом данных longlong (64-битные целые) будут выполняться быстрее. Но такие значения используются редко, это целые числа со значением больше 2 млрд

Andrey: А самые медленные операции, чтение-запись в базы будут быстрей происходить на 64bit приложениях ? Т.е. расчет который проходит за 1.5 часа на 32bit приложении, будет быстрей производиться ?

Dima: Andrey пишет: Т.е. расчет который проходит за 1.5 часа на 32bit приложении Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?!


Andrey: Dima пишет: Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?! Да я уже писал про это... Все никак не дойдут руки до оптимизации... База примерно 65 500 записей, объём 231 Мб, кол-во полей 374. Без МЕМО поля. База содержит 30 полей: 1) даты прихода денег, 2) суммы прихода денег, 3) даты начисления, 4) суммы начисления, .... короче лучше смотреть скриншот....

Dima: Andrey пишет: Все никак не дойдут руки до оптимизации... Помочь ? Одна голова хорошо а две лучше ;) PS С тебя пиво.

Pasha: Andrey пишет: А самые медленные операции, чтение-запись в базы будут быстрей происходить на 64bit приложениях ? На эти операции разрядность ОС не влияет

Andrey: Dima пишет: Каков размер базы (кол-во записей и полей которые участвуют в расчете ) , что так долго считается ?! Да я уже писал про это... Все никак не дойдут руки до оптимизации... База примерно 65 500 записей, объём 231 Мб, кол-во полей 374. Без МЕМО поля. База содержит 30 полей: 1) даты прихода денег, 2) суммы прихода денег, 3) даты начисления, 4) суммы начисления, .... короче лучше смотреть скриншот.... Т.е. на ВСЕ начисления и приход денег абонента имею ВСЕГО ОДНУ запись в БД. Это позволило еще в 1999году на Клипере 5.3 под Виндой95/98 просматривать "мгновенно" начисления абонента. Правда считалось (раз в месяц) ну очень долго, часов 15-16.... Расчет происходил так: 1) создавалась временная база одного абонента, 2) туда копировались данные по одному абоненту из основной БД, 3) делалось начисления (добавлялись записи в временную БД), 4) считывались записи из временной БД в постоянную, 5) временная база закрывалась. Сейчас делается немного по другому: 1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется. Сейчас на хХарборе считается быстрей конечно, но от времени записи из массива в БД - никуда не денешься. А это 30 полей "Даты прихода денег", 30 полей Суммы прихода денег", 30 полей "Даты начислений", 30 полей "Суммы начислений" и т.д. Вот такой ПИРОГ получается ....

Andrey: Dima пишет: С тебя пиво. Без вопросов... Куда доставить... Адрес давай....

Петр: Andrey пишет: 1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется. 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай.

Dima: Andrey Алгоритм я так понял не изменился , за исключением того что ранее инфа по абоненту считывалась во временную базу а сегодня в маcсив. Andrey пишет: Считываются данные по одному абоненту из основной БД в многомерный массив Andrey пишет: Т.е. на ВСЕ начисления и приход денег абонента имею ВСЕГО ОДНУ запись в БД То есть фактически считываются 374 поля из одной единственной записи ? И если я верно понял то длина массива не более 374 элементов !? Полтора часа не понятно что там можно считать....... Andrey пишет: кол-во полей 374 Дни года что ли в полях хранишь ?

Pasha: У нас же была тема про массивы. Операции с массивами тоже можно резко оптимизировать, но нужно видеть предмет для разговора т.е. алгоритм. Т.е., имеем простой цикл по таблице абонентов, и расчет по каждому абоненту выполняется за 1.5 часа/65000 абонентов, т.е грубо за 0.08 сек Прежде всего надо выяснить узкое место. Это выборка данных из БД или сам расчет ?

LYSK: По-моему - "узкое" место - это "широкая таблица" БД. Кажется, уже тут об этом писали.

Andrey: Dima пишет: То есть фактически считываются 374 поля из одной единственной записи ? И если я верно понял то длина массива не более 374 элементов !? Длина массива 15 элементов (как на скриншоте выше): 1) Тариф 2) Дата тарифа 3) Приход 4) Дата прихода 5) Вид оплаты 6) Начислено 7) Простили 8) Дата начисления 9) Задолжность 10) Номер документа оплаты 11) Номер пачки 12) Примечание 13) Id абонента 14) Id операции 15) Id резерв Dima пишет: Дни года что ли в полях хранишь ? Нет в одной записи храню по 30 значений: Тариф, дата тарифа, сумма начисления, дата начисления, ... и т.д. до 13 позиции списка выше ! Плюс суда к этому 10-15 доп.полей, Id абонента, Дата последней корректировки, Признак закрытия начислений .. и т.д. Pasha пишет: Прежде всего надо выяснить узкое место. Это выборка данных из БД или сам расчет ? Расчет быстрый ! Узкое место запись (чтение не рассматриваю, т.к. эта операция быстрей) из массива в БД ! Т.е. надо из массива записать в поля записи по 30 значений: Тарифа, даты тарифа, .... (см.выше) У меня если юзер пересчитывает абонентскую плату ОДНОГО абонента, это мгновенно, да и запись одного абонента, тоже юзера НЕ НАПРЯГАЕТ, быстро происходит... Почему сделано по 30 значений, отвечу. В принципе АБОНЕНТ за год оплачивает коммуналку 1 раз в месяц... Раньше база была меньше, хранил по 15 значений... Но жизнь показа (тут и ЕИРЦ и СБанк), что мало. Пришлось до 30 довести. Сейчас вообще прикол с этим ЕИРЦ в Москве - коммунальные услуги оплачивает каждый собственник квартиры. Семья - допустим из 4 человек платит каждый месяц по 4 платежа, итого 4*12=42 платежа .... Тут и 30 моих ячеек не хватает...

Andrey: LYSK пишет: По-моему - "узкое" место - это "широкая таблица" БД. Кажется, уже тут об этом писали. Согласен с этим высказыванием. Но другого пути в свое время (см.выше) я не увидел. Что будет быстрей считаться я не знаю. Но в моей базе можно считать и больше 1 миллиона абонентов. А в обычной базе сколько можно будет считать ? И сколько записей будет в этой БД ? Допустим имеем 100 000 абонентов (я считал и 150тыс.абонентов). За год абонент платит 15 раз (см. выше, у меня чаще). Плюс к этому еще и начисления, т.е. 15*2 Итого имеем 100000 * 15 * 2 = 3 000 000 записей. Интересно сколько времени будет начисляться по такому кол-ву записей ?

Andrey: Петр пишет: 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай. А есть смысл переделать под эту штуку ? И навскидку - какое будет ускорение ?

Dima: Andrey пишет: И навскидку - какое будет ускорение ? Просто попробуй и сравни сам по скорости с массивом. Потом нам раскажешь ;)

Петр: Andrey пишет: А есть смысл переделать под эту штуку ? ? Если вы ее освоите и будете использовать, то почему и нет. И навскидку - какое будет ускорение ? Автор hbmemio Mindaugas Kavaliauskas в принципе для таких целей и написал эту библиотеку. По его словам, время построения отчетов его программой уменьшилось ощутимо, в разы, но порядок цифр точно не помню, потому и приводить не буду.

Петр: Со своей стороны хочу добавить, что с в некоторых программах с той же целью я использую SQLITE in memory database (аналог hbmemio) - у пользователей создается ощущение, что все выполняется на 1-2

XVar: Андрей есть подозрение, что в Вашем случае переход на 64 бита ничего не даст. Подобные скорости наблюдал при чтении из файлов построчно (да здравствует XML - технология 21 века), с последующей обработкой. Причем при модернизации железа положение улучшилось в разы. Апгрейдить пришлость все : процессор, 4 Г памяти , SCSI RAID5 (HW). Для интереса посмотрите статистики. Возможно проблема на виду . Например процессор загружен на 100 %, или кол. обрашений к диску великовато. Про грабли :) (Офф топ) Почитайте здесь : http://clipper.borda.ru/?1-1-0-00000155-000-0-0-1225096542 За вопрос "как поменять компилятор?" могут и заклевать :). Кстати Вы там интересовались насчет WinCe, устыдившись после всего высказанного, купил FWPPC (FiveWin Pocket PC edition). Имеются проблемы (кодировка , недоработки), но в целом рулит.

Andrey: Петр пишет: Andrey пишет: цитата: 1) Считываются данные по одному абоненту из основной БД в многомерный массив, 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД. 4) массив удаляется. 100% просится вариант с hbmemio. Но хорошо б если машина имела 1 Гб и больше памяти, так на всякий случай. Поднимаю еще раз этот вопрос. Так как собрался с силами (время на праздниках будет) делать оптимизацию по своим начислениям. Буду пробовать вариант с hbmemio. Придется наверно делать отдельную программу на Харборе. Но хотелось бы уточнить, а через многопотоковость нельзя ли организовать расчет ? 1) Сделать отдельную функцию расчета 2) запустит 10 потоков расчета/записи ОДНОЙ записи в БД и пускай они считают сразу 10 записей..... Т.е. программа будет считать последовательно не 1-ну запись в БД, а сразу 10 !!! Ну ускорения в 10 раз конечно же не ожидаю, но быстрей же БАЗА должна считаться в целом ?



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