-
- любой каприз за ваши деньги - ld(23.10.2010 05:40, )
- А зачем? В большинстве современных не ембеддеровских системах основное падение производительности происходит из-за кеш-миса. А правильно распределить память пользовательской задачи ИМХО, совсем не компилерная задача. А вот когда все кеш-мисы de3(216 знак., 19.10.2010 20:52)
- Понятно, что компилер не может думать на том же уровне абстрации, что и программист. Вопрос в удобных тулзах, чтобы прграммист как можно легче донес свое видение задачи до компилера, и тот сделал, что ему велят. Evgeny_CD(395 знак., 19.10.2010 21:01)
- Вот был когда-то креёвский компилер, в его фортране было много таких команд, они выглядели как комментарии для обычного компилера. de3(276 знак., 19.10.2010 21:32)
- Понятно, что компилер не может думать на том же уровне абстрации, что и программист. Вопрос в удобных тулзах, чтобы прграммист как можно легче донес свое видение задачи до компилера, и тот сделал, что ему велят. Evgeny_CD(395 знак., 19.10.2010 21:01)
- Тонкая оптимизация генерации кода с учетом MAM-подобных технологий. Такое есть? Evgeny_CD(867 знак., 18.10.2010 21:32, ссылка)
- Интересно насколько распространена в компилерах поддержка такой идеи. Я беру блок кода и выделяю его {}. И пишу в начале #pragma align чего-то там. И компилер с линкером выравнивают его по указанной границе. - Evgeny_CD(19.10.2010 00:19)
- Есть продукт аналогичного назначения для x86 - Intel VTune vmp(168 знак., 18.10.2010 23:53, ссылка)
- В контроллерах с многобанковой FLASH ситуауция еще интереснее. -> стр 30. Evgeny_CD(353 знак., 18.10.2010 21:38, ссылка)
- Положить всё быстрое в статическое ОЗУ и не морочить мозг. - fk0(21.10.2010 14:41)
- Порой приходиться помогать компилятору ручками этот... мерчендайзинг делать. Особливо в том же Hi-Tech C for PIC. - SERGHIO(21.10.2010 14:00)
- Никогда специально не изучал, но вот задумался. Своременные IDE (компилер и линкер) - они могут работать со структурами, у которой члены распиханы по памяти разных классов? Навеяно -> Evgeny_CD(185 знак., 18.10.2010 21:17, ссылка)
- Народ, а реально, в С, без С++, такое возможно? - Evgeny_CD(18.10.2010 22:06)
- нет - koyodza(18.10.2010 22:12)
- Так-так. Вот впервые замаячила кардинальная польза от С++. Вопрос в оверхеде при доступе к таким "продвинутым структурам"... Ну или придется некий протоязык изобретать, на нем описывать работу с такими "продвинутыми структурами" , а затем все Evgeny_CD(17 знак., 18.10.2010 22:16)
- В C можно всё то же самое, но врукопашную и очень аккуратно. Как и в ассемблере. Но не стоит дурную работу взваливать с компилятора на себя. И нет там никакого оверхеда, если не 8-битник... Ну только если кеш -- малость есть. Но маленькие объекты fk0(42 знак., 18.10.2010 23:38)
- Понятно что можно написать мегаскрипт для линкера и "запрагмить" #pragma align код. Но если делать это руками = программирование руками на асме. Кайф состоит в том, чтобы иметь возможность управлять распределением памяти. Типа есть некая больщая Evgeny_CD(386 знак., 19.10.2010 00:23)
- В ИАРе в файле конфигурации линкера такое делается, какие проблемы? - Михаил Е.(19.10.2010 08:21)
- Опять же никогда не разбирался, а как там к секции кода в {} обратиться? "Вон та, вторая сверху" - как линкеру указать? Не на уровне функции, а именно на уровне блока кода. - Evgeny_CD(19.10.2010 21:03)
- Я так делал Михаил Е.(145 знак., 20.10.2010 11:03)
- С данными понятно. А как указать расположение блока кода {}? Не функции, а именно блока кода? - Evgeny_CD(21.10.2010 12:32)
- А зачем это надо? Не вижу ни одной причины, для чего это может понадобиться... - Михаил Е.(21.10.2010 17:34)
- -> Тонкая оптимизация для MAM. Или выравниваение кусков кода по кеш лайн блоку. - Evgeny_CD(21.10.2010 17:39, ссылка)
- Работа на пределе возможностей? Предпочитаю держаться подальше от предельных параметров, консерватор вобщем:))) - Михаил Е.(21.10.2010 18:30)
- Вопрос в том, как это использовать. Если так делать во всем коде, иначе не успеваем - системного архитектора ф топку. Если только в каком-то определенном критическом месте (небольшом числе мест) - вполне допустимо. - Evgeny_CD(21.10.2010 19:09)
- Я бы согласился на "вылизанную" таким образом библиотеку от производителя кристалла. А вручную обкладывать код флажками? Ну для этого нужны очень веские основания, в первую очередь экономические. - vmp(22.10.2010 11:08)
- Пока что я пытаюсь понять - а "флажки" они только в моей башке есть или в жизни тоже? - Evgeny_CD(22.10.2010 11:13)
- Хотелось бы, чтобы их не было. В общем то ситуаций, когда обязательно надо было так жестко оптимизировать, вылизывая буквально по байту или микросекунде удалось избежать, отступив на заранее приготовленные позиции. :) vmp(564 знак., 22.10.2010 11:57)
- есть. Иногда приходится сталкиваться просто с жуткими примерами оптимизации, ноги которой наиболее часто растут из асемблера koyodza(736 знак., 22.10.2010 11:22, ссылка)
- Пока что я пытаюсь понять - а "флажки" они только в моей башке есть или в жизни тоже? - Evgeny_CD(22.10.2010 11:13)
- имхо, тоже ф топку - koyodza(21.10.2010 20:05)
- +1. Надо брать более крутой кристалл. - Михаил Е.(21.10.2010 20:25)
- не всегда: обычно нужно просто подойти к решению более системно. Шире посмотреть на задачу koyodza(416 знак., 21.10.2010 20:46 - 20:55)
- Согласен! Смотрите расклад. Evgeny_CD(511 знак., 22.10.2010 10:06)
- Вы сейчас обрисовали только один из возможных путей, который предлагаете взамен другого. А я говорю о том, что на практике путей бывает множество, и нужно уметь выбрать правильный (или совокупность нескольких) koyodza(837 знак., 22.10.2010 10:48)
- Все верно. Но в веере возможных решений наличе пути по выжимванию всего за счет тонкой оптимизации - тоже важная компонента. Превожу на язык цифр Evgeny_CD(728 знак., 22.10.2010 11:10)
- а с наступлением события нам уже нужны 5 fps. и вот тут-то BF и пригодится. - Mahagam(22.10.2010 16:25)
- Да, BF - идеальный сопроцессор для ARM! Я с этим полностью согласен :) -> - Evgeny_CD(22.10.2010 16:31, ссылка)
- это только если события наступают слишком часто. Всегда есть разумные требования, превышать которые смысла нет - koyodza(22.10.2010 16:29)
- Да, в том примере, который я приводил, канал узкий и FLASH мало - так что данные при частых события похерятся все равно. И выбор разработчика - похерятся они сжатыми или нет :) - Evgeny_CD(22.10.2010 16:32)
- ну, сжатыми похерить конечно веселее - проц пожирнее, а значит потеплее, а значит больше электричества кушает, а значит нефть быстрее закончится ;=) - koyodza(22.10.2010 16:42)
- Вот, и я за то, чтобы JPEG сделать на double плавучке с комплесными числами, а затем похерить сжатое :) - Evgeny_CD(22.10.2010 16:44)
- ну, сжатыми похерить конечно веселее - проц пожирнее, а значит потеплее, а значит больше электричества кушает, а значит нефть быстрее закончится ;=) - koyodza(22.10.2010 16:42)
- Да, в том примере, который я приводил, канал узкий и FLASH мало - так что данные при частых события похерятся все равно. И выбор разработчика - похерятся они сжатыми или нет :) - Evgeny_CD(22.10.2010 16:32)
- Вы неправильно посчитали koyodza(146 знак., 22.10.2010 16:18)
- Можно и так - тоже верно. Если есть низкоприоритетная задача, то тогда резерва по процу можно не делать - пусть свободное время курит ее. Собственно, я приводил свой искусственный пример для того, чтобы показать нелинейный характер влияния Evgeny_CD(145 знак., 22.10.2010 16:24)
- это к вопросу koyodza(142 знак., 22.10.2010 16:31)
- Можно и так - тоже верно. Если есть низкоприоритетная задача, то тогда резерва по процу можно не делать - пусть свободное время курит ее. Собственно, я приводил свой искусственный пример для того, чтобы показать нелинейный характер влияния Evgeny_CD(145 знак., 22.10.2010 16:24)
- а с наступлением события нам уже нужны 5 fps. и вот тут-то BF и пригодится. - Mahagam(22.10.2010 16:25)
- Все верно. Но в веере возможных решений наличе пути по выжимванию всего за счет тонкой оптимизации - тоже важная компонента. Превожу на язык цифр Evgeny_CD(728 знак., 22.10.2010 11:10)
- Вы сейчас обрисовали только один из возможных путей, который предлагаете взамен другого. А я говорю о том, что на практике путей бывает множество, и нужно уметь выбрать правильный (или совокупность нескольких) koyodza(837 знак., 22.10.2010 10:48)
- Согласен! Смотрите расклад. Evgeny_CD(511 знак., 22.10.2010 10:06)
- не всегда: обычно нужно просто подойти к решению более системно. Шире посмотреть на задачу koyodza(416 знак., 21.10.2010 20:46 - 20:55)
- +1. Надо брать более крутой кристалл. - Михаил Е.(21.10.2010 20:25)
- Я бы согласился на "вылизанную" таким образом библиотеку от производителя кристалла. А вручную обкладывать код флажками? Ну для этого нужны очень веские основания, в первую очередь экономические. - vmp(22.10.2010 11:08)
- +1 - koyodza(21.10.2010 18:33)
- Вопрос в том, как это использовать. Если так делать во всем коде, иначе не успеваем - системного архитектора ф топку. Если только в каком-то определенном критическом месте (небольшом числе мест) - вполне допустимо. - Evgeny_CD(21.10.2010 19:09)
- Работа на пределе возможностей? Предпочитаю держаться подальше от предельных параметров, консерватор вобщем:))) - Михаил Е.(21.10.2010 18:30)
- -> Тонкая оптимизация для MAM. Или выравниваение кусков кода по кеш лайн блоку. - Evgeny_CD(21.10.2010 17:39, ссылка)
- В C функция должна влезать в один регион памяти. Скорей никак. Вынести в другую функцию и её атрибутами/прагмами загнать куда надо. - fk0(21.10.2010 12:37)
- От же засада.. Inline функция, и для нее заданный регион? - Evgeny_CD(21.10.2010 12:43)
- inline -- это что-то вроде define... - fk0(21.10.2010 14:28)
- От же засада.. Inline функция, и для нее заданный регион? - Evgeny_CD(21.10.2010 12:43)
- А зачем это надо? Не вижу ни одной причины, для чего это может понадобиться... - Михаил Е.(21.10.2010 17:34)
- С данными понятно. А как указать расположение блока кода {}? Не функции, а именно блока кода? - Evgeny_CD(21.10.2010 12:32)
- Ну по идее прагмой указываются сегменты для элементов структуры. Тока я, кнешно, так никогда не юзал, только константы: #pragma constseg=XXXX. А вообще-то запись в медленную память требует пусть небольших, но специальных подходов из-за Vladimir Ljaschko(112 знак., 20.10.2010 09:34 - 09:44)
- Я так делал Михаил Е.(145 знак., 20.10.2010 11:03)
- Опять же никогда не разбирался, а как там к секции кода в {} обратиться? "Вон та, вторая сверху" - как линкеру указать? Не на уровне функции, а именно на уровне блока кода. - Evgeny_CD(19.10.2010 21:03)
- В ИАРе в файле конфигурации линкера такое делается, какие проблемы? - Михаил Е.(19.10.2010 08:21)
- Понятно что можно написать мегаскрипт для линкера и "запрагмить" #pragma align код. Но если делать это руками = программирование руками на асме. Кайф состоит в том, чтобы иметь возможность управлять распределением памяти. Типа есть некая больщая Evgeny_CD(386 знак., 19.10.2010 00:23)
- В C можно всё то же самое, но врукопашную и очень аккуратно. Как и в ассемблере. Но не стоит дурную работу взваливать с компилятора на себя. И нет там никакого оверхеда, если не 8-битник... Ну только если кеш -- малость есть. Но маленькие объекты fk0(42 знак., 18.10.2010 23:38)
- Так-так. Вот впервые замаячила кардинальная польза от С++. Вопрос в оверхеде при доступе к таким "продвинутым структурам"... Ну или придется некий протоязык изобретать, на нем описывать работу с такими "продвинутыми структурами" , а затем все Evgeny_CD(17 знак., 18.10.2010 22:16)
- нет - koyodza(18.10.2010 22:12)
- Структура -- она принципиально соседние ячейки памяти занимает. По крайней мере в C++. И вообще компилятор+линкер это не IDE. IDE -- это такой редактор с кнопкой вызова компилятора. И без всяких IDE такое можно сделать, через указатели. Только в fk0(54 знак., 18.10.2010 21:56)
- Ага!!! Вот где впервые (лично для меня) использование С++ может дать кардинально лучший результат... - Evgeny_CD(18.10.2010 22:03)
- Народ, а реально, в С, без С++, такое возможно? - Evgeny_CD(18.10.2010 22:06)