Есть пиар, чтобы добавить меню оптимизации

https: // github.com/rogerclarkmelbourne/ ... 2/тяга/313

эн.глин. это добавляет это к каждой доске
mapleMini.menu.opt.o2std=Faster mapleMini.menu.opt.o2std.build.flags.optimize=-O2 mapleMini.menu.opt.o2std.build.flags.ldspecs= mapleMini.menu.opt.o2lto=Faster with LTO mapleMini.menu.opt.o2lto.build.flags.optimize=-O2 -flto mapleMini.menu.opt.o2lto.build.flags.ldspecs=-flto mapleMini.menu.opt.o1std=Fast mapleMini.menu.opt.o1std.build.flags.optimize=-O1 mapleMini.menu.opt.o1std.build.flags.ldspecs= mapleMini.menu.opt.o1lto=Fast with LTO mapleMini.menu.opt.o1lto.build.flags.optimize=-O1 -flto mapleMini.menu.opt.o1lto.build.flags.ldspecs=-flto mapleMini.menu.opt.o3std=Fastest mapleMini.menu.opt.o3std.build.flags.optimize=-O3 mapleMini.menu.opt.o3std.build.flags.ldspecs= mapleMini.menu.opt.o3lto=Fastest with LTO mapleMini.menu.opt.o3lto.build.flags.optimize=-O3 -flto mapleMini.menu.opt.o3lto.build.flags.ldspecs=-flto mapleMini.menu.opt.ogstd=Debug mapleMini.menu.opt.ogstd.build.flags.optimize=-Og mapleMini.menu.opt.ogstd.build.flags.ldspecs= mapleMini.menu.opt.oglto=Debug with LTO mapleMini.menu.opt.oglto.build.flags.optimize=-Og -flto mapleMini.menu.opt.oglto.build.flags.ldspecs=-flto mapleMini.menu.opt.osstd=Smallest Code mapleMini.menu.opt.osstd.build.flags.optimize=-Os mapleMini.menu.opt.osstd.build.flags.ldspecs= mapleMini.menu.opt.oslto=Smallest Code with LTO mapleMini.menu.opt.oslto.build.flags.optimize=-Os -flto mapleMini.menu.opt.oslto.build.flags.ldspecs=-flto

Я думаю, что это вздутие не решит никакой проблемы.

Если -fflto, как правило, улучшает размер кода, не влияя на скорость выполнения, то я думаю, что было бы разумно интегрировать его на платформу.TXT (при условии, что больше ничего не сломается).
Если скорость выполнения страдает, то я не приветствую это. Причина, по которой многие люди используют этот чип, заключается в его скорости, которая должна быть сохранена.
И в большинстве пользовательских приложений достаточно места для большинства пользовательских приложений, максимум 5% сэкономил не слишком много, за исключением некоторого времени сэкономить во время загрузки.

Что касается оптимизации скорости, я думаю, что -OS дает общую хорошую производительность для большинства приложений, если у них нет особых случаев (LiveOV7670).
При необходимости, скорость может быть в конечном итоге увеличена, используя специальный стиль кодирования, который затем принесет такое же преимущество, что и -O2 или 3, сохраняя общую настройку -OS на месте.
Альтернативным решением является локальное изменение уровня оптимизации: #pragma GCC push_options #pragma GCC optimize ("O0") your code #pragma GCC pop_options

Спасибо, Стив

Я думаю, -O2 может быть быстрее -os, так как это работает для LiveOV7670, но я уже писал об использовании -O2, и об этом мы должны оставаться с -ОС

https: // gcc.гну.org/onlinedocs/gcc/func ... Агма.HTML #pragma GCC optimize ("string"...) This pragma allows you to set global optimization options for functions defined later in the source file. One or more strings can be specified. Each function that is defined after this point is as if attribute((optimize("STRING"))) was specified for that function. The parenthesis around the options is optional. See Function Attributes, for more information about the optimize attribute and the attribute syntax.

#pragma gcc оптимизация выглядит действительно интересно

У нас уже есть хотя бы один пример, который нуждается в -O2, который на данный момент требует изменений в платформе.текст

Профессионал с системой меню заключается в том, что если кто -то откроет демонстрацию «OV7670 Live», которая нуждается в -O2, он не будет автоматически выбирать -O2, но прагма исправят эту ситуацию

К сожалению, просмотр справочной страницы GCC

https: // gcc.гну.org/onlinedocs/gcc/func ... Агма.HTML

Это говорит
Целевая прагма #Pragma GCC в настоящее время реализована только для целей X86, PowerPC и NIOS II. что подразумевает, что он недоступен для рук

Я проверил, что #Pragma на кодировании LiveOV7670, который работает только правильно с оптимизацией -O2, и, похоже, не работает.

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

Так что на данный момент использование #pragma gcc не вариант..

Вернуться к исходной цели этой ветки

Я попробовал пиар, и мне на самом деле очень нравится... Однако это понадобятся некоторые изменения

Я запустил графический тест, который рисует линии, заполняет, текст и т. Д. На дисплее ILI9341 и сравнил нашу текущую оптимизацию -OS (это обычно означает оптимизацию для размера, на уровне оптимизации -O2)

-Код ОС и размеры оперативной памяти были
Sketch использует 30292 байта (46%) пространства для хранения программ. Максимум составляет 65536 байтов.
Глобальные переменные используют 3728 байтов (18%) динамической памяти

-O3 & LTO -код и размеры оперативной памяти, где
Sketch использует 32720 байт (49%) пространства для хранения программ. Максимум составляет 65536 байтов.
Глобальные переменные используют 3704 байта (18%) динамической памяти

Что ожидается, поскольку размер кода увеличился на 2K (около 8%)

Тест на скорость также был интересным и делает то, что можно было бы ожидать, с заметными достижениями в некоторых местах

Операция	-ОС ОПТИМИЗАЦИЯ	-O3 & Оптимизация LTO	__Улучшение %
Screenfill	170789	170739	0.02927589
Текст	39905	31275	21.62636261
Линии	228371	169259	25.88419721
Horiz/Vertlines	15736	15031	4.480172852
Прямоугольники (схема)	11469	10496	8.483738774
Прямоугольники (заполненные)	355032	354789	0.068444535
Круги (заполненные)	140210	106118	24.31495614
Круги (схема)	154955	120331	22.34455164
Треугольники (схема)	57983	40706	29.79666454
Треугольники (заполненные)	164206	146417	10.83334348
Округлые прямы (схема)	54528	42923	21.28264378
Округлые прямы (заполненные)	414590	403744	2.616078535

Текст, линии, круги и округлые прямы очень быстрее, что «треугольники (контур)» почти на 30% быстрее

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

Единственная проблема, которую я вижу с этим PR, заключается в том, что она изменяет оптимизацию по умолчанию на «быстрее», который

.меню.Опт.O2std = быстрее
.меню.Опт.O2STD.строить.флаги.Оптимизировать = -O2


Я хотел бы добавить это, но чтобы остановить его потенциально нарушение существующего кода, оптимизация должна быть установлена ​​на -os по умолчанию.

Я думаю, что было бы также лучше, если бы количество оптимизации увеличилось в более низких вариантах меню

Так что, наверное, пойдет.

Наименьший
Наименьший + LTO
Быстрый
Быстро+lto
Быстрее
Быстрее+lto
Самый быстрый
Самый быстрый+LTO

А потом отлаживайте как последний вариант, поскольку я не совсем уверен, кто будет использовать это, или мы должны включить его вообще, поскольку IDE не имеет никаких возможностей отладки, и эта опция будет полезна только для людей, использующих репо в другом IDE, который может вообще не поддерживать варианты меню.

К сожалению, у меня нет времени, на данный момент пройти и изменить порядок всех этих записей на доске.текст

https: // github.com/mtiutiu/arduino_stm3 ... доски.текст

Я посмотрю, готов ли ОП изменить это, или, возможно, кто -то еще со временем на руках может сделать это?

Пса. Я предполагаю, что это можно сделать, взяв один раздел в отдельное окно редактора
#-- Optimizations mapleMini.menu.opt.o2std=Faster mapleMini.menu.opt.o2std.build.flags.optimize=-O2 mapleMini.menu.opt.o2std.build.flags.ldspecs= mapleMini.menu.opt.o2lto=Faster with LTO mapleMini.menu.opt.o2lto.build.flags.optimize=-O2 -flto mapleMini.menu.opt.o2lto.build.flags.ldspecs=-flto mapleMini.menu.opt.o1std=Fast mapleMini.menu.opt.o1std.build.flags.optimize=-O1 mapleMini.menu.opt.o1std.build.flags.ldspecs= mapleMini.menu.opt.o1lto=Fast with LTO mapleMini.menu.opt.o1lto.build.flags.optimize=-O1 -flto mapleMini.menu.opt.o1lto.build.flags.ldspecs=-flto mapleMini.menu.opt.o3std=Fastest mapleMini.menu.opt.o3std.build.flags.optimize=-O3 mapleMini.menu.opt.o3std.build.flags.ldspecs= mapleMini.menu.opt.o3lto=Fastest with LTO mapleMini.menu.opt.o3lto.build.flags.optimize=-O3 -flto mapleMini.menu.opt.o3lto.build.flags.ldspecs=-flto mapleMini.menu.opt.ogstd=Debug mapleMini.menu.opt.ogstd.build.flags.optimize=-Og mapleMini.menu.opt.ogstd.build.flags.ldspecs= mapleMini.menu.opt.oglto=Debug with LTO mapleMini.menu.opt.oglto.build.flags.optimize=-Og -flto mapleMini.menu.opt.oglto.build.flags.ldspecs=-flto mapleMini.menu.opt.osstd=Smallest Code mapleMini.menu.opt.osstd.build.flags.optimize=-Os mapleMini.menu.opt.osstd.build.flags.ldspecs= mapleMini.menu.opt.oslto=Smallest Code with LTO mapleMini.menu.opt.oslto.build.flags.optimize=-Os -flto mapleMini.menu.opt.oslto.build.flags.ldspecs=-flto

Я посмотрю, смогу ли я сам сценарий самостоятельно...

Редактировать.

Я совершил изменения для F1, но у меня нет времени, чтобы сделать F3 и F4 в данный момент.

Операция -ОПИТ -ОПИТ -О3 & Оптимизация LTO __IMPROVEMENT % Это правильно? Всегда быстрее?

Наоборот

-ОС всегда медленнее в графическом тесте

@Rogerclark,

Просто к вашему сведению,

Я обновляю функцию Pulsein () для ARDUINO_CORE_STM32, чтобы иметь лучшую точность.
Я видел, что у вас жестко закодировано количество цикла на итерацию (до 16), но, поскольку это новое меню, в зависимости от выбранного оптимизации, это число не всегда одинаково, поэтому значение продолжительности неверно для всех быков.

https: // github.com/rogerclarkmelbourne/ ... F1.CPP#L42

Я пытаюсь найти общий способ вычисления этого значения (ASM, DWT_CYCCNT,...), так как мне приходится иметь дело со всеми сериями STM32.

Спасибо

Я заметил, что программное обеспечение I2C также повлияло на настройку оптимизации, но, поскольку Libmaple теперь использует аппаратный i2c для «провода», это не столько проблема, и он будет только влиять на людей, специально предпочитая использовать программное обеспечение i2c

Поскольку петли задержки в программном обеспечении I2C настолько короткие, я не думаю, что есть способ правильно работать для всех настроек оптимизации.

Вы можете попытаться добавить, что это влияющая функция:
__asm__("")

Как насчет атрибута «оптимизации», чтобы заставить функцию всегда оптимизироваться, он и тот же уровень независимо от того, что используется для остальной части кода?
Это может помочь сохранить эти петли времени, всегда приводит к тому же коду.
Фредерик, вы упоминаете DWT_CYCCNT, который несколько раз появлялся на форуме. Есть ли какой -либо вредный эффект от его использования? Я считаю, что опасения были связаны с последствиями отладки, не помню, это было потому, что это можно было остановить или сбросить во время отладки или какой другой причины.

Спасибо, Виктор, я проверю об оптимизации.
О DWT CYCCNT, я просто заявляю о расследовании, и я думаю, что не буду использовать это, как не поддерживаемая семья M0. И, вероятно, вы правы в отношении эффекта отладки.

Я действительно надеялся, что вы скажете, что это нормально использовать его

Виктор

Можете ли вы дать более подробную информацию об атрибуте "Optimize"..

Я исследовал что -то подобное, пытаясь получить оригинальный код камеры OV7670 для работы с нашими настройками оптимизации по умолчанию, я.E переключиться на -O2 для некоторого кода, но прагма для этого не поддерживается версия GCC ARM

Я попытался быстро вчера, и, кажется, работает, но я использую ARM GCC V6, я не тестирую на V4.8 #pragma GCC push_options #pragma GCC optimize ("Os") your function #pragma GCC pop_options

[victor_pv - Пн 18 сентября 2017 г. 20:36] - Я действительно надеялся, что вы скажете, что это нормально использовать его

Я попытался использовать DWT Cycnt для F103, но мне не удастся правильно написать регистр DWT CTRL. Я думаю, что это заблокировано по умолчанию (вероятно, потому что я использовал Stlink), поэтому его необходимо разблокировать.

Я нашел этот хороший пример и думаю, что в этом случае:
https: // github.com/petteriaimonen/stm32 ... ммпл.C#L35
Но я не проверил.

В заключение, добавив: uint32_t __attribute__((optimize("Os"))) pulseIn( uint32_t pin, uint32_t state, uint32_t timeout )

Это было протестировано с помощью GCC 4.х ?

Я тестировал на BP с Arduino_stm32 Repo.
Без исправления, использование O1 обеспечивает неправильное значение, в то время как при исправлении все в порядке. uint32_t __attribute__((optimize("Os"))) pulseIn( uint32_t pin, uint32_t state, uint32_t timeout )

ХОРОШО.

Это интересно.

Спасибо

Добро пожаловать, я также должен поблагодарить вас, я добавил этот пиар в arduino_core_stm32.
https: // github.com/stm32duino/arduino_c ... 2/pull/110
Очень полезно, чтобы избежать редактирования платформы.текст

Только одна информация для тех, кто использует ARM GCC 6-2017-Q1-UPDATE для использования функции LTO, необходимо использовать ARM GCC 6-2017-Q2-UPDATE
Предыдущий имеет ошибку, вызывающую ошибку сегментации во время сборки.

Не беспокойся...


Re: LTO

Я не заметил никаких проблем в GCC 4.x, кроме LTO, не всегда приводит к меньшему или более быстрому коду.

Кроме того, в Libmaple я заметил, что включение LTO показывает некоторые предупреждения во время компиляции, но они, похоже, не влияют на работу кода.

Да, на самом деле это регрессия V6. Так v4.8 не влияет.