С учетом всего вышесказанного, не удивительно, что статья Эвана Яреса побудила Николая Снытникова взяться за написание заметки «Многоядерность в процессорах и многопроцессорность в ядрах». В ней будут рассмотрены несколько причин, препятствующих миллиардным корпорациям эффективно поддержать параллельные вычисления в своих геометрических ядрах, и показано, почему такая поддержка будет естественным образом реализована в Российском Геометрическом Ядре.
Оригинал статьи Э.Яреса:
Evan Yares. SPATIAL, ACIS, CGM, AND THE FUTURE OF GEOMETRIC MODELERS
Я впервые принял участие в камерной конференции, в которой приняло участие примерно 60 человек, не считая сотрудников Spatial с учеными степенями по математике, немного похожими на яйцеголовых ботаников. Подобные конференции Spatial ежегодно проводит для своих лучших клиентов, чтобы рассказать им о состоянии дел и планах. Spatial — скромная по размерам компания, в ней работает около 100 сотрудников. Специализация компании — создание программных компонентов для использования в сторонних CAD/CAM/CAE системах. С 2000 года Spatial — дочерняя компания Dassault Systemes.
Наиболее известные продукты Spatial — это широко известное геометрического ядро ACIS и набор трансляторов для 3D-данных 3D InterOp. Менее известные продукты: другие геометрические ядра CGM (Convergence Geometric Modeler) и GGCM (General Geometric Constraint Manager), а также геометрический решатель CDS (Constraint Design Solver), все они достались Spatial от DS, где используются в CATIA V5 и V6. Все эти продукты — весьма интересные, но в этой заметке я остановлюсь лишь на наиболее известных и влияющих на жизнь многих CAD/CAM/CAE-пользователей — на геометрических ядрах ACIS and CGM.
ACIS
Наряду с Parasolid от Siemens PLM, ACIS — самое известное геометрическое ядро. За 20 лет жизни ACIS стал зрелым продуктом. Зрелость означает вполне устойчивую работу и сложившуюся функциональность. Spatial продолжает эффективно поддерживать ACIS, сосредотачиваясь на устранении ошибок и повышении производительности. На конференции Spatial показал нам ряд впечатляющих достижений по повышению производительности, которые были достигнуты на основе использования многопоточности обработки деталей в сборках и исполнения процессов на многоядерных процессорах. А еще нам продемонстрировали оперативную загрузку представления деталей (полигональное представление загружается сразу, а точное — в фоновом режиме).Эта возможность очень многое значит для пользователей ACIS. Например, присутствовавший на конференции представитель SpaceClaim сказал, что его компания будет использовать все продвижения по многопоточности, которые будут реализованы в ACIS. В общем, вполне ясно, что Spatial тратит много сил на внедрение многопоточности в ACIS. Однако, это обстоятельство мало что значит само по себе. Вспомним, что Spatial уже более двенадцати лет работает над механизмами многопоточности для ACIS, однако, за все эти годы удалось решить только несколько самых первоочередных задач. Скажем, многопоточность сравнительно легко реализуется, если в загружаемом файле имеется полигональное представление, но так бывает далеко не всегда. А что насчет обработки сопряжений сложных цепочек ребер в рамках одной детали? Вот это уже по-настоящему трудно.
Уже много лет я обсуждаю проблемы многопоточности с несколькими весьма опытными разработчиками САПР. Мы пришли к единодушному выводу: существует только несколько процессов (внятно декомпозируемых, без зависимостей), которые можно сравнительно легко реализовать в режиме многопоточности. В остальных же случаях внедрить многопоточность в программную архитектуру — весьма трудная задача: если только вы не заложили соответствующие возможности с самого начала. И такие возможности не были с самого начла заложены в ACIS, поэтому внедрить их теперь — огромная работа. Я впечатлен прогрессом, который продемонстрировали разработчики в Spatial, но будущее не сулит никаких чудес. Еще раз уточню: единственный вариант использовать преимущества многопоточности состоит в том, чтобы предусмотреть ее возможности разрабатывая новое геометрическое ядро с новой архитектурой.
CGM
CGM (Convergence Geometric Modeler) было разработано в DS специально для линеек CATIA V5 (и затем — V6). Интересно, что в момент первого выпуска CATIA V5 использовала не CGM, а ACIS. Этот факт не стал достоянием широкой публики, и руководство DS предпочитает о нем не распространяться. Возможно, такое использование ACIS оказалось вынужденным промежуточным решением, но факт тот, что CGM работает и представляет данные существенно не так, как ACIS. Ясно также, что начальные планы DS не предусматривали выпуск CGM как независимо распространяемого геометрического ядра: в CGM просматриваются глубокие зависимости от CATIA. И, когда было принято решение о коммерциализации CGM как распространяемой компоненты, оказалось разумным передать это ядро в Spatial — компанию, занимающуюся как раз программными компонентами. Этот процесс коммерциализации оказался непростым, он не завершен и по сей день. В CGM была удачно реализована геометрия, топология и операторы моделирования, однако — отсутствовала поддержка работы с деталями, если нужно сохранение истории и возвраты. Не было также автономных программных интерфейсов. Для работы требовался стандартизованный открытый формат файлов, а также программы импорта из чужих форматов. Такие средства были добавлены уже в Spatial — в его первом релизе R2012.Первые отзывы на этот релиз оказались положительными: клиентам Spatial (независимым вендорам) понравилась базовая функциональность, интерфейсы, документация. Но им не понравился огромный объем памяти, которого требует работа CGM. Во втором релизе CGM, Spatial добавил интерфейсы для большего числа операторов моделирования, а также расширил набор InterOp-форматов, реализовал поддержку 3DXML и поддержку обработки облаков точек.
Spatial не позиционирует CGM как ядро общего назначения, предназначенное на все случаи жизни. Это ядро нацеливается на поддержку определенных классов задач, для начала — задач метрологии и CAM. Однако по мере того, как Spatial реализует интерфейсы для всех операторов моделирования, продукт станет основой для любых продуктов, вплоть до полномасштабного САПР.
Фундаментальный вопрос относительно CGM состоит в том, является ли эта программа практической альтернативой Parasolid или ACIS (и, в данном контексте — Granite от PTC). Для нынешних применений — ответ: нет, не является. У вас ничего не выйдет, если вы попытаетесь заменить Parasolid или ACIS на CGM. Вопрос не в том, что лучше или хуже (хотя в некоторых приложениях такой вопрос правомерен): просто CGM будет работать совершенно не так.
У CGM есть одно качество, отсутствующее у других геометрических ядер: полная B-rep-совместимость с CATIA V5 и V6. Это выгодно тем независимым вендорам, которые хотят работать в экосистеме DS, но у которых недостаточно квалификации (или терпения!) для того, чтобы стать партнерами DS по разработкам (CAA — Component Application Architecture).
А вот поддержка многопоточности у CGM отсутствует. В этой системе параллельная обработка основана на многопроцессорности, которая используется для связи между процессами как средство разделения данных. Хотя для легко-структурируемых задач такой метод, использующий модель распределенной памяти, может обеспечить определенный выигрыш в производительности, в качестве общего, это решение не годится.
Помимо технических проблем, у CGM есть и другие: одна из них цена лицензирования. Дело в том, что DS (и, следовательно, Spatial) очень гордятся своим продуктом и оценят его выше, чем AСIS. Независимые вендоры, создающие свои CAD/CAM/CAE и другие подобные системы, часто лицензируют чужие технологические компоненты (например, ACIS, HOOPS, DCM и т.п.) на основе royalty — отчислений процентов от своих релевантных доходов. Такие отчисления могут находиться на уровне
Короче говоря, CGM развивается в сторону полноценного геометрического ядра, однако, вряд ли сможет заменить ACIS or Parasolid, и уж точно не является «геометрическим ядром будущего», которое сможет превзойти своих нынешних конкурентов.
А как насчет SolidWorks V6?
Скорее всего, слухи о SolidWorks V6 дошли и до вас. Это готовящийся к выпуску продукт следующего поколения от DS SolidWorks Corp, основанный на технологии CATIA/ENOVIA V6. Беседуя с Linda Lokay, вице-президентом Spatial по маркетингу и развитию бизнеса, я спросил ее, будет ли в SolidWorks V6 использоваться CGM и 3D InterOp, и добавил: «Вы же не собираетесь мне ответить, ведь так?». Линда только улыбнулась и порекомендовала обратиться к в SolidWorks — к Fielder Hiss, вице-президенту по маркетингу и управлению продуктами. Ну, что же: ответ вполне честный.Я думаю, что для разработки своих продуктов SolidWorks будет использовать всю инфраструктуру DS CATIA/ENOVIA V6, но это — только мое предположение. И еще мне кажется, что для чтения существующих файлов SolidWorks, в SolidWorks V6 было бы разумно использовать недавно созданный в Spatial модуль для непосредственного чтения файлов Parasolid. В кулуарах той же конференции я побеседовал со своим старым приятелем — прекрасно разбирающимся в читалках файлов — и спросил его: есть ли принципиальная техническая возможность построить читалку для Parasolid, которая сможет обеспечить