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

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

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

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

Pasha: Пятничный оффтоп. Просто для того, чтобы сопоставить имеющиеся в наличии вычислительные мощности и решаемые ими задачи. На запущенной на днях марсианской экспедиции MSL стоимостью 2.5 млрд. долларов, это примерно 80 млрд. рублей в текущих ценах, что примерно в 10 раз превыщает стоимость флагманской миссии Роскосмоса Фобос-Грунт, к моему огромному сожалению неудачной, цена которой 8 млдр. рублей, установлен компьютер с такими характеристиками: Процессор 200MHz - 2 шт, 250 MB RAM, 2GB флэш-память. На запущенных в 2003-м году мамрсианских роверах стоит процессор 25 MHZ, 128 MB RAM, и флешка 256 MB. На меркурианском аппарате Messenger, запущенном в 2004-м - процессоры 25 и 10 MHZ и флешка 1 GB. Сопоставьте уровень решаемых задач с задачей по учету домофонов. Дополнил оффтоп

PSP: Pasha, а файлы dbf, открытые в основной программе ведь недоступны в других потоках и между потоками?

Dima: PSP пишет: открытые в основной программе ведь недоступны в других потоках Доступны


Pasha: PSP пишет: Pasha, а файлы dbf, открытые в основной программе ведь недоступны в других потоках и между потоками? См. примеры в harbour\tests\mt Андрей, так в чем узкое место расчета ? Если это выборка из БД, то распределение по потокам мало что даст. Если расчет запустить локально, не по сети, то он работает быстрее ? А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности.

PSP: Pasha пишет: См. примеры Уже посмотрел. :)

Andrey: Pasha пишет: Андрей, так в чем узкое место расчета ? Берется 1-я запись Абонента (из 30-65 тыс. записей) 1) Считываются данные по одному абоненту из основной БД в многомерный массив (структуру смотри выше), 2) делаются начисления в массиве (добавляются строки в массив и т.д.) 3) записываются значения из массива в основную БД (30 значений по столбцам: даты начислений, суммы начислений, ставок т/о и т.д. - итого 30*12=360 значениц в таблицу БД). - помоему самое узкое место.... 4) массив удаляется. Берется 2-я запись Абонента.... Pasha пишет: Если расчет запустить локально, не по сети, то он работает быстрее ? Конечно быстрее, в несколько раз... Но не всегда это можно, т.к. у некоторых моих пользователей БАЗЫ сидят на выделенном сервере - они считают через локальную сеть- это раза в 2-3 дольше. А некоторые запускают задачу счета на сервере- все равно считаются абоненты 1,5-2 часа. Pasha пишет: А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности. Программа на компе запускается только в одно окно (т.е. стоит запрет на запуск второй копии програииы). У меня стоит запрет на расчет несколькими рабочими станциями одновременно. Считает только ОДИН пользователь... Если допустить второго, то он тупо будет пересчитывать опять с 1-ой записи. Для того чтоб разрешить считать нескольким программам, тогда наверно нужно делать отдельную функцию (журнал расчета): какая станция расчитывает абонента с номером ID и смотреть чтоб абонент уже не был уже расчитан. Я просто хочу понять с вашей помощью, стоит ли тратить время на это или нужно по другому решать. Если абонентов мало, т.е. меньше 30 тысяц - расчет быстро идет. Просто у меня уже много контор где абонентов уже больше 50 тыс. - там медленно очень 1,5-2 часа. Сервера у них разные, ХР/2003, 2 МГц и выше, памяти 2Гб. Средние машины... Может нужно делать - отдельную программу на сервер (или службу/не знаю как пока), которая будет по "свистку" делать начисления ?

PSP: Andrey пишет: Считает только ОДИН пользователь... Если допустить второго, то он тупо будет пересчитывать опять с 1-ой записи. Для того чтоб разрешить считать нескольким программам, тогда наверно нужно делать отдельную функцию (журнал расчета): какая станция расчитывает абонента с номером ID и смотреть чтоб абонент уже не был уже расчитан. Потоки по сути - это отдельные программы. Они все (сколько б их не было) будут работать с одним набором данных. Поэтому, тебе придется придумывать механизм разделения, который позволит на 100% быть уверенным, что не останется необработанных или обработанных больше одного раза записей. А вот когда такой механизм будет, тогда и о потоках можно говорить.

Andrey: PSP пишет: А вот когда такой механизм будет, тогда и о потоках можно говорить. Да механизм придумать несложно, главное чтобы быстрее считало ! Вот я и пытаюсь понять, что быстрей будет: 1) вариант с hbmemio 2) вариант с потоками

Pasha: Andrey пишет: Pasha пишет: цитата: Если расчет запустить локально, не по сети, то он работает быстрее ? Конечно быстрее, в несколько раз... Тогда напрашивается вариант с letodb. Функция расчета компилируется на сервере в файл hrb, и запускается на выполнение с клиента. При этом расчет будет выполнять сервер, без всякой передачи данных по сети. Да еще БД при этом открывается сервером монопольно, так шта.. это будет еще быстрее. Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы.

Pasha: Да, Андрей, хотелось бы уточнить терминологию. Под термином "БД" ты имеешь в ввиду одну таблицу БД ? И одному абоненту в этой таблице соответствует одна запись ? И результат расчета записывается в эту строку (запись) ? И все это работает мееедленно ? Я правильно понимаю ? Структура простейшая, без всяких связей, подчиненных таблиц, и прочего ? Тогда мне не очень понятно, что там может быть медленно ? Если ты думаешь, что это запись результата, то это всего лишь операция dbCommit. Или все-таки неоптимальный алгоритм расчета ?

Andrey: Pasha пишет: Тогда напрашивается вариант с letodb На LetoDB пока не могу перейти: 1) LetoDB не поддерживает несколько индексных файлов для одной БД. 2) LetoDB не позволяет открывать сторонним программам уже открытые ей базы. 3) Переделка на LetoDB и перевод пользователей на нее пока проблематична из-за нехватки времени. В планах на 2012 год. Ищу пока промежуточный вариант - запуск на сервере, отдельной программой: 1) вариант с hbmemio 2) вариант с потоками Что будет быстрей работать ? Pasha пишет: Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы. Согласен. Но наверно для этого я пока отделю весь расчет в отдельный проект. Соберу заодно и на Харборе. Посмотрю заодно кто быстрей считает...

Pasha: 1. Я же это сделал уже почти месяц как. 2. Это не так, позволяет. Хотя при этом теряются преимущества монопольного доступа. Если сторонние программы твои, то лучше их тоже переделать c letodb 3. Ну тут тебе никто не поможет. Что будет быстрее работать тебе никто не скажет, пока ты не покажешь свой расчет. Если ты считаешь, что узкое место - запись результата, то распределение по потокам не поможет. А для чего предполагается использовать hbmemio ? Вместо использования массива ? Так это называется менять шило на мыло. Хотя, конечно, и работу с массивами можно сделать так, что будет работать мееедленно. Я много неоптимального кода видел.

Dima: Pasha пишет: Я много неоптимального кода видел +1

Andrey: Pasha пишет: Под термином "БД" ты имеешь в ввиду одну таблицу БД ? И одному абоненту в этой таблице соответствует одна запись ? И результат расчета записывается в эту строку (запись) ? И все это работает мееедленно ? Я правильно понимаю ? Нет не одна таблица. БД-Тарифов (даты и суммы начислений) БД-Абонент (1 запись, в ней ID-абонента, его тариф). По тарифу вытаскиваю из БД-Тарифа сумму начисления за месяц. По ID-абонента, seek-ом иду на БД-оплаты-20хх года. Далее считываю 30*12=360 значений БД в массив, далее делаю начисления, блокирую запись БД-оплаты-20хх и переписываю массив 30*12=360 значений в эту запись. Далее блокирую запись БД-Абонента и записываю итог и дату расчета этого абонента. Вот в кратце "алгоритм". Я выводил счет времени по одному абоненту. Где то среднее 0.08 сек счета по одному абоненту. Много помоему... Может "зарубить" вывод на экран "бегунка" по каждому абоненту ? Перерисовка экрана в GTWVT-терминалке времени тоже же "отнимает" порядочно !

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

Pasha: PSP пишет: Нет не одна таблица. БД-Тарифов (даты и суммы начислений) БД-Абонент (1 запись, в ней ID-абонента, его тариф). По тарифу вытаскиваю из БД-Тарифа сумму начисления за месяц. По ID-абонента, seek-ом иду на БД-оплаты-20хх года. Далее считываю 30*12=360 значений БД в массив, далее делаю начисления, блокирую запись БД-оплаты-20хх и переписываю массив 30*12=360 значений в эту запись. Далее блокирую запись БД-Абонента и записываю итог и дату расчета этого абонента. Вот в кратце "алгоритм". Я выводил счет времени по одному абоненту. Где то среднее 0.08 сек счета по одному абоненту. Много помоему... 0.08 это много. 0.08*65000 = 5200 сек Каким методом выбираются оплаты ? Быстрым индексно-последовательным, т.е. seek while ! eof() .and. ... skip enddo или более медленным индексным, т.е. seek seek ... ? Что записывается в оплаты и как, каким методом ? И зачем при расчете что-то заносить в оплаты ? Оплаты это оплаты, а расчет это расчет. Все-таки, где узкое место ? Если сделать отдельно расчет без записи, и запись чего-нибудь без расчета, то что медленнее ?

S-A-N: А что является результатом расчета? Сумма к оплате? Если да, то чем вызвана необходимость перезаписи всего массива из 360 эл-тов?

Vlad04: Результативнее пересмотреть алгоритм расчета , по аналогии с 1с. Результат m1+m2+m3+m4 =S1_4 можно заменить на S1_3 +m4 =S1_4 где S1_3 =m1+m2+m3. Т.е вводятся промежуточные итоги. Общий итог равен ближайший промежуточный + данные за текущий период. Название 1с означает - ПОЛУЧИТЬ РЕЗУЛЬТАТ ЗА 1 секунду.

AlexMyr: Vlad04 пишет: Название 1с означает - ПОЛУЧИТЬ РЕЗУЛЬТАТ ЗА 1 секунду.

AlexMyr: У меня на 1с7(дбф) зарплата на 40 чел рассчитывается около минуты, а на clipper5.3 для 260 чел приблизительно 20 сек., так что 1с в аналогии брать не нужно.



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