[power85]

Здравствуйте
Имеется lisp код на 1600 строк выполнятся, он может 12час. Определено узкое место. Нужно распараллелить вычисления на многоядерном процессоре.
Кроме этого я знаю языки Python и Vba. В Python есть, возможно, распараллелить вычисления и сделать функцию для узкого места. Но как её использовать в lisp?
Переписать весь код lisp 1600 строк в код на Python не реально.

[Сергей812]

Сообщение от power85 Переписать весь код lisp 1600 строк в код на Python не реально.

думаете городить интеграцию с кодом на питоне с параллельным выполнением вычислений займет сильно меньше времени?) А VBA - это тот же ActiveX, скорости на нем не получите.

----- добавлено через ~5 мин. -----
тот же код на .Net можно ориентировочно считать на пару порядков быстрее лиспа работает, т.е. вместо 12 часов будет 10 мин даже без распараллеливания

----- добавлено через ~8 мин. -----

Сообщение от power85 Или как сделать параллельное программирование в Visual Lisp?

ничего, что акад (хотя, может, в последних версиях есть подвижки) - работает на одном ядре?)

[Кулик Алексей aka kpblc]

Я бы подумал на предмет изменения этого самого куска. Логического изменения.

[power85]

Сообщение от Сергей812 тот же код на .Net можно ориентировочно считать на пару порядков быстрее лиспа работает, т.е. вместо 12 часов будет 10 мин даже без распараллеливания

.Net реально на столько крут? Есть тесты сравнения? Конечно рискованно и сложно переписать на Net чтобы проверить.

[Кулик Алексей aka kpblc]

Зависит от задач и сложности хранения данных. И от качества кода, конечно. У меня было, что NET, написанный криво, работал втрое медленнее некомпилированного лиспа. А бывало, что NET в несколько десятков раз быстрее.
P.S. Этот кусок выполняется 12 часов в некомпилированном виде? А если собрать его в fas?

[power85]

Сообщение от Кулик Алексей aka kpblc Я бы подумал на предмет изменения этого самого куска. Логического изменения.

На мой взгляд я написал этот кусок максимально оптимизировано.

----- добавлено через ~2 мин. -----

Сообщение от Кулик Алексей aka kpblc P.S. Этот кусок выполняется 12 часов в некомпилированном виде? А если собрать его в fas?

Да собрал я его в fas т.е. с компилируемый.

[Кулик Алексей aka kpblc]

Offtop: Я в свое время тоже так думал. Пока не поменял ненужный mapcar на foreach

----- добавлено через ~2 мин. -----
Offtop: Ну и - дополнительно - вопрос в качестве входящих данных. Если они слабоструктурированы, то, может, узкое место совсем не здесь? ))

[power85]

Сообщение от Кулик Алексей aka kpblc Зависит от задач и сложности хранения данных. И от качества кода, конечно. У меня было, что NET, написанный криво, работал втрое медленнее некомпилированного лиспа. А бывало, что NET в несколько десятков раз быстрее.

То есть функцию можно сделать с параллельным программированием можно сделать только в Net?

----- добавлено через ~5 мин. -----

Сообщение от Кулик Алексей aka kpblc Offtop: Ну и - дополнительно - вопрос в качестве входящих данных. Если они слабоструктурированы, то, может, узкое место совсем не здесь? ))

Может быть не здесь. Там долго происходит проверка (поиск) куда можно поставить мультивыноски между примитивами. А проверка происходит на пересечения.

[Кулик Алексей aka kpblc]

Я сильно подозреваю, что параллельность не сильно понадобится. Смотри, допустим, есть задача из списка вытащить что-то там по ключу. Проблема в том, что ключ может быть строковым. И необязательно в едином регистре. Придется городить костыли, хотя достаточно просто данные "снаружи" привести в божеский вид.
Offtop: Пример, конечно, высосан из пальца, но тем не менее:

Код:

[Выделить все]

 (defun t1 (key data)
  (cdr (assoc (if (= (type key) 'str)
                (strcase key)
                key
              ) ;_ end of if
              (mapcar (function (lambda (x)
                                  (cons
                                    (if (= (type (car x)) 'str)
                                      (strcase (car x))
                                      (car x)
                                    ) ;_ end of if
                                    (cdr x)
                                  ) ;_ end of cons
                                ) ;_ end of LAMBDA
                      ) ;_ end of function
                      data
              ) ;_ end of mapcar
       ) ;_ end of assoc
  ) ;_ end of cdr
) ;_ end of defun

(defun t2 (key data)
  (cdr (assoc key data))
) ;_ end of defun

И собственно проверки:

Код:

[Выделить все]

 _$ (setq key "a" data '((1 . 20) ("b" . 1342) ("A" . "asdf") ("a" . "qwer")))
((1 . 20) ("b" . 1342) ("A" . "asdf") ("a" . "qwer"))
_$ (t1 key data)
"asdf"
_$ (t2 key data)
"qwer"
_$ (BENCHMARK '((t1 key data) (t2 key data)))
Benchmarking ..................Elapsed milliseconds / relative speed for 32768 iteration(s):

    (T2 KEY DATA).....1453 / 1.61 <fastest>
    (T1 KEY DATA).....2344 / 1 <slowest>

И результаты разные

[power85]

Сообщение от Кулик Алексей aka kpblc Я сильно подозреваю, что параллельность не сильно понадобится. Смотри, допустим, есть задача из списка вытащить что-то там по ключу. Проблема в том, что ключ может быть строковым. И необязательно в едином регистре. Придется городить костыли, хотя достаточно просто данные "снаружи" привести в божеский вид.

Спасибо За ответы.
Понятно.

[Сергей812]

Сообщение от power85 .Net реально на столько крут?

.Net работает фактически напрямую с акадом (через обертки над нативным С++), а сама обработка данных вообще акад не затрагивает по сути. Плюс есть куча готовых вещей - списки, словари и т.д. Ну а так смотря какой код напишите) Вот у Алексея были тесты, у меня по сравнению с аналогичными задачами при переходе с Interop (тот же ActiveX) на .Net скорость выполнения кода примерно на пару порядков и подросла.

Причем на .Net можно делать AutoLISP Function Definition и вызывать из лиспа основной программы (это к вопросу тестирования производительности - что не всю программу перелопачивать сразу, а по частям).

[power85]

Сообщение от Сергей812 .Net работает фактически напрямую с акадом (через обертки над нативным С++), а сама обработка данных вообще акад не затрагивает по сути. Плюс есть куча готовых вещей - списки, словари и т.д. Ну а так смотря какой код напишите) Вот у Алексея были тесты, у меня по сравнению с аналогичными задачами при переходе с Interop (тот же ActiveX) на .Net скорость выполнения кода примерно на пару порядков и подросла.

Спасибо за ответы.
Понятно. Круто.

[Кулик Алексей aka kpblc]

Сообщение от power85 ам долго происходит проверка (поиск) куда можно поставить мультивыноски между примитивами. А проверка происходит на пересечения.

Знакомая задача Тут вполне может оказаться наиболее выгодным (если оставлять все на лиспе) создавать новый документ через ObjectDBX, туда клонировать примитивы и напрямую в том документе создавать / проставлять мультивыноски. А потом готовые мультивыноски склонировать в текущий. Тупо, но иногда достаточно выгодно.

[power85]

Сообщение от Сергей812 Причем на .Net можно делать AutoLISP Function Definition и вызывать из лиспа основной программы (это к вопросу тестирования производительности - что не всю программу перелопачивать сразу, а по частям).

Вот это другое дело.
То есть можно создать в VB.NET функцию далее сохранить в dll. Далее загрузить dll в autocad через netload и можно пользоваться этой функцией как обычной lisp? Просто я не профессиональный программист.

----- добавлено через ~6 мин. -----

Сообщение от Кулик Алексей aka kpblc Знакомая задача Тут вполне может оказаться наиболее выгодным (если оставлять все на лиспе) создавать новый документ через ObjectDBX, туда клонировать примитивы и напрямую в том документе создавать / проставлять мультивыноски. А потом готовые мультивыноски склонировать в текущий. Тупо, но иногда достаточно выгодно.

Понятно. Хорошая идея.

[Кулик Алексей aka kpblc]

Сообщение от power85 То есть можно создать в VB.NET функцию далее сохранить в dll. Далее загрузить dll в autocad через netload и можно пользоваться этой функцией как обычной lisp?

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

[румата]

Сообщение от power85 То есть можно создать в VB.NET функцию далее сохранить в dll. Далее загрузить dll в autocad через netload и можно пользоваться этой функцией как обычной lisp?

Да, можно. Можно даже командный метод программирования в .net использовать

----- добавлено через ~11 мин. -----

Сообщение от Кулик Алексей aka kpblc Просто у меня на такие вещи почему-то достаточно большие потери на разбор входящих данных (если это списки какие-то достаточно странные) и формирование выходных списков.

Не понятно, что за входные списки?

[Кулик Алексей aka kpblc]

Ну, к примеру, лисповая функция обрабатывает список вида '(("key1" . "value1") ("key2" "val21" "val22" "val23) ...), и должна вернуть нечто типа '((1 . 1) (2 . 3) ...) - логика сейчас не важна. На NET (я про замену "в лоб") придется корректно разбирать входящий параметр и опять же - корректно формировать выходной список. У меня на выполнение именно этого куска тратится прилично времени.

[румата]

Сообщение от Кулик Алексей aka kpblc Ну, к примеру, лисповая функция обрабатывает список вида...

Не понятно откуда берется и что определяет такой список вида... Это парсинг данных из внешнего файла для скармливания автокаду или еще что?

[Кулик Алексей aka kpblc]

Я не про это. На входе в функцию данные, которые как-то структурированы и которые надо каким-то хитрым образом обработать. И вернуть тоже список, чтобы не порушить остальной код.
К примеру:

Код:

[Выделить все]

 (setq lst (vl-remove nil
                     (apply (function append)
                            (mapcar (function (lambda (name)
                                                (read-data-from-dict ent name)
                                              ) ;_ end of LAMBDA
                                    ) ;_ end of function
                                    '("data" "links" "ext")
                            ) ;_ end of mapcar
                     ) ;_ end of apply
          ) ;_ end of vl-remove
) ;_ end of setq

После этого как раз и получаем список типа (("key1" . "value1") ("key2" "val21" "val22" "val23) ...). А дальше где-то по коду встречается

Код:

[Выделить все]

 (setq res (change-dict-datas lst))

И твоя функция change-dict-datas как раз ожидает формат lst, и возвращает '((1 . 1) (2 . 3) ...) для дальнейшего использования. Так что если ты переписываешь change-dict-datas на NET, то и новое определение должно возвращать такое же. Иначе надо переделывать вообще все, а на это никогда нет ни времени, ни возможностей.

----- добавлено через ~1 мин. -----
Естественно, все имена фунций выдуманы прямо на ходу.

[power85]

Сообщение от румата Можно даже командный метод программирования в .net использовать

А где можно про это почитать? Или как это делается?

[румата]

Сообщение от Кулик Алексей aka kpblc На входе в функцию данные, которые как-то структурированы и которые надо каким-то хитрым образом обработать. И вернуть тоже список, чтобы не порушить остальной код. К примеру:

Ну так LINQом в .net это делается очень элегантно наподобия запроса к базе данных. При этом это очень быстро работает со всеми внутренними нетовскими структурами массивов, т.е. и со словарями и с простыми списками и с очередями и со стопками.

[power85]

Сообщение от Кулик Алексей aka kpblc Да, можно. Просто у меня на такие вещи почему-то достаточно большие потери на разбор входящих данных (если это списки какие-то достаточно странные) и формирование выходных списков. Но из меня NET-программист как из слона балерина

Сообщение от румата Да, можно.

Отлично. Буду пробовать.

[Сергей812]

Сообщение от power85 А где можно про это почитать? Или как это делается?

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

[Кулик Алексей aka kpblc]

Сообщение от румата Ну так LINQом в .net это делается очень элегантно наподобия запроса к базе данных. При этом это очень быстро работает со всеми внутренними нетовскими структурами массивов, т.е. и со словарями и с простыми списками и с очередями и со стопками.

Хм, в таком ключе еще не думал... Побрел искать, читать и пытаться осознать

[румата]

Сообщение от power85 А где можно про это почитать? Или как это делается?

Здесь можно посмотреть. Там и примеры и куски кода

[Сергей812]

Сообщение от румата Ну так LINQом в .net это делается очень элегантно наподобия запроса к базе данных. При этом это очень быстро работает со всеми внутренними нетовскими структурами массивов, т.е. и со словарями и с простыми списками и с очередями и со стопками.

ну там то речь шла - чтобы не переделывать остальной код на лиспе для использования .Net)

----- добавлено через ~3 мин. -----
а передача данных из условной Лисп-машины в .Net функцию и обратно явно будет узким местом как стык между управляемым кодом .Net и тем же ActiveX

[румата]

Сообщение от Сергей812 ну там то речь шла - чтобы не переделывать остальной код на лиспе для использования .Net)

Так не получится.

----- добавлено через 51 сек. -----

Сообщение от Сергей812 а передача данных из условной Лисп-машины в .Net функцию и обратно явно будет узким местом как стык между управляемым кодом .Net и тем же ActiveX *

Нужно будет городить промежуточный обмен файлом для передачи внутренних массивов данных между лисп и net

----- добавлено через ~9 мин. -----

Сообщение от румата Здесь можно посмотреть. Там и примеры и куски кода

Прошу прощения немного не ту ссылку сделал. Здесь можно посмотреть как использовать внутренние команды через обращение к командной строке.

[Сергей812]

Сообщение от румата Нужно будет городить промежуточный обмен файлом для передачи внутренних массивов данных между лисп и net

здесь возникает вопрос - а зачем собирать информацию в более медленном лиспе, потом пропихивать ее в .Net метод, а после этого - возможно, еще и обратно?

Имхо, рациональнее Lisp-подобные функции использовать в следующих случаях:
1. Диалоги (причем помимо диалога можно там же и с БД работать или иным внешним хранилищем. и т.п.). И возвращать лишь конечный результат.
2. Обработка больших объемов информации по некоторому конечному набору критериев (пускай с самой БД dwg чертежа уже внутри .Net метода работает).
3. Реализация функционала, отсутствующего в самом Lisp (по сути альтернатива подключаемым внешним библиотекам).

[румата]

Сообщение от Сергей812 Имхо, рациональнее Lisp-подобные функции использовать в следующих случаях:

Лисп-функции программируемые из-под .net это же просто обертки над net с ограничинным набором типов данных, которыми можно обмениваться при последующем программировании на лиспе. Чтобы не было проблем это ограничение нужно иметь в виду при написании программ на лиспе. А скорость обмена данными между такими функциями и родными лисповскими функциями через ResultBuffer и TypedValue, по идее, не должна стать узким местом. Хотя внутренние издержки, конечно, будут.

[power85]

Сообщение от румата Лисп-функции программируемые из-под .net это же просто обертки над net с ограничинным набором типов данных, которыми можно обмениваться при последующем программировании на лиспе. Чтобы не было проблем это ограничение нужно иметь в виду при написании программ на лиспе. А скорость обмена данными между такими функциями и родными лисповскими функциями через ResultBuffer и TypedValue, по идее, не должна стать узким местом. Хотя внутренние издержки, конечно, будт.

Спасибо. Буду разбираться и пробовать.

[Сергей812]

Сообщение от румата Лисп-функции программируемые из-под .net это же просто обертки над net

точнее - это код .Net, помеченный атрибутом LispFunction для возможности взаимодействия с Lisp-кодом путем встраивания дополнительных метаданных в сборку. Иначе как акад узнает - что там программист решил реализовывать в сборке, если он (акад) сможет из метаданных получить только название метода без дополнительной информации.

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

[Александр Ривилис]

Сергей812,
Передача большого списка (десятки тысяч элементов и больше) из VisualLisp в lisp-функцию, созданную при помощи .NET очень не рекомендую. Замечал очень большие задержки именно на этапе передачи списка. Причем это не только в .NET, но и в чистом ObjectARX.

[Сергей812]

Сообщение от Александр Ривилис Передача большого списка (десятки тысяч элементов и больше) из VisualLisp в lisp-функцию, созданную при помощи .NET очень не рекомендую. Замечал очень большие задержки именно на этапе передачи списка. Причем это не только в .NET, но и в чистом ObjectARX.

насколько понимаю, список лиспа являет однонаправленным списком и передается значение первого элемента (в отличие от указателя на начало области памяти массива, как в "классических" языках программирования). И, соответственно, вместо передачи напрямую в ObjectARX/.Net списка как ссылки на коллекцию происходит проход по всему списку.

[румата]

Сообщение от Сергей812 И, соответственно, вместо передачи напрямую в ObjectARX/.Net списка как ссылки на коллекцию происходит проход по всему списку.

Да. Даже передаваемый по ссылке ResultBuffer нужно форычить для дальнейшей работы с передаваемыми данными.

[Петр-и-Алекс]

когда то существавали компиляторы lisp
конечно же с большими ограничениями ... и за деньги (не большие вообще то)
не знаю, как оно сегодня обстоит

[trir]

Там долго происходит проверка (поиск) куда можно поставить мультивыноски между примитивами. А проверка происходит на пересечения.

надо использовать RTree

[румата]

Сообщение от trir надо использовать RTree

А есть такая структура данных в объектной модели автокада?

[trir]

https://habr.com/ru/post/278765/

https://github.com/rpav/spatial-tree...r/r-trees.lisp