[peshkoff 24]

3 hours ago, dxp said:

Тема, вроде, уже обсуждалась когда-то...

вкратце: альтиум тормозил, тормозит и будет тормозить.

никакое железо с китайскими циклами не справится.

забейте

[dxp 33]

48 минут назад, peshkoff сказал:

китайскими циклами

Это про что?

[peshkoff 24]

2 minutes ago, dxp said:

Это про что?

Вы же программист? От программистов слышал такое, это когда вместо цикла (условно) for i:=1 to 10 do... пишется десять строк повторяющихся. якобы китайцы так программируют. Шутка, наверное... :)

речь о том, что "новые необходимые" функции программистами альтиума вставляются операцией типа "костыль". Кое как ее подниму, а что там рядом валяется и что все может колом встать, да пофиг

[dxp 33]

9 минут назад, peshkoff сказал:

От программистов слышал такое, это когда вместо цикла (условно) for i:=1 to 10 do... пишется десять строк повторяющихся. якобы китайцы так программируют. Шутка, наверное... :)

Не, не слышал такой шутки. Но это не сильно шутка, такой приём называется unroll loop, применяется для ускорения как раз. Правда, современные компиляторы сами такое уже умеют, особенно если им подсказывать. Код, конечно, раздувается. 

[AlexandrY 2]

1 hour ago, peshkoff said:

Вы же программист? От программистов слышал такое, это когда вместо цикла (условно) for i:=1 to 10 do... пишется десять строк повторяющихся. якобы китайцы так программируют. Шутка, наверное... :)

Эт примитивный взгляд.
Реальность гораздо сложнее. Altium при открытии PCB  создает более 50! процессов на каждую. 
Достаточно там немного тормозить чему-то в операционке с организацией синхронизации, как процессы начинают тормозить на мьютексах, семафорах, очередях и т.д. и мультиплицируют тормоза.

Кстати сейчас видеокарты сами решают на чем делать рендеринг, на CPU или на GPU и на скольких CPU.
Я для Altium-а оставлял для рендеринга только один CPU из 20 имеющихся , и все равно все летало.  
Так что у кого тормозит должен искать проблемы в операционном окружении на своем компе. 

[peshkoff 24]

22 minutes ago, AlexandrY said:

Эт примитивный взгляд.

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

а летательность ПО - признак субъективный

[dxp 33]

Затраты памяти. Один и тот же проект.

 

AD14.3

 

AD21

 

[popms 3]

AD18+ на других движках построен на системе Х2. Многие модули переписываются на c#, подключаются многие библиотеки, подключается DirectX обработка графики и т.д.

 

запустите PCAD, там ещё меньше будет чем в AD14.3

[AlexandrY 2]

54 minutes ago, popms said:

AD18+ на других движках построен на системе Х2. Многие модули переписываются на c#, подключаются многие библиотеки, подключается DirectX обработка графики и т.д.

У ТС-а речь идет о работе в виртуалке VMware.  Да еще под 7-ой виндой, это которую уже не поддерживают . Ситуация ясная. Могло быть и хуже. 

Я вот поставил Altium на самый дохлый PC что был под рукой, на i5-4570T без видеокарты, на нативном интеловском контроллере.  Они у нас на стендах релюшками щелкают. 
Ну все работает без каких-либо напрягов.
Задержек с курсором нет, двигается все быстро, но только полигоны стали реально медленно прорисовываться и DRC тормозит. 
Т.е. Altium  и на планшете с Win 10 будет работать. 

[dxp 33]

Пикад умеет то же, что и AD14?

 

Главный вопрос темы и был про то, что такого нового умеет AD21 по сравнению с AD14, что за это приходится платить ресурсами? Пока что были озвучены варианты:

• AD21 лучше работает с большими проектами.
• AD21 умеет использовать более 3.5 гига памяти.
• в AD21 стало быстрее работать 3D.

По богатству функционала замечаний не последовало. Из того, что я заметил, выравнивание длин стало попродвинутее - умеет не только меандры (аккордеоны), но и тромбоны. 

[dxp 33]

58 минут назад, AlexandrY сказал:

У ТС-а речь идет о работе в виртуалке VMware.  Да еще под 7-ой виндой, это которую уже не поддерживают . Ситуация ясная. Могло быть и хуже. 

Причём тут это? На виртуалке старые версии меньше памяти жрут, чем на хостовой ОС? Или семёрка что-то тут вносит? Вы сами-то верите в эту ерунду? Я подкрутил параметры вмвари, добился, чтобы шевелилось юзабельно. Но разница в потреблении ресурсов - в данном случае памяти (её взяли потому, что это проще всего измерить) никуда не делась. Что-то же в программе эту память потребляет. 200 М и 1.2Г - разница существенная. Мне не жаль памяти, у меня толстый хост, всего хватает. Но хочется понять куда это идёт. 

 

Ситуация похожа на ту, что с браузерами. Не секрет, что современные браузеры жрут память непомерно. Несколько гигов - обычное дело. Да ещё и "текут" постоянно, это не лечится, тут только периодические перезагрузки. Причина ликов в менеджере памяти (его сборщике мусора) jvm. Но не суть. И вот вспоминаются браузеры 15-летней давности. Они тоже умели открывать страницы. Исполнять скрипты. Проигрывать мультимедию. Что реально нового умеют современные браузеры по сравнению с теми? А, да, TLS появился, секурность. Но это не требует таких ресурсов. Специалисты говорят, что такой нынче интернет, и показывают, что клик по ссылке, которая открывает страницу, приводит к созданию двух десятков (и это далеко не предел) TCP соединений. И вот зачем это? Зачем так делать? Какая необходимость? Почему 15 лет назад можно было без этого обходиться?

 

Есть мнение, что просто никто не задумывается о деталях реализации. Главный приоритет - скорее выкинуть на рынок. "Х..як, х..як и в продакшн" - это давно уже вышло за пределы шутки и стало кредо многих IT компаний. А многие уже и просто не могут писать эффективный код, там нет специалистов, которые понимают, как работает железо, как писать эффективный код. Тяжёлая САПР печатных плат должна разрабатываться на С++ (или другом языке, дающим эффективный, быстрый код), а не на скриптовых языках. Но найти квалифицированного С++ программера намного сложнее, чем такового на C# или Java. Вот и идут по пути наименьшего сопротивления. В идеале для них, наверное, было бы вообще сделать САПР в виде веб-приложения. Но тут пока ресурсы не позволяют.

 

Что касается конкретно AD, то мне представляется, что основной прирост потребления той же памяти всё же обусловлен переходом на новые версии фреймворков, которые там используются и отсутствие усилий по оптимизации. За скорость наверное как-то ещё борются, т.к. это критично, особенно на больших проектах, а за память - да кому это надо: не хватит 16 гигов, поставят 32, не хватит этого, тогда  64. Хосты нынче позволяют.

 

Да, забыл в предыдущем посте добавить ещё пункт, что в AD21 скорость заливки полигонов увеличилась. Гуд. Но неужто построение 2D фигуры пусть и с непростой геометрией жрёт такой ресурс? Я не специалист, да, но вот смотрю на конструкторские САПРы, там сложные 3D объекты строят в пространстве, вращают их, трансформируют, и не видать, чтобы что-то тормозило. Если на заливке полигонов тормозит, может что-то с математикой и/или кодированием (реализацией) этого не всё в порядке?

[AlexandrY 2]

2 hours ago, dxp said:

И вот зачем это? Зачем так делать? Какая необходимость? Почему 15 лет назад можно было без этого обходиться?

В Altium как раз и вставили броузерный движок - https://cefsharp.github.io/. И похоже это он отжирает 1 GB. 
И да, написан на плюсах и еще тянет весь .NET CLR. 

А в остальном все как было. Даж DirectX до сих пор 9-й.
Но за это мы получили возможность проверки стоков и цен прямо в схеме. 
Кликаешь на компоненте, открывается диалог в каких стоках и почем он есть и выбираешь лучшее предложение. 
Эт просто киллер фича, за такую мне и 4 GB не жалко отдать.

 

[Uree 1]

Ааа, вмварь... там лаги из-за "удлиннения" программного интерфейса мыши. С аллегро/оркад в ней такая же ерунда, графика реагирует с задержками на движения мыши при панорамировании/зуме. Т.е. теоретически производительности достаточно, но задержки больше, вот и получается, как получается.

[peshkoff 24]

58 minutes ago, AlexandrY said:

открывается диалог в каких стоках и почем он есть и выбираешь лучшее предложение

интересно услышать, как это связано с реальной жизнью

[dxp 33]

4 часа назад, Uree сказал:

Ааа, вмварь... там лаги из-за "удлиннения" программного интерфейса мыши. С аллегро/оркад в ней такая же ерунда, графика реагирует с задержками на движения мыши при панорамировании/зуме. Т.е. теоретически производительности достаточно, но задержки больше, вот и получается, как получается.

Аллегру я ради интереса поднял нативно в линухе (в контейнере с centos7 под убунтой) и на той же виртуалке. Визуально скорость работы почти одинаковая (может чуть лучше "контейнерый" вариант). И она (алегра) поотзывчивее будет, чем AD. И памяти меньше жрёт.

5 часов назад, AlexandrY сказал:

В Altium как раз и вставили броузерный движок

Правдоподобное объяснение.