Отправлено: 30.04.10 10:34. Заголовок: Как сделать программу 64битной ?

Всем привет !
Только не пинайте сильно за вопрос... Пока только разбираюсь....

Как готовое приложение под хХарбором (терминалка) пересобрать на 64bit под новые системы Win 7 ?
Оно конечно и так там работает, но хотелось бы узнать что это даст ?

 Отправлено: 02.12.11 23:01. Заголовок: Пятничный оффтоп. Пр..

Пятничный оффтоп. Просто для того, чтобы сопоставить имеющиеся в наличии вычислительные мощности и решаемые ими задачи.
На запущенной на днях марсианской экспедиции 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.
Сопоставьте уровень решаемых задач с задачей по учету домофонов.

Дополнил оффтоп

 Отправлено: 03.12.11 15:53. Заголовок: Pasha, а файлы dbf, ..

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

 Отправлено: 03.12.11 16:00. Заголовок: PSP пишет: открытые..

PSP пишет:

цитата:

открытые в основной программе ведь недоступны в других потоках

Доступны

 Отправлено: 03.12.11 16:51. Заголовок: PSP пишет: Pasha, а..

PSP пишет:

цитата:

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

См. примеры в harbour\tests\mt

Андрей, так в чем узкое место расчета ? Если это выборка из БД, то распределение по потокам мало что даст.
Если расчет запустить локально, не по сети, то он работает быстрее ?
А если расчет запустить одновременно 2 или несколько раз на одном компьютере, то общее время будет какое ? Это будет некоторая эмуляция многопоточности.

 Отправлено: 04.12.11 10:30. Заголовок: Pasha пишет: См. пр..

Pasha пишет:

цитата:

См. примеры

Уже посмотрел. :)

 Отправлено: 04.12.11 20:07. Заголовок: Pasha пишет: Андрей..

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Гб. Средние машины...

Может нужно делать - отдельную программу на сервер (или службу/не знаю как пока), которая будет по "свистку" делать начисления ?

 Отправлено: 04.12.11 20:39. Заголовок: Andrey пишет: Счита..

Andrey пишет:

цитата:

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

Потоки по сути - это отдельные программы. Они все (сколько б их не было) будут работать с одним набором данных. Поэтому, тебе придется придумывать механизм разделения, который позволит на 100% быть уверенным, что не останется необработанных или обработанных больше одного раза записей.
А вот когда такой механизм будет, тогда и о потоках можно говорить.

 Отправлено: 04.12.11 20:56. Заголовок: PSP пишет: А вот ко..

PSP пишет:

цитата:

А вот когда такой механизм будет, тогда и о потоках можно говорить.

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

 Отправлено: 04.12.11 21:10. Заголовок: Andrey пишет: Pasha..

Andrey пишет:

цитата:

Pasha пишет: цитата: Если расчет запустить локально, не по сети, то он работает быстрее ? Конечно быстрее, в несколько раз...

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

 Отправлено: 04.12.11 21:19. Заголовок: Да, Андрей, хотелось..

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

 Отправлено: 04.12.11 21:27. Заголовок: Pasha пишет: Тогда ..

Pasha пишет:

цитата:

Тогда напрашивается вариант с letodb

На LetoDB пока не могу перейти:
1) LetoDB не поддерживает несколько индексных файлов для одной БД.
2) LetoDB не позволяет открывать сторонним программам уже открытые ей базы.
3) Переделка на LetoDB и перевод пользователей на нее пока проблематична из-за нехватки времени. В планах на 2012 год.

Ищу пока промежуточный вариант - запуск на сервере, отдельной программой:
1) вариант с hbmemio
2) вариант с потоками

Что будет быстрей работать ?

Pasha пишет:

цитата:

Ну и конечно, надо пересмотреть код на предмет оптимизации. Опыт подсказывает, что здесь всегда есть резервы.

Согласен. Но наверно для этого я пока отделю весь расчет в отдельный проект.
Соберу заодно и на Харборе. Посмотрю заодно кто быстрей считает...

 Отправлено: 04.12.11 21:53. Заголовок: 1. Я же это сделал у..

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

Что будет быстрее работать тебе никто не скажет, пока ты не покажешь свой расчет. Если ты считаешь, что узкое место - запись результата, то распределение по потокам не поможет. А для чего предполагается использовать hbmemio ? Вместо использования массива ? Так это называется менять шило на мыло. Хотя, конечно, и работу с массивами можно сделать так, что будет работать мееедленно. Я много неоптимального кода видел.

 Отправлено: 04.12.11 22:48. Заголовок: Pasha пишет: Я мног..

Pasha пишет:

цитата:

Я много неоптимального кода видел

+1

 Отправлено: 05.12.11 01:22. Заголовок: Pasha пишет: Под те..

Pasha пишет:

цитата:

Под термином "БД" ты имеешь в ввиду одну таблицу БД ? И одному абоненту в этой таблице соответствует одна запись ? И результат расчета записывается в эту строку (запись) ? И все это работает мееедленно ? Я правильно понимаю ?

Нет не одна таблица.
БД-Тарифов (даты и суммы начислений)
БД-Абонент (1 запись, в ней ID-абонента, его тариф).
По тарифу вытаскиваю из БД-Тарифа сумму начисления за месяц.
По ID-абонента, seek-ом иду на БД-оплаты-20хх года.
Далее считываю 30*12=360 значений БД в массив,
далее делаю начисления,
блокирую запись БД-оплаты-20хх и переписываю массив 30*12=360 значений в эту запись.
Далее блокирую запись БД-Абонента и записываю итог и дату расчета этого абонента.

Вот в кратце "алгоритм".

Я выводил счет времени по одному абоненту. Где то среднее 0.08 сек счета по одному абоненту.
Много помоему...

Может "зарубить" вывод на экран "бегунка" по каждому абоненту ?
Перерисовка экрана в GTWVT-терминалке времени тоже же "отнимает" порядочно !

 Отправлено: 05.12.11 10:13. Заголовок: Имхо, весь затык в п..

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

 Отправлено: 05.12.11 12:31. Заголовок: PSP пишет: Нет не о..

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
...

?

Что записывается в оплаты и как, каким методом ?
И зачем при расчете что-то заносить в оплаты ? Оплаты это оплаты, а расчет это расчет.

Все-таки, где узкое место ?
Если сделать отдельно расчет без записи, и запись чего-нибудь без расчета, то что медленнее ?

 Отправлено: 05.12.11 15:17. Заголовок: А что является резул..

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

 Отправлено: 05.12.11 19:46. Заголовок: Результативнее перес..

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

 Отправлено: 05.12.11 21:01. Заголовок: Vlad04 пишет: Назва..

Vlad04 пишет:

цитата:

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

 Отправлено: 05.12.11 21:12. Заголовок: У меня на 1с7(дбф) з..

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