Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 126 19-06-2006 09:20 | |
Ответ на »сообщение 119« (AVC)
___________________________
Главное же -- пока нет механизма для совмещения CASE с безопасностью типов.
(Если Вы его предложите -- будет здорово!)
Да я собственно уже предложил - если CASE будет применим для типов, то все с безопасностью типов в порядке. В Дельфи вообще нет препятствий к этому, если метакласс признать полноценным типом. Ну и считать такие константы ordinal.:)
В Обероне чуть сложнее:
CASE msg OF
|Message: console.Writeln(msg(Message).str);
|SleepMessage: sleep(msg(SleepMessage).amount);
ELSE <еще чего-нибудь>
END
Хотя что если точно также как в Дельфи?
Впрочем, может оно и не стоит того - замерять надо. Ускорение программы будет ощутимым только при большом количестве сообщений.
Еще можно компилятор научить оптимизировать IF ELSEIF. Но думаю это усложнит его больше.
№ 125 19-06-2006 07:05 | |
Ответ на »сообщение 124« (AVC)
___________________________
ASU > Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)
По крайней мере, это для них неспецифично. :)
:)
Вместе с тем, если кто-нибудь в результате (вдруг!) предложит механизм, повышающий эффективность обероновской "программной шины", то это будет иметь самое прямое отношение к ОТ
Хм... С моей точки зрения, ОТ - это "сферический конь в вакууме"... Чтобы поднять эффективность, достаточно приписать пару нолей или ввести коэффициент чего-то (ну, очень большой... коэффициент) :)
Все разговоры об инструментах (а язык программирования (даже ассемблер) - это частный случай инструмента) безотносительно области их применения - моветон... IMHO, разумеется.
№ 124 19-06-2006 06:04 | |
Ответ на »сообщение 122« (ASU)
___________________________
Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)
По крайней мере, это для них неспецифично. :)
Вместе с тем, если кто-нибудь в результате (вдруг!) предложит механизм, повышающий эффективность обероновской "программной шины", то это будет иметь самое прямое отношение к ОТ.
№ 123 19-06-2006 05:49 | |
Ответ на »сообщение 120« (4)
___________________________
При больших векторах, такая оптимизация себя оправдывает.ASU
Это интересно. На каком компиляторе пробовали?
На ассемблере... вестимо.
№ 122 19-06-2006 05:46 | |
Ответ на »сообщение 117« (AVC)
___________________________
Но для Windows, ИМХО, это непрактично: слишком большие таблицы переходов могут потребоваться. О чем я и сказал Mirage.
Да, практичность такого вектора вызывает сомнения, тем более, при росте числа видов сообщений и... повышении разрядности :)
Вы предлашаете другой (и весьма симпатичный) способ реализации switch, но главное не меняется -- достичь эффективности поиска перехода O(1) не получается
Вы же знаете, что есть два принципиально разных способа оптимизации программ: по скорости исполнения и размерности. В пределе вектор из четырехбайтных чисел будет стремиться к... 16 Гб, для кода программы может просто не остаться места в адресном пространстве процесса... :)
Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Ваша идея кажется мне интересной.
Единственное -- создается впечатление, что уж слишком умным должен быть компилятор, чтобы выбрать оптимальный способ представления switch
Можно и хешировать, почему бы и нет... Что же касается построения бинарного "дерева", то этот алгоритм реализуем на макроязыке ассемблера (когда-то я его делал...), то есть, он вполне может быть реализован в компиляторе (в виде шаблона, в том числе). Но тоже самое относится и к хешированию. В принципе можно посчитать времена затрачиваемые на вычисление хеш-функции и бинарный поиск для различных N. Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)
№ 121 19-06-2006 05:45 | |
Ответ на »сообщение 120« (4)
___________________________
Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)AVC При каких условиях стоит обратиться?
При условии, если список констант длинный, а диапазон -- большой. :)
На мой взгляд (пока), выбор оптимального механизма реализации switch (CASE) сделает этот раздел компилятора самым интеллектуальным. :)
Но главное не в этом.
Главное, что цепочка
IF v IS T1 THEN ...
ELSIF v IS T2 THEN...
ELSE ...
END
гарантирует безопасность типов (type-safety).
Вариантный оператор WITH (как он представлен в О-2) есть надстройка именно над цепочкой IF ELSIF ELSE, а не над CASE.
Повторю: если кто-нибудь предложит типобезопасный механизм, более эффективный, чем цепочка IF ELSIF ELSE, я буду очень рад.
Мне самому не нравится не слишком высокая эффективность этой конструкции.
№ 120 Удалено модератором | |
№ 119 19-06-2006 05:35 | |
Ответ на »сообщение 118« (Mirage)
___________________________
Речь шла о том, что CASE эффективнее кучи проверок с IS. Даже если IS - одно сравнение.
Я против CASE ничего не имею. :)
Хотя CASE и не всегда эффективнее, чем IF ELSIF ELSE.
CASE не учитывает случаи с разной вероятностью выбора ветвей.
Кроме того, для коротких списков констант следует учитывать дополнительные накладные расходы на вспомогательные вычисления.
Главное же -- пока нет механизма для совмещения CASE с безопасностью типов.
(Если Вы его предложите -- будет здорово!)
№ 118 19-06-2006 04:47 | |
Ответ на »сообщение 117« (AVC)
___________________________
Речь шла о том, можно ли найти адрес перехода в массиве, сгенерированном компилятором, за одно сравнение.
Речь шла о том, что CASE эффективнее кучи проверок с IS. Даже если IS - одно сравнение.
Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Собственно при плотности констант в CASE хеширование и происходит (должно). А при неплотном распределении - разбиение на набор плотных и т.п. ухищрения.
№ 117 19-06-2006 04:24 | |
Ответ на »сообщение 115« (ASU)
___________________________
Да, но при условии "плотности" списка констант.
Применительно к огромному (и потому "рассеянному") количеству сообщений Windows, это неприменимо, ИМХО.
"Плотность" списка констант не является столь важным показателем. Хороший компилятор на месте switch создаст конструкцию вида:
mov eax,[message]
lea edx,msg_vector
mov ecx,cnt_items - 1
@@loop:
cmp eax,[edx + ecx * 8]
je @@run_handler
dec ecx
jns @@loop
; default handler
@@run_handler:
jmp [edx + ecx * 8 + 4]
Речь шла о том, можно ли найти адрес перехода в массиве, сгенерированном компилятором, за одно сравнение.
Что-то вроде:
msg_type -= LEAST_MSG_TYPE_IN_SWITCH;
if (0 <= msg_type && msg_type < sizeof (jmp_table) / sizeof (*jmp_table))
Принципиально, конечно, это возможно.
Но для Windows, ИМХО, это непрактично: слишком большие таблицы переходов могут потребоваться. О чем я и сказал Mirage.
Вы предлашаете другой (и весьма симпатичный) способ реализации switch, но главное не меняется -- достичь эффективности поиска перехода O(1) не получается.
Вектор обработки выглядит следущим образом:
label dword
message1, handler1 ; номер первого сообщения и адрес его обработчика
message2, handler2 ; номер второго сообщения и адрес его обработчика
...
Если компилятор "умный", то он оптимизирует обработку вектора, исходя из количества входящих в него элементов, возможно включив прямой просмотр (а не обратный, как в примере), предвыборку (prefetch) и даже отсортировав на этапе компиляции сообщения, чтобы использовать бинарный поиск. При больших векторах, такая оптимизация себя оправдывает.
Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Ваша идея кажется мне интересной.
Единственное -- создается впечатление, что уж слишком умным должен быть компилятор, чтобы выбрать оптимальный способ представления switch.
(Может быть, я неправ. Надо подумать.)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|