Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  23:21[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 136—127 | 126—117 | 116—107 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 614


№ 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)
___________________________

Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)

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


№ 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, я буду очень рад.
Мне самому не нравится не слишком высокая эффективность этой конструкции.
 AVC


№ 120   Удалено модератором


№ 119   19-06-2006 05:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 118« (Mirage)
___________________________


Речь шла о том, что CASE эффективнее кучи проверок с IS. Даже если IS - одно сравнение.


Я против CASE ничего не имею. :)
Хотя CASE и не всегда эффективнее, чем IF ELSIF ELSE.
CASE не учитывает случаи с разной вероятностью выбора ветвей.
Кроме того, для коротких списков констант следует учитывать дополнительные накладные расходы на вспомогательные вычисления.

Главное же -- пока нет механизма для совмещения CASE с безопасностью типов.
(Если Вы его предложите -- будет здорово!)
 AVC


№ 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)) {
    adr = jump_table[msg_type];
    if (adr != 0)
        goto adr; /* ну, примерно так -- на ассемблере уже не наглядно... :) */
}


Принципиально, конечно, это возможно.
Но для Windows, ИМХО, это непрактично: слишком большие таблицы переходов могут потребоваться. О чем я и сказал Mirage.
Вы предлашаете другой (и весьма симпатичный) способ реализации switch, но главное не меняется -- достичь эффективности поиска перехода O(1) не получается.


Вектор обработки выглядит следущим образом:
label dword
message1, handler1 ; номер первого сообщения и адрес его обработчика
message2, handler2 ; номер второго сообщения и адрес его обработчика
...
Если компилятор "умный", то он оптимизирует обработку вектора, исходя из количества входящих в него элементов, возможно включив прямой просмотр (а не обратный, как в примере), предвыборку (prefetch) и даже отсортировав на этапе компиляции сообщения, чтобы использовать бинарный поиск. При больших векторах, такая оптимизация себя оправдывает.


Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Ваша идея кажется мне интересной.
Единственное -- создается впечатление, что уж слишком умным должен быть компилятор, чтобы выбрать оптимальный способ представления switch.
(Может быть, я неправ. Надо подумать.)
 AVC


<<<... | 136—127 | 126—117 | 116—107 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 614


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования