[power85]

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

[румата]

Сообщение от Кулик Алексей 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