of63
Лулгу, ты много проверочных штучек написал?. ну зачем, кто их будет запускать и проверять. Много текста, Лулгу. Краткий анонс эксперимента не сделал... это я еще по пьяни тебе ответил, а так и не ответят(им). Даже он монстров проверок, _vit, leonid, spinz - ну что ты выразишь вкрадце, чтобы хоть кто-то посмотрел на твои труды. Я без прикола, просто. посмотри на свои результаты экспериментов, и их предвесники, здраво. Эти ребято тоже не безгрешны, но они "гуру", и чтобы с ними соревноваться, нужно точно быть уверенным, и знать их возможные вопросы, вот так )

С чего вы решили (да и не вы одни, тролликов хватает), что меня так волнует это п...мерянье, да еще и вдобавок мнение каких-то "монстров".
Кому нужно, может тому и пригодится.

Ну, так мне показалось, что я как-то поясню отрицаловку по отношению к тебе... Хотя тут сложнее, отрицалова на этом форуме нет, все прощают друг другу, довольно быстро )

П..мерянье зачем может пригодиться? Бабам например, мужикам... они вроде не заморачиваются сильно размером...?



Исправлено 1 раз(а). Последнее : of63, 24.01.18 00:49

Причем здесь бабы, мужики - п...меряньем пацаны сидя на заборе занимаются.

ЗЫ. Опять вы берега начали путать, пока.

на заборе остро, и занозисто )

Simple777
Я пробовал запускать эту функцию из командного окна FPD. Сообщение об ошибке появлялось при первом же вызове.

Было несколько сборок. Какая-то выдавала такое сообщение только при повторных вызовах.

Igor Korolyov
Собственно вот сама fll и тестирующая программа.
Собирал я её в Microsoft Visual C++ 2008 Express, посему там ссылки на сишный рантайм msvcr90.dll, кому надо, думаю, без проблем найдут установщик соответствующего рантайма
Исходник fll, конечно, прилагается.
Там я добавил второй вариант - штатный "возврат значения", т.к. один чёрт от лишних копирований строки не избавиться - скорость работу 2 вариантов совпадает (до точности сравнения. HPET я использовать не стал, и так всё видно).
Ну и на всякий случай скриншот с результатами:
[attachment 28858 reduce_test.png]

Архив с исходниками:
[attachment 28859 reduce_fll_test.zip]

Что-то не понял за счет чего выигрыш. Твой сишный код в принципе не может быть быстрей

За счёт исключения ненужных фоксовых операций над строками. Такой код в любом случае потребует LEFT(), плюс лишнее создание ещё одной строки (буфера) и передачу её в машкод. Мне просто лень было влазить в этот машкод, чтобы заменить работу с 2-мя блоками памяти на работу с одним - тем самым убрав из точки вызова бессмысленный memmove на размер этой же строки. Ну и как бонус, получив возможность работать с чуть большими строками (у меня до 400Мб получалось обработать - в "чистом/свежезапущенном" IDE фокса).
То что сгенерённый студией машкод для собственно реализации алгоритма неоптимален - я даже и не собираюсь спорить Вся соль как раз в том что твоя борьба "за такты" в реализации самого схлопывания замечательно съедается ненужными копированиями гигантских строк-блоков в точке вызова и в фоксовой части кода.
Я полагал что фокс вообще даст "прямой" доступ - тогда бы скорость была ещё выше - т.к. не происходило бы вообще копирований мега-строки с места на место, только "усечение" по результату и всё. Но FoxAPI это, увы, не позволяет - таки присутствуют как минимум два memmove (ну и соответственно alloc-и под них).

Igor Korolyov
То что сгенерённый студией машкод для собственно реализации алгоритма неоптимален - я даже и не собираюсь спорить Вся соль как раз в том что твоя борьба "за такты" в реализации самого схлопывания замечательно съедается ненужными копированиями гигантских строк-блоков в точке вызова и в фоксовой части кода.

Ну, учитывая, что я в фоксе полный дилетант, меня и не интересовала скорость реализации именно при вызове функи из фокса.
А вот реализация на асме дала определенную пищу для размышлений

spinz
А вот реализация на асме дала

Что за реализация?

Ну я говорю про код Леонида и свои попытки его обогнать))

upd
А, понял, тут ключевое слово "дала"



Исправлено 1 раз(а). Последнее : spinz, 27.01.18 10:28

Simple777
И если в FPD и возникают критические ошибки, то в подавляющем большинстве случаев они воспроизводимы, и можно точно увидеть команду, на которой система вешается.

Вот, к сожалению, есть исключения. Я на своей практике сталкивался и так и не победил два (насколько помню) раза.

2. Второй случай актуален и сейчас. После относительно длительной процедуры (секунд 30, наверное, и больше), в которой идёт интенсивное чтение относительно большого количества данных, например, формирование "большого" отчёта, уже в самом конце, когда отчёт готов и выведен на экран и FPD переходит в состояние ожидания реакции юзера (modify file), процесс FPD зависает. Перестают тикать секунды. Снимается, понятно, только "крестиком". Проявляется проблема спорадически, в одной и той же конторе на одном компе нормально, на другом иногда встаёт колом. Более того, если подключиться к этой машине по RDP, проблема может не возникать, а у «основного» локального юзера на той же машине – косяк. Отловить невозможно – по шагам проблема не воспроизводится. Вроде как, чаще проявляется если данные лежат именно на этой машине, а не тянутся по сети.
Опытным путём нашёл костыль, полностью снимающий эту проблему. Если на конкретной машине косяк проявляется, то в программе в настройке локального рабочего места ставлю галочку. При запуске проги, если эта галочка установлена, с помощью NirCmd переключаю процесс ntvdm.exe на работу на одном ядре. Убого, но работает.

1. Первый случай помню плохо по прошествии лет. Но маялся с ним очень долго. В редких случаях на относительно больших базах (но наоборот, при работе по сети) что-то происходило во время выполнения процедуры биллинга (там тоже интенсивное чтение/запись с блокировками). Насколько помню, тоже зависал процесс, корёжились индексы. Боролся тем, что в разные места вставлял задержки. Типа после каждой сотни обработанных объектов делал wait "ждём 3 секунды" window time 3. В каком именно месте программы возникал косяк так и не удалось обнаружить – эта процедура постоянно меняется и со временем проблема как-то перестала проявляться.

andrewk
если эта галочка установлена, с помощью NirCmd переключаю процесс ntvdm.exe на работу на одном ядре. Убого, но работает.

Есть известная проблема зависания FPD-приложений на многоядерных процессорах. Лечится путем запуска в bat-файле утилиты типа iceaffinity.exe (насчет точности указанного имени не уверен). После этого зависаний нет. Проверено многократно. На форуме тоже есть обсуждение этой темы.



Исправлено 1 раз(а). Последнее : Simple777, 31.01.18 15:18

Jlutko
Может кто-нибудь решал нечто подобное.

forum.foxclub.ru

По поводу выравнивания была отличная статья на хабре
habrahabr.ru

Ерунда все это. Не читал - но не одобряю. (не, ну пытался таки же сколько-то )
Но Игорь в принципе правильно сказал где-то в начале еще - как будут все эти "ассемблерные вставки" разгребаться на 4-х ядерном скажем процессоре - то бабка по воде вилами писала. ;)
Вполне возможно (да оно и скорее всего), какой-нибудь сишно-диезный код с "вложенной самооптимизацией" сделает таки выполнение того же самого на нынешних процах (особливо скажем на новых 12-16-ядерных) реально на порядки быстрее, нежели попытка "возврата к истокам".
Ну а так, как бы для кухни, типа поговорить по душам, тема в принципе конечно "ничо так". Типа Герцен. "Былое и думы".

spinz
По поводу выравнивания была отличная статья на хабре
habrahabr.ru

Цитата оттуда кстати:

Цитата:

Я собирал этот код последним Clang со следующими опциями:

-O2 -march=skylake -fno-unroll-loops


Я запускал этот код на процессоре Intel Core i7-6700 Skylake

чем-то вдруг напомнила песню:

Цитата:

Я брал острую бритву, я правил себя.
Я укрылся в подвале, я резал
Кожаные ремни, Стянувшие слабую грудь

Crispy
Вполне возможно (да оно и скорее всего), какой-нибудь сишно-диезный код с "вложенной самооптимизацией" сделает таки выполнение того же самого на нынешних процах (особливо скажем на новых 12-16-ядерных) реально на порядки быстрее, нежели попытка "возврата к истокам".

Да говнокод никакой компилятор не спасет

spinz

Crispy
Вполне возможно (да оно и скорее всего), какой-нибудь сишно-диезный код с "вложенной самооптимизацией" сделает таки выполнение того же самого на нынешних процах (особливо скажем на новых 12-16-ядерных) реально на порядки быстрее, нежели попытка "возврата к истокам".

Да говнокод никакой компилятор не спасет

Увиливаешь. ;) Суть в самом принципе как бы.
Т.е. вопрос поставлен ребром:
Стоит ли мучиться написанием машинных кодов? Либо использовать таки новые технологии?
Что есть больший гут?
Говно однозначно изначально оставляем соответствующему помещению. И считаем, что в обоих случаях работают лучшие повара.

Crispy
Стоит ли мучиться написанием машинных кодов?

В каких-то случаях стоит

Simple777

andrewk
если эта галочка установлена, с помощью NirCmd переключаю процесс ntvdm.exe на работу на одном ядре.

Есть известная проблема зависания FPD-приложений на многоядерных процессорах. Лечится путем запуска в bat-файле утилиты типа iceaffinity.exe (насчет точности указанного имени не уверен). После этого зависаний нет. Проверено многократно. На форуме тоже есть обсуждение этой темы.

Дак, возможно, когда-то чтение форума и толкнуло меня в эту сторону подумать насчёт ядер))

Но вариант с IceAffinity.exe мне не нравится тем, что он запускается перед стартом нашего процесса, то есть всегда. А (по моей статистике клиентов) такие зависы происходят процентах, наверное, на 10 компьютеров, не больше. Поэтому принудительно переключать всех на одно ядро как-то не комильфо. Лучше уж, раз есть возможность, это сделать только по необходимости.