Оптимизация компилятора: где/как я могу получить ощущение того, что выплата для различной оптимизации?

A ListObject не имеет свойства Offset; Range делает.


Возможно, используйте DataBodyRange , который

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

blockquote>

Пример, который записывает в строку x и столбец y таблицы (без использования Offset):

Sub TestMyTable()
    Dim tbl As ListObject
    Set tbl = Sheets("Workouts").ListObjects("tbl_Workouts")

    Dim x As Long, y As Long
    x = 1
    y = 1

    tbl.DataBodyRange(x, y).Value = 1 ' or tbl.DataBodyRange.Cells(x, y)
End Sub

5
задан Andru Luvisi 4 November 2008 в 00:44
поделиться

8 ответов

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

Таким образом, действительно нет хорошего ответа на Ваш вопрос. Все - компромисс. Много оптимизации работают хорошо над одним типом кода, но являются pessimizations для других типов. Это похоже на разработку дома - при создании кухни большего размера кладовая становится меньшего размера.

Реальная работа в создании оптимизатора испытывает различные комбинации, сравнивая результатов, и, как шеф-повар, выбирая правильное соединение компонентов.

13
ответ дан 18 December 2019 в 06:13
поделиться

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

Затем существуют типы оптимизации, которая могла извлечь выгоду из типа используемого процессора (как использование инструкций SIMD относительно современных центральных процессоров).

Посмотрите Оптимизацию Компилятора на Википедию для ссылки.

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

3
ответ дан 18 December 2019 в 06:13
поделиться

Язык в щеке:

  1. Гордость
  2. Сравнительные тесты
  3. Затруднение

Более серьезно это зависит от архитектуры и целей Вашего компилятора. Вот опыт одного человека...

Пойдите для "больших выплат":

  • поколение собственного кода
  • выделение регистра
  • планирование инструкции

Пойдите для остающегося "низко висящего плода":

  • сокращение силы
  • постоянное распространение
  • распространение копии

Продолжайте сравнивать.

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

Обычно имеет место, что объединение оптимизации или даже повторение оптимизационных проходов, являются более эффективными, чем Вы могли бы ожидать. Преимущество является больше, чем сумма частей.

Можно найти, что введение одной оптимизации может требовать другого. Например, SSA с выделением регистра Briggs-Chaitin действительно извлекает выгоду из распространения копии.

4
ответ дан 18 December 2019 в 06:13
поделиться

Я не разработчик компилятора, но почему не только инкрементно оптимизируют части Вашего кода, представляя все время?

Моя схема оптимизации обычно идет:

1) удостоверьтесь, что программа работает

2) найдите, что что-то оптимизирует

3) оптимизируйте его

4) сравните результаты испытаний с тем, что прибыло из 1; если они отличаются, то оптимизация является на самом деле повреждающимся изменением.

5) сравните различие в синхронизации

Инкрементно, я получу его быстрее.

Я выбираю который части сфокусироваться на при помощи профилировщика. Я не уверен, какую дополнительную информацию Вы соберете путем выяснения у разработчиков компилятора.

2
ответ дан 18 December 2019 в 06:13
поделиться

Стоит отметить, что во многих случаях, разработчики компилятора НЕ проведут много времени, если таковые имеются, при обеспечении, что их библиотеки оптимизированы. Сравнительные тесты имеют тенденцию преуменьшать роль или даже игнорировать различия библиотеки, по-видимому, потому что можно просто пользоваться различными библиотеками. Например, алгоритмы перестановки в GCC асимптотически* менее эффективны, чем они могли быть при попытке переставить сложные данные. Это касается неправильного создания глубоких копий во время вызовов для свопинга функций. Это будет, вероятно, исправлено в большинстве компиляторов с введением rvalue ссылок (часть C++ 0x стандарт). Перезапись STL, чтобы быть намного быстрее удивительно легка.

*Это предполагает, что размер переставляемого класса является переменным. Например, перестановка вектора векторов ints замедлилась бы, если бы векторы ints были больше.

1
ответ дан 18 December 2019 в 06:13
поделиться

Это действительно зависит от того, что Вы компилируете. Существует, была довольно хорошая дискуссия об этом в списке рассылки LLVM недавно, это, конечно, несколько характерно для оптимизаторов, которые они имеют в наличии. Они используют сокращения для большого количества их оптимизационных проходов, если не знакомый с каким-либо из акронимов, которые они бросают вокруг Вас, можно посмотреть на их страницу передач для документации. В конечном счете можно провести годы, читая научные газеты на этом предмете.

2
ответ дан 18 December 2019 в 06:13
поделиться

Это - одна из тех тем где научные работы (ACM, возможно?) может быть один из лучших источников актуальной информации. Лучшая вещь сделать, если Вы действительно хотите знать, могла бы состоять в том, чтобы создать некоторый код в неоптимизированной форме и некоторых в форме, которую оптимизация примет (развернутые циклы, и т.д.) и на самом деле выяснит, где усиления, вероятно, будут использовать компилятор с выключенной оптимизацией.

1
ответ дан 18 December 2019 в 06:13
поделиться

Тот, который может дать большие ускорения, но редко делается, должен вставить инструкции по упреждающей выборке памяти. Прием должен выяснить, какую память программа будет желать достаточно далеко заранее, никогда не попросить неправильную память и никогда не переполнять D-кэша.

0
ответ дан 18 December 2019 в 06:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: