Segger Embedded Studio

ARM
Картинко
Доброго времени суток, дорогой читатель!
Идея написать что-нибудь родилась у меня после того как поиском не нашел ни слова про эту среду разработки(«А жаль и надо что-то делать», — подумал я).
Eclipse я терпеть не могу(особенно после периода вынужденной работы в Xilinx Vivado). Сторонники могут со мной спорить, но я все равно пойду искать что-нибудь быстрое, написанное на C/C++, прости господи, С#. Почему сравнение с Eclipse? Да потому, что более топорного редактора чем IAR вообще сложно найти. Вообще, мрак win98 напоминает, нафиг его(хоть и компилятор вроде ничего). А мода использовать Eclipse в качестве среды разработки для ARM'ов похоже постигла всех производителей железа… В долгих копаниях и поисках набрел на вот эту среду. Прикольно, подумал я. Однако дорого. Побродив еще немного совершенно случайно уже набрел на Segger Embedded Studio. Тот же продукт, но уже бесплатно, от Segger.
Короч, не буду сильно долго разводить сопли, сразу к делу.
Поддержка ARM:
Analog Devices
Atmel SAMD21, SAMR21
Freescale Kinetis
Infineon XMC4000
Nordic nRF
NXP LPC1700, LPC 1800, LPC4300
Silicon Labs EFM32xx
Spansion FMx
ST STM32f0xx, f1xx, f2xx, f3xx, f4xx, f7xx, L0xx, L1xx, L4xx, W1xx
Texas Instruments MSP432p4xx, TM4c
Неплохой пакет для начала.
Все это счастье работает после установки доп пакетов через Package Manager(Tools->Package Manager).

После установки получаем рабочую среду с IntelliScence, компилятором, стартовым кодом, библиотеками, realtime отладчиком(это отдельная тема) с поддержкой всего вышеперечисленного зоопарка чипов. И никакой Java! :)
Бесплатно для личного пользования(ограничений по коду нет).

Побольше инфы тут

Что понравилось:
1) Скорость работы
2) Относительная полнота документации
3) Настраиваемость среды
4) IntelliScence + Source Navigator+ Symbol Browser
5) Скорость отладки с jLink(она реально бешеная в сравнении с Eclipse-средами)
6) Отображение всех регистров, периферии, битов, масок и прочей ботвы во время отладки
7) Поддержка импорта проектов сторонних сред
8) Возможность работы с STM32CubeMX
9) Многопоточная компиляция(до 16 потоков, сборка проекта из 27 «с» файлов за 1.7с)
10) Поддержка систем контроля версий(пока не пользовался, но прикольно)

Symbol browser здесь — это отображение блоков кода в файле(особенно понравился для xml-файлов). Фишка так себе, но полезна при навигации по большим файлам.
Source navigator — все проиндексированные элементы кода и библиотек в проекте с поиском. Удобно когда не знаешь точно название функции/typedef'a/переменной, а только часть имени. Еще полезно просто посмотреть, что может быть использовано в проекте, что используется и вообще. Must have фича.

Еще есть своего рода дизассемблер и редактор ресурсов. Полезно глянуть из чего готовый elf/hex состоит.
Профилировщик тоже имеется.

Что НЕ понравилось:
1) Иногда все-таки вылетает с ошибками(может пора просто почистить систему? :))
2) Есть некоторые недоработки при импорте проектов из KEIL/IAR
3) Поддержка только jLink в качестве интерфейса прошивки/отладки(для неимеющих китайских клонов jLink есть Simulator).

Из непроверенного, возможность работы под Unix|MacOS и для меня это большой плюс на будущее.

А вот это скрин отладки:
Дебуг
Статейка получается скомканой, может быть допишу и перепишу, если кому-то будет интересно могу как нибудь рассказать про работу в среде с STM32, STMCubeMX, импорт проектов и отладку jLink'ом. А пока все."
  • +7
  • 09 ноября 2016, 19:38
  • geonicz

Комментарии (117)

RSS свернуть / развернуть
Хоть бы скрины привел, дабы представлять о чем речь идет.
0
  • avatar
  • Vga
  • 09 ноября 2016, 21:10
Добавил, хотя больше скринов всего и вся по ссылке «ТУТ» в самой статье.
0
Было бы неплохо, если бы понравилось/не понравилось сопровождалось релевантными скринами. Заодно, глядишь, и статья выглядела бы менее скомканно)
0
А мне нравится IAR )) Прям как в раньше под виндами програмишь ))
0
А что за файлики лезут RTT в новом проекте?
0
Стандартные библиотеки Segger'a. Выставляют некоторые настройки, функции(printf, puts, __getchar, __putchar)и переменные, позволяющие работать с терминалом в реальном времени и не только(проекты можно отлаживать в железе просто как обычное Windows/Unix приложение безо всяких там костылей со светодиодиками).
Кое-что из комментов в файле SEGGER_RTT.c
«Implementation of SEGGER real-time transfer (RTT) which allows real-time communication on targets which support debugger memory accesses while the CPU is running.»
Вообще компилятор идет со своей библиотекой С и документацией к ней. Можно использовать, а можно не использовать(пользоваться сторонними, CMSIS, SPL) — дело вкуса.
0
RTT от сеггера, кстати, можно использовать в любой среде. Есть эти библиотеки на сайте. Просто добавляем в проект, настраиваем Putty или юзаем фирменную утиль от segger. Фишка в том, что отладочный вывод передается прямо через отладчик (поток вклинивается в пакеты отладчика), не занимает отдельный uart и не тормозит всю программу. Не глючит, как встроенный терминал того же IAR-а. Удобная, годная вещь. Да что там говорить, вот: habrahabr.ru/post/259205/
0
0
А St-link поддерживается?
0
Нет. В поддержке только J-Link. Работает с китайскими клонами за 20 у.е., поддерживающими все линейки ARM.
Сам работаю через китайца по SWD интерфейсу(можно и JTAG выставить).
0
Если кому нужно то www.segger.com/jlink-st-link.html
0
Возможное решение к вопросу выше).
Хотя я бы не жмотился и просто заказал J-Link на aliexpress.
0
Зачем? Если есть st-link с того же ali.
0
Тут вопрос скорее зачем St-Link. Поясню: st-link «может» только STM8/STM32, J-Link может все Cortex'ы в принципе + все STM32. J-link поддерживается всеми средами разработки, st-link меньше. Выбор производителей знааачительно шире получается, а добавка в цене — пара(ну пусть десятка) долларов.
0
st-link «может» только STM8/STM32
Но с другой стороны, STM8 может только он. Да и STM32, АФАЙК, лидируют среди ARM'ов в среде любителей. Да и просто дешевый (хотя ща уже и J-Link'и баксов по 10 есть, если не меньше...). Поэтому у многих может быть лишний ST-LINK, который не жалко перешить в J-LINK.
0
Признаться вообще не вижу смысла в покупке отдельного St-link. Только разве в составе Demo-board.
0
не поддерживает русские буквы в каталоге… впрочем как и везде во всех средах… Правда это скорее предъява к компилеру, потому как именно он тупит…
0
кирилица в именах файлов нинужна
0
В NT5 в некоторых системных путях от пробелов и кириллицы нельзя избавиться. В NT6 пофиксили, но многие до сих пор пятую любят… В Atmel Studio 5 это раздражало, симулятор там не переваривает пробелы в путях.
0
Да есть такой косяк. Сам когда AVR Dragon'ом отлаживал какую-то тиньку наткнулся и долго не мог понять в чем беда. А оказалось что в моей английской системе случайно затесалась директория или файл(уже не помню деталей) с кириллицей. Удивился(в век юникода? странно), проматерился, переименовал и пошел дальше отлаживать.
0
> IntelliScence + Source Navigator+ Symbol Browser
А можно чуть подробней в разрезе этих трех опций. Я просто IDE не пользуюсь (так уж получилось). При этом все очень их хвалят в том числе за встроенный отладчик и наличие этих вот трех волшебных слов. Что конкретно под ними понимается?
Автодополнение, дерево проекта и поиск вхождения символов?
0
Полагаю, что все понимают по разному, тем паче что IntelliSense это вообще название конкретной фишки майкрософтовской студии.
А так (для меня) примерно да (за исключением дерева проекта) — автодополнение и подсказки, навигация по коду, etc. Причем оно бывает в разном объеме, так что неплохо бы, конечно, еще и оценку того, как оные возможности реализованы.
0
мдя. Почитал тут про IntelliScence. Оказывается всего лишь автодополнение и подсказки. Я скорблю.
0
А что еще надо?
0
Да не в этом дело. Целая толстая и жирная ИДЕ ради трех смешных возможностей которые есть в любом приличном редакторе (либо встроенные либо при помощи внешних простых приложений).
Конечно, визуальная отладка с контролем регистров весьма приятна, но в целом какого-то серьезного преимущества не дает (а если ацки тормозит и виснет, то вообще можно считать вредом).
0
трех смешных возможностей которые есть в любом приличном редакторе
А в каком «приличном редакторе» они есть? Я как-то не встречал таких, да и в самих IDE (особенно — IDE для эмбеда) оно далеко не всегда есть, далеко не всегда хорошо сделано и далеко не всегда хорошо работает.
Собственно, продвинутый интеллисенс — основная причина, почему платят за тормозящие и жрущие память гигабайтами иде от JetBrains.
0
Я под приличным редактором понимаю как минимум vim. Конечно вызова справки по функциям там нет (из коробки. Подозреваю, что эта штука появляется при подключении соответствующего плагина и доксигена). Но автодополнение там есть. Навигация по коду (переход к объявлению переменной или функции) реализовано при помощи ctags. А с учетом того, что на это есть хоткеи навигация вообще представляется весьма удобной (тыкаться мышкой в msvs ад и израиль!)
Я не агитирую всех пересесть на vim (или emacs), но заявлять о том что ИДЕ нужна ради этих уберфитч как минимум некорректно.
0
А, vim/emacs. Я бы сказал, эта штука по монструозности сравнима с IDE. И многими используется как IDE, да. Особенно учитывая, что в emacs (за вим не скажу) можно дописать что угодно на его лиспе. Но таких редакторов не так уж много (точнее, ты уже оба назвал), обычно по фразе «приличный редактор» вспоминается нечто вроде Notepad++.
Навигация по коду (переход к объявлению переменной или функции) реализовано при помощи ctags.
ctags АФАЙК так себе навигатор. В хороших IDE получше.
но заявлять о том что ИДЕ нужна ради этих уберфитч как минимум некорректн
Для того, кто емаксом не пользуется — вполне корректно. Для того, кто пользуется — а зачем вам вообще какие-то другие инструменты?
0
> монструозности сравнима с IDE
да ладно, просто консольный редактор. Кстати kate из KDE может почти тоже самое (даже vi-интерфейс).
> Notepad++
не работал плотно с ним, не могу сказать ничего.
> ctags АФАЙК так себе навигатор. В хороших IDE получше.
где и как вы его использовали?
тут я бы очень осторожно походил к оценкам. Начнем с того, что ctags не навигатор, а построитель индекса всех вхождений всех имен в исходниках на которые его натравили. Имеет кучу ключей для выбора того, что и как в этот индекс включать. Так же должна быть поддержка от редактора на эффективное использование этого индекса.
> за вим не скажу
для вима тоже можно много всякого написать. А с учетом его интеграции с любой консольной утилитой по обработке текста (grep, sed, awk, regexp) можно делать очень интересные вещи.

чем мне не нравятся монструозные ИДЕ:
1. очень убогий редактор, причем встроенный и прибитый гвоздями
2. странное распределение настроек между ИДЕ и проектом (я щас про MSVS). Иногда настройки среды влияют на сборку проекта.
3. просто монструозная, не очевидная, непрозрачная схема настройки сборки проекта.
И это только то, с чем сам столкнулся в процессе вынужденной работы в MSVS.

Да многие голосуют за продвинутый интегрированный отладчик (хотя меня и gdb вполне устраивает, и это при том что я там и 10% возможности не использую). Кто-то более продвинутый хвастается рефакторингом. Хотя тоже слабый аргумент, это же как надо архитектурить проект, что бы потом регулярно его рефакторить при помощи спец.инструмента.
-1
Кто-то может меня закидать помидорами, но по мне MSVS — первая по убогости среда разработки с ее ворохом настроек и прожорливостью. За это же терпеть не могу Eclipse. Из монструозных IDE типа двух вышеперечисленных мне всегда больше нравилась третья — Netbeans. Логики в настройках и сочетании фичи/время настройки фич в ней по мне больше чем в остальных. Вообще за свою жизнь я перепробовал много сред, редакторов и меня тут очень сложно удивить чем-то новым. Ценю простоту, лаконичность интерфейса, расширяемость и насыщенность фичами. Терпеть не могу принуждение работать мышью.
-1
Кстати kate из KDE может почти тоже самое
Пробовал, не заметил. Впрочем, KDE я пользовался 10 лет назад.
где и как вы его использовали?
Никак. ОБС.
Начнем с того, что ctags не навигатор, а построитель индекса всех вхождений всех имен в исходниках на которые его натравили.
Фактически это основа навигатора и есть. Современные продвинутые навигаторы как минимум умеют парсить все дерево инклудов с учетом активных дефайнов. Плюс умеют предлагать только то, что осмысленно в данном контексте. Насколько я знаю, для таких задач нужен достаточно серьезный парсер и помнится мне, что ctags такого не имеет. Но, конечно, могу ошибаться. И это только то, что касается дополнения.
для вима тоже можно много всякого написать
Я не работал ни с вимом, ни с емаксом, но говорят, что скриптовый язык вима достаточно ограничен, тогда как емакс сам написан на emacs lisp и в дополнениях можно делать все, что угодно.

Конкретно про MSVS — это только одна IDE. На мой дилетантский (в плане C++ IDE) взгляд — довольно неплохая, но у нее есть и еще два момента — с ней идет неплохой компилятор и под нее чаще всего встречаются файлы проектов в комплекте с сырками. Еще, в принципе, не стоит забывать, что IDE — таки интегрированная среда, а не только редактор, хотя в последнее время инновации в основном в области редактора, потому и фокус внимания сместился именно на возможности IDE как редактора.
это же как надо архитектурить проект, что бы потом регулярно его рефакторить при помощи спец.инструмента
В некоторых техниках рефакторинг — основа архитектуры. Например, про это в сообществе писал evsi. В Delphi я нередко пользуюсь рефакторинг-возможностями MMX. Удобно.
0
> Современные продвинутые навигаторы как минимум умеют парсить все дерево инклудов с учетом активных дефайнов.
ctags парсит все что ему подсунешь. Можно ему добавить то чего в текущем проекте вообще нет. Ты еще инклюд не вписал, а его содержимое уже доступно :)
> некоторых техниках рефакторинг — основа архитектуры. Например, про это в сообществе писал evsi. В Delphi я нередко пользуюсь рефакторинг-возможностями MMX. Удобно.
Я понимаю, что удобно пользоваться удобным инструментом. Хотя по мне это костыль вместо грамотного проектирования.
-1
ctags парсит все что ему подсунешь.
Вопрос в том, насколько глубоко парсит и с учетом каких моментов. Опять же, сам я с ним не работал — только слышал, что навигатор/интеллисенс на базе ctags уступает более продвинутым образцам.
Я работал с сабжем в дельфи — и был удивлен, читая обзоры и сравнения IDE для C++, что воспринимавшиеся мной как само собой разумеющееся фичи интеллисенса еще старой Delphi 7 отсутствуют во многих средах для С++, даже считающихся достаточно крутыми. Правда, это было давно и с тех пор могло многое поменяться.
Хотя по мне это костыль вместо грамотного проектирования.
Это достаточно сложный вопрос. Так что я просто сошлюсь на старый топик и срачик.
0
> Вопрос в том, насколько глубоко парсит
что значит глубоко? по вложенности каталогов с исходниками? или что?
> Это достаточно сложный вопрос. Так что я просто сошлюсь на старый топик и срачик.
Евси я конечно уважаю как профи (хотя конечно и есть к нему вопрос по его майданопозиции и демарша что либо тут писать пока крым не вернут). Он там конечно хорошо по водопаду прошелся и за agile митингнул, но это только часть картинки мира. Есть заказчики и ТЗ где изначально известно что надо когда и как. А тогда все эти гибкие практики уже нафиг не нужны.
Вот неплохая книжонка про еще один подход к разработке:
«IT-проекты. Фронтовые очерки» Джо Мараско.
-1
что значит глубоко? по вложенности каталогов с исходниками? или что?
По глубине разбора. Можно просто найти все объявления переменных и составить их список, а можно разобрать код по косточкам и извлечь дополнительную информацию — например, области видимости переменных (некоторые автодополняторы на полном серьезе предлагают в одной функции локальную переменную из другой).
Есть заказчики и ТЗ где изначально известно что надо когда и как.
Разумеется, бывают разные задачи и для них нужны разные инструменты. Но речь-то шла о
это же как надо архитектурить проект, что бы потом регулярно его рефакторить при помощи спец.инструмента
И я склонен полагать, что проекты, где ТЗ прописано во всех деталях, а архитектура проработана до последней функции далеко не большинство.
+1
> По глубине разбора
теперь ясно. ну тут только лексический анализатор поможет.
> далеко не большинство.
ну если брать весь спектр программной разработки, то конечно в большинстве это будут всякие сайтики на «рельсах» и игрульки для мобил. Тут понятно, что заказчик хочет чтобы бабло шло, а как его не волнует.
Но мы то тут за ембедед разговаривем. А он как правило жестко привязан к требуемому функционалу и аппаратным средствам. И делать крестики-нолики в gps-логере с одной кнопкой и одной лампочкой вряд ли понадобится.
-1
теперь ясно. ну тут только лексический анализатор поможет.
Дельфи так и делает — использует для всей кодонавигации движок компилятора. И кодонавигация там хорошая. Правда, глючноватая.
Но мы то тут за ембедед разговаривем. А он как правило жестко привязан к требуемому функционалу и аппаратным средствам.
Даже в эмбеддеде средствам рефакторинга есть место. Тем более, что это часто довольно простые, но за счет этого часто востребованные средства — типа перекинуть магическое число в константы, вырезать кусок функции в отдельную функцию, etc.
Ну и в том же топике evsi приводил книжку TDD in Embedded C)
0
> типа перекинуть магическое число в константы
ШТА! сразу вопрос, а как она вообще в коде появилась?
> вырезать кусок функции в отдельную функцию,
для этого нужен специальный инструмент для рефакторинга? копипаста не справится?

Я не против рефакторинга в принципе. И с удовольствием бы им попользовался. Но вот как-то не требовалось.
0
ШТА! сразу вопрос, а как она вообще в коде появилась?
Мало ли. Всякое бывает. Может это вообще был по быстрому накиданный экспериментальный код, который оказался удачным и теперь причесывается под стандарты.
копипаста не справится?
Специальный инструмент удобнее и безопаснее.
Но вот как-то не требовалось.
Обычно человек не испытывает потребности в том, что не пробовал. Зато попробовав — хорошо так подсаживается. Чем-то похоже на «парадокс блаба».
P.S. Используй кнопочку «цитата», хорошо оформленное сообщение читать удобнее.
0
Обычно человек не испытывает потребности в том, что не пробовал. Зато попробовав — хорошо так подсаживается. Чем-то похоже на «парадокс блаба».
Ну это уж совсем упрощение ситуации. Несколько раз мне требовалось нечто подобное сделать. Просто это делалось при помощи других средств намного более гибких и мощных (grep/sed/regexp)
0
Гибкий инструмент часто менее удобен в конкретной ситуации. Именно поэтому существуют специализированные инструменты.
+1
Полностью поддерживаю. Конечно, нверное можно используя связку из grep+sed+regexp+…+…+ написать, например, продвинутую тулзу для рефакторинка, которая будет отличать контекст использования выражения в конкретном ЯП. Но это офигеть какая нетривиальная задача. А в большинстве современых IDE подобные вещи являются обыденными…
0
Да не очень уж и нетривиальная задача(text processing в Linux'e — это вообще песня, можно практически всегда красиво и элегантно выполнить) скорее выбора правильного набора тулзов и точности постановки задачи. Но вопрос: зачем? Большинство необходимого уже реализовано до тебя, доработки обычно требуется немного при грамотном выборе инструмента, а еще таскать за собой ворох своих костылей, которые могут похериться после переустановки, не везде будут работать и еще тысяча вопросов из серии сопровождение/универсальность.
Поэтому соглашусь с вами, Товарищ e_mc2, писать костыли самому, когда есть готовое, можно(ИМХО конечно) либо по глупости, либо с целью научиться чему-то и прокачать навыки.
0
Только про автодополнение в точку. И оно тут неплохо сделано, с поддержкой дополнения имен header'ов.
Source navigator здесь — это отображение блоков кода в файле(особенно понравился для xml-файлов). Фишка так себе, но полезна при навигации по большим файлам.
Symbol browser — все проиндексированные элементы кода и библиотек в проекте с поиском. Удобно когда не знаешь точно название функции/typedef'a/переменной, а только часть имени. Еще полезно просто посмотреть, что может быть использовано в проекте, что используется и вообще. Must have фича.

Еще есть своего рода дизассемблер и редактор ресурсов. Полезно глянуть из чего готовый elf/hex состоит.
Профилировщик тоже имеется.
0
Перепута Navigator/Browser. Все наоборот для них.
0
Source navigator здесь — это отображение блоков кода в файле(особенно понравился для xml-файлов). Фишка так себе, но полезна при навигации по большим файлам.
code folding чтоль?
Symbol browser — все проиндексированные элементы кода и библиотек в проекте с поиском.
Это, в принципе, и есть кодонавигатор.
0
Не, code folding — это просто сворачивание блоков кода в редакторе(его, кстати нету, жаль).
Блин, вообще, кажется, проще просто поставить и попробовать самому, чем пытаться это описать)
0
А что в таком случае ты имеешь в виду? Можно проиллюстрировать скрином.
0
Code outline — это слева вверху.
Source navigator — справа.(Включен фильтр по GPIO)
Вообще, пример сборки двух проектов с нуля(полная сборка clean/build 2.8сек) за счет 16 параллельных потоков сборки(большинство сред собирает по одному потоку, что прискорбно).
Картинко
0
> за счет 16 параллельных потоков сборки
у вас 16 ядер на рабочей машине?
> большинство сред собирает по одному потоку, что прискорбно
если это так, я щас разрыдаюсь.
15 лет назад, в те времена когда сеть уже была, а вычислительная мощь была еще маленькая, мы мало того что многопоточно собирали, так еще одновременно на всех доступных в сети машинах (distcc). Ядро linux собиралось за 10-15 минут (при нескольких часах если на одном 486).
0
(при нескольких часах если на одном 486)
Больно быстро. Оно на гигагерцовом атлоне около часа собиралось, ЕМНИП. А 486 не только на порядок меньшую частоту имеет, но и меньшую производительность на такт. Хотя, если сборка упирается в IO, то возможно…
Алсо, 486 это все же более 20 лет назад, пожалуй.
0
> Больно быстро. Оно на гигагерцовом атлоне около часа собиралось, ЕМНИП.
ядра тогда были поменьше, плюс еще не собиралось все ядро, а только то, что реально было нужно.
в общем это была иллюстрация того, что многопоточная сборка была уже тогда и тогда же уже была распределенная на нескольких машинах сборка.
0
Разницу между потоками/процессами, ядрами/виртуальными ядрами Intel'а думаю обьяснять не надо.
Вообще не скажу точно, как ребятам из Segger'a удалось добиться такой быстрой сборки точно, но вообще сборка под виндами — это всегда тугой процесс по времени. Дело обычно даже не в однопоточности/многопоточности, а скорее в высоких накладных расходах на создание процесса/потока в виндах + накладки на disk IO. Для сравнение, сборка одинаковых проектов под Unix и Windows будет зачастую быстрее проходить под Unix.
Хотя кто его знает? Может я просто пересел на более быстрый ноутбук с ССД :)
0
> Разницу между потоками/процессами, ядрами/виртуальными ядрами Intel'а думаю обьяснять не надо.
нет конечно. Просто я на своих 8 ядрах, тоже могу запустить 16-поточную сборку, но в реальности оно соберется не быстрее чем запустить ее на 8 потоков.
> Вообще не скажу точно, как ребятам из Segger'a удалось добиться такой быстрой сборки точно,
С одной стороны чудес не бывает, нельзя одновременно исполнять потоков больше чем физических ядер.
С другой стороны заметил, что пользователи интегрированных сред слабо себе представляют из чего состоит процесс сборки проекта.

Реальная быстрота недоступная никакому SSD наступает тогда когда /tmp размещаешь в ramfs. Компилятор все промежуточные файлы складывает туда. Так что много ядер, быстрый диск и размещение временных файлов в оперативке = залог быстрой сборки. Но чтобы этим всем воспользоваться, система сборки должна уметь запускать несколько экземпляров компилятора.
0
Просто я на своих 8 ядрах, тоже могу запустить 16-поточную сборку, но в реальности оно соберется не быстрее чем запустить ее на 8 потоков.
Бывают нюансы, вроде. x264 по дефолту запускает N + N/2 потоков. Видимо, какой-то смысл в том есть.
0
> Видимо, какой-то смысл в том есть.
Ядро ОС и прочие служебные штуки так же нуждаются в процессорном времени. А для кинчика важно чтобы не тормозило когда приходит уведомление в мессенджер.
0
Это не кинчик, это видеокодер. Когда он работает — все остальное тормозит.
0
он только в одну сторону работает? :)
> Бывают нюансы,
но мы тут вроде про компиляцию больше.
Понятно, что эти нюансы зависят от соотношения времени загрузки «исходников» и времени их обработки CPU.
0
он только в одну сторону работает? :)
Да. x264 умеет только кодировать. И даже если бы это было не так — комментарий касательно количества потоков относился именно к кодированию. И это — именно потоки кодирования, без учета вспомогательных.
но мы тут вроде про компиляцию больше.
У меня нет конкретней информации из вопроса именно многопоточной компиляции, и у тебя, полагаю, тоже. Только привожу пример, что не всегда ограничение числа идентичных потоков числом аппаратных потоков оптимально.
0
> что не всегда ограничение числа идентичных потоков числом аппаратных потоков оптимально.
с этим как раз никто не спорит. претензия была к заявлению ТС о 16 потоках и моем сомнении, что у него вдруг оказался комп с парой ксеонов.
Кстати, видел тут как собирается проект для FPGA, так там при наличии 8 ядер (4 из них HT) в реальности использовались только 4 ядра. Так что для некоторых видов работы HT бесполезен.
0
претензия была к заявлению ТС о 16 потоках и моем сомнении, что у него вдруг оказался комп с парой ксеонов.
Я как раз к тому, что 16 потоков компиляции на 8 ядрах может быть оправдано. А может и нет. Не знаю.
На мой вкус 3 секунды на сборку — это вообще ужас, я привык к дельфи, собирающей за секунду проект на полсотни килострок (с нуля и в одном потоке), не говоря уже о том, что пересборка при небольших изменениях просто мгновенна. Но, к сожалению, для С/С++ это суровая правда жизни.
-1
А может и нет. Не знаю.
никакого логичного объяснения этому быть не может. я скорей предположу что тут 16 потоков было для красного словца.
0
А у тебя есть логичное объяснение, почему x264 кодирует в 6 потоков на четырехядернике?
0
А у тебя есть логичное объяснение, почему x264 кодирует в 6 потоков на четырехядернике?
Я думаю это ошибка. Если потоков больше чем ядер, то значит часть потоков всегда будет спать. Возможно там такая схема, что для кодирования каждого фрейма создается свой поток и происходит активное создание/удаление потоков. А операция «создания» потока дороже переключения. Поэтому потоки делаются с избытком, чтобы когда нужно создавать очередной поток не ждать его, а просто переключиться на уже созданный.
0
x264 достаточно давно разрабатывается и его дефолты достаточно осмысленны, а не взяты с потолка. И потоки оно не пересоздает.
Если потоков больше чем ядер, то значит часть потоков всегда будет спать.
Нет. Это значит, что потоки будут переключаться, что теоретически может быть менее производительно, чем создать потоков по числу процессоров и дать каждому выполняться на своем ядре без переключений. Когда потоком много и переключения происходят часто, то действительно, оверхед от переключений становится заметен. Поэтому, например, серверы не создают по потоку на подключение.
В случае компиляции, возможно, есть смысл запустить больше потоков, чем ядер. Скажем, пока один поток будет ждать выполнения операции асинхронного IO, другой поток будет обсчитываться. С другой стороны, если производительность упирается в диск, то даже при наличии 16 ядер 16 потоков могут работать в разы медленнее, чем один.
0
Здравая мысль насчет цены создания/переключения и количества. Когда есть «задание» на обработку, время не тратится на его создание.
0
А у тебя есть логичное объяснение,
Могу предположить, что в потоках есть какие-либо блокирующие вызовы (например чтение/запрись на диск). Если сделать количество потоков равное количеству ядер, то процессор бы во время блокировок потока простаивал…
+1
Или взаимозависимость потоков. Но все это может быть и у компилятора — уж с диском он точно работает, причем каждый процесс отдельно (а вот потоки кодера вполне могут централизованно кормиться данными — тем паче, что они идут с декодера, а не прямо с диска).
+1
Но все это может быть и у компилятора — уж с диском он точно работает
Безусловно. Более того, по поим наблюдением, именно диск является «бутылочным горлышком» при компиляции. Ибо переход на ССД дает просто дикий прирост производительности при сборке большого проекта.
0
А когда уже перейдешь на ССД, начинаешь смотреть, что бы еще могло вызвать прирост и вот тогда уже…
Короче вот про этот мой случай я пытался поведать.
0
Предлагаю вместо долгого обсуждения поставить и самому попробовать. Сборка в один поток и сборка в 16. Галка выставляется в настройках Project Explorer'a.
0
Сборка в один поток и сборка в 16. Галка выставляется в настройках Project Explorer'a.
то есть на выбор только 2 варианта — 1 или 16 потоков? фееричненько :)
Пробовать это я конечно не буду.
-1
Да нет, почему? Можно от 1 до 16, произвольно.
Никто не заставляет.
Доказывать что-то мне тоже лень. Свои беглые предположения я высказал. С учетом сложности всего процесса работы софта в сочетании с железом я легко могу позволить себе ошибаться. Я обратил внимание на странную быстроту сборки без доп костылей, которые есть всегда у других производителей. Что делать с этим — ваше дело, а так мне плевать)
0
«Не смотрел, но осуждаю», чес слово…
+1
Сборка в один поток и сборка в 16. Галка выставляется в настройках Project Explorer'a.
Из вашего поста я понял, что там всего два варианта. Написали бы что там окошко в которое можно ввести целое число, или что там спинбокс. Было бы понятней.
Ну и я никого и ничего не осуждаю. Просто очень мне любопытно понять за что любят IDE.
Я обратил внимание на странную быстроту сборки без доп костылей, которые есть всегда у других производителей. Что делать с этим — ваше дело, а так мне плевать)
Многопоточная сборка в моем мире, умолчательная функция уже много лет (больше 20). Поэтому, мне и удивительно было узнать, что где-то это не так.
-1
Просто очень мне любопытно понять за что любят IDE.
 

За удобство работы с кодом, интеграцию с отладчиком и прочими вещами типа системы контроля версий, таск трекерами и т. д.

А вот система сборки в IDE зачастую достаточно примитивная и часто используют внешнюю.

ИМХО единственный минус большинства современных IDE – прожорливаость по ресурсам.
+1
ИМХО единственный минус большинства современных IDE – прожорливаость по ресурсам.
А интересно, CLion кто-то из местных уже заценил?
0
Я ее пробовал (правда давно, практически сразу как только она появилась). Было несколько фичей которые мне понравились, но в целом я для себя не нашел причин, ради чего стоило бы не нее переходить…
0
Было несколько фичей которые мне понравились
Например? И с чем сравнивал?
0
Из того что помню — понравилась адекватность навигации по коду, типа find all usages/go to definition(в нетривиальных случаях типа наследование и темплейты). Сравнивал с актуальными на тот момент версиями VS (без ReSharper C++ ) и Eclipse
0
Давно уже, полгода если не больше(точно не скажу) и признаться ничего кроме неплохого парсера ресурсов там не нашел. Бывали и получше среды.
0
ничего кроме неплохого парсера ресурсов там не нашел
Оно вроде как в первую очередь этим и пиарится.

А как оно жрет? Чет пугали тем, что на 32-битной системе смысла запускать нет, памяти не хватит.
0
От «толщины» проекта, думаю, зависит. Но Java, это да. Меньше 256, думаю оно не способоно в принципе отожрать. Но я вообще не часто об этом в последнее время задумываюсь. Core i7 + 8GB RAM… Пока хватало на все что угодно.
Только что тестовый проектик загрузил. OMG! Working set — 1.115 MB RAM… Java Такая Java…
0
Гиг — это фигня. Говорят, на приличном проекте оно спокойно жрет 6+ ГБ. Девелы говорят (в каментах на хабре), что по этой причине они и не делают х32-версии, все равно неюзабельна будет (там всего-то 2 гига можно выделить, на самом деле даже меньше).
0
Мда уж… Хотя интерфейс неплохой.
0
на приличном проекте оно спокойно жрет 6+ ГБ

Ну, VS тоже может отожрать 6+ Гб и не поперхнуться (не смотря на то что 32х битная, просто она стартует много процессов и это не так бросается в глаза).
0
OMG! Working set — 1.115 MB RAM… Java Такая Java…
При чем тут Java?
0
CLion неплохо развивается. Недавно прикрутили удалённую отладку. :D
Ещё бы они как-то кооперировались с разработчиками Resharper C++, а то фичи не пересекаются. Что-то есть там, чего нет в другом и наоборот.
0
За удобство работы с кодом, интеграцию с отладчиком и прочими вещами типа системы контроля версий, таск трекерами и т. д.
Самое главное — навигация по коду. Как только код вырастает за пределы пары файлов, без навигации по коду IDE бесполезна.
+1
У Дельфы механизм сборки совершенно другой. А вот сишники вынуждены всегда страдать. Есть костыли типа частичной сборки(incremental build).
0
Ага, я знаю. Алсо веселюсь, когда некоторые упертые личности пытаются доказать превосходство механизма С :)
Есть костыли типа частичной сборки(incremental build).
К этой проблеме костылем является скорее PCH.
0
А как оно выглядит, когда загружен сырок на С/С++?
0
Пожалуйста
0
Довольно забавно, как я понимаю — это структура кода в виде дерева?
Вообще IDE-шка выглядит любопытно.
0
это структура кода в виде дерева?
Да, для отдельно взятого открытого файла. Переменные там, функции всякие…
0
Если среда бесплатна, то за что они тут пытаются денег взять?
0
  • avatar
  • Aneg
  • 10 ноября 2016, 18:09
За коммерческое использование + за то что в разделе Description.
Никто не запрещает для своих поделок использовать полноценную среду.
0
>>>могу как нибудь рассказать про работу в среде с STM32, STMCubeMX, импорт проектов и отладку jLink'ом.
Рассказывайте! Обязательно, а то в последнее время здесь свежих статей стало мало.
+1
Забавную хрень заметил давеча: сборка в SES компилятором Keil производится быстрей чем в uVision среде ее же Keil компилятором…
Почему-то уверен, что ставить для проверки аналогичной ситуации с IAR не имеет смысла.
Это к диалогам по поводу многопоточности/многопроцессности выше.
PS: Keil uVision вообще умеет в многопоточную компиляцию???
0
>>Keil uVision вообще умеет в многопоточную компиляцию???
Нет, лет пять назад это было в проекте, пока не допилили.
0
Похоже на очередной клон Code::Blocks с элементами анального огораживания.
Смотрите сразу на EmBitz. В ней всё то же самое, но умеет и в ST-Link, и в J-Link, и в безгранично могучий OpenOCD. И никаких ограничений.
0
Это экс-Em::Blocks чтоль?
0
Он самый, да.
0
Вот только он совершено бесполезен, поскольку не живет за пределами винды. И пофиг, что никаких ограничений, если оно не живое.
0
Вот только он совершено бесполезен
… для воинствующих линуксоидов
0
… для воинствующих линуксоидов
Не знал, что называть вещи своими именами это, оказывается, воинственно…
0
называть вещи своими именами
… и со своей колокольни.
0
… и со своей колокольни.
Фраза «совершенно бесполезен за пределами винды» не зависит от колокольни. Это просто констатация факта.
0
Исходная фраза была «совершенно бесполезен», без уточнения. А с этой я спорить не буду, разумеется.
0
Сторонники могут со мной спорить, но я все равно пойду искать что-нибудь быстрое, написанное на C/C++, прости господи, С#.

Вам тогда qtcreator надо, рекомендую. Летает везде, отладку и прошивку из среды поддерживает. Из минусов — проект при переносе частично надо настраивать заново (чтоб всё из среды работало).
0
Да, им я пользовался даже какое-то долгое время(в течение пары лет это был один из основных моих редакторов/IDE). Но признаться честно, для embedded-разработки он мне не очень понравился. А так да, один из лучших С/С++ редакторов кода :)
0
Чушь в виде «что-нибудь быстрое, написанное на C/C++, прости господи, С#» отбила желание читать дальше.
0
  • avatar
  • evsi
  • 21 декабря 2016, 14:14
Я больше скажу: читать — вредно. Зрение садится, жопный мозоль натирается. Проще попробовать. Помнится мне, ты вроде на X-серверах обитаешь. Оно умеет в линуксы. Но плюсы скорости сборки на иксах не так очевидны как на винде. Еще раз повторюсь: не знаю как, но хитрожопые люди из Segger заставили проекты собираться чужими компиляторами быстрее в их среде, чем в средах производителей компиляторов. Уже только поэтому на эту хрень имеет смысл обратить внимание.
И к посту выше: да, у меня аллергия на Java. Моя личная половая драма.
0
Я больше скажу: читать — вредно.
Ну так не читайте, зачем вы мне-то жалуетесь?
Уже только поэтому на эту хрень имеет смысл обратить внимание.
Пропоненты этой хрени чересчур агрессивно ее проталкивают, что бы обращать на них (и на хрень) внимание. Разве что поржать с них.
И к посту выше: да, у меня аллергия на Java. Моя личная половая драма.
И, судя по вашей реакции, делитесь вы ею публично потому, что уверены в важности своей драмы для окружающих. Могу вас разочаровать, на вашу драму окружающим начхать.

P.S. даже на вычислительных задачах С/С++ выигрывают у жабы всего несколько процентов, С# +- такой же или чуть медленнее обоих. интерактивному софту все эти единицы процентов похрену, он и так 99% времени юзера ждет. впрочем, для того, что бы понимать, что вовсе не язык, на котором написано интерактивное приложение, определяет скорость работы самого приложения, надо читать и дамать, а у вас «зрение садится» и «жопный мозоль натирается».
0
Я не знаю как у меня так иногда получается на ровном месте парой фраз обидеть человека. Не хотел ничем задеть. Прости, что так получилось.
И раз уж пришлось извиняться, то необходимо провести работу над ошибками.
Читать вредно <поверхностные бесполезные статейки вроде этой> // а не нормальные труды вроде Таненбаума, Вирта, Кнутта, Гради и Буч«а, Дейкстры, Хоровица и Хилла и еще много кого…
Если уж натирать мозоль, то не впустую :)
»Черезчур агрессивно проталкивают" — ок, завязываю. Каждый пишет код так как хочет.
Жаль статья вышла дерьмовая и толком ни одного дельного вопроса я так и не увидел в комментах. Либо никто не ставил и не пользовался, либо поставили и так все ясно, либо поставили и снесли. В любом случае продолжение нафиг не нужно.
Последнее, что хотел отметить — это про Java vs C/C++. Не хочу холиворить(а тут даже простое упоминания рядом двух языков уже подбивает) — вот просто сразу сливаюсь и не буду продолжать, но синтетические тесты на математику для сравнения скорости выполнения — чушь собачья в лабораторных условиях. Надеюсь, не надо обьяснять почему. И если выбирать инструмент для написания программ, то у меня в приоритете будут С/С++ и Python в противовес Java. Python хотя бы потому, что он в отличие от не лезет в GUI, где ему не место ввиду генетических особенностей(а если и лезет — PyQt/Wx, то от него и его GC не ждут многого — и он приятно удивляет, а не огорчает как javac). В вопросах IDE это очень важный момент, кстати.
Еще раз прошу прощение.
0
Я не знаю как у меня так иногда получается на ровном месте парой фраз обидеть человека. Не хотел ничем задеть. Прости, что так получилось.
Человеческая глупость меня давно не обижает. Даже не раздражает. Разве что становится предметом насмешек с моей стороны, но и только.
но синтетические тесты на математику для сравнения скорости выполнения — чушь собачья в лабораторных условиях. Надеюсь, не надо обьяснять почему.
Да, эти тесты имеют свою специфику, которая отдает предпочтение низкоуровневым языкам. Скажем, большинство тестов проходит всего несколько секунд (многие меньше секунды), что не дает возможности JVM провести эффективную оптимизацию (которая базируется на статистике, а для ее сбора требуется время). Даже в этих условиях жаба показывает весьма хорошие результаты. В более сложных приложениях, особенно работающих дольше нескольких секунд, результаты будут заметно отличаться в лучшую для жабы сторону. Впрочем, для того, что бы понимать, почему так, надо знать потроха, а это явно не ващ случай.
Python хотя бы потому, что он в отличие от не лезет в GUI, где ему не место ввиду генетических особенностей
Во-первых, вы еще раз продемонстрировали, что у вас «аллергия» на то, чего вы не знаете (сюрприз, жаба в гуе вполне хорошо вписывается, причем по производительности особенно легко). Во-вторых, вы, похоже, совсем плохо представляете на что идут затраты вычислительных ресурсов в гуйне (и почему это не имеет никакого значения для IDE). В-третих, питон для сколько-нибудь сложных программ не годится (вот тут, как раз, именно из-за «генетических особенностей»).

P.S. хотя бы иногда стоит задумываться о таких элементарных вещах, которые вас окружают в повседневной жизни как то, что все телефоны на андроиде имеют гуй написанный на жабе. к тому же на отнюдь не самой быстрой и эффективной VM (поскольку она создавалась для совершенно других целей — оптимальное расходование сильно ограниченных ресурсов). и, что совсем уже удивительно, все это совершенно не тормозит. неужели ни разу не пришла в голову мысль, чем был обоснован выбор именно жабы? а мысль о том, что выйдя на рынок заметно позже всех главных конкурентов (айфон и винда для мобилок), андроид легко всех их нагнул по распространенности и количеству приложений за счет грамотной политики и удобного инструментария для разработки (в том числе — языка) вам тоже в голову не приходила? замечу, все эти приложения это на 90% гуйня.
P.P.S. всегда забавно смотреть на людей, которые думают, что разбираются в программировании и выдают оценки вроде ваших. даже на ностальгию как-то пробивает, вспоминаются старые баталии асм против всех-всех-всех. ту историю (почему-то) вспоминают редко, хотя она весьма показательна в плане того, что эффективность низкоуровневого кода давно мало кого волнует (в отличие от производительности самих программистов и удобства/эффективности написания/сопровождения). впрочем, вам еще предстоит пройти этот путь, на этот раз в варианте «С/С++ против всех-всех-всех».
0
Quora прямо мысли читает:

For other stuff, like a web server that handles only a few thousand users, or a user interface, go with Java.


Автор, правда, спорол чушь насчет «few thousand users» (на жабе не сложно сделать сервер под любую нагрузку, от одного, до многих миллионов активных юзеров), но, тем не менее, советует использовать именно жабу (а не плюсы) для гуйни.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.