Здравствуйте, mihailik, Вы писали:

A>>>>варианты есть, только все предпочитают не думать а решать "в лоб" или "в лом"

M>>>Видимо секретные какие-то технологии, что ты их скрываешь?

M>Значит всё-таки секретная технология

умершие технологии

A>>>>для некоторых типов данных возможна даже очень большая оптимизация

M>>>Что-то я упустил, когда мы перешли к List "для некоторых типов". Разве мы не об универсальном классе говорим?

A>>если класс уневерсальный значит он должен подрузумевать расширение в таких местах!

M>Да не хочу я воздух перемешивать. Упёрся, понимаешь, абстрактной диалектике поучает.

M>Ты знаешь конкретные причины писать List неделю? Назови конкретно, а не это вот "подразумевать расширение", "очень большая оптимизация". Какая большая оптимизация и какие конкретно расширение.

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

написать можно и за пару часов, а вот получить 100% увереность что то, что написал соотвествует требованиям и работает быстро и без глюков — вот это занимает большего всего времени...

а говорить что я могу написать это за пару часов и оно будет рабочим есть подход делетанский...
без тестов твоему слову просто никто не поверит или ты намекаеш что в макрософте делетанты работают?!
ведь у у них все проходит тестинг и очень "жесткий", и скорость у них высокая разработки из-за того что они пишут код хорошо + каждый занимаеться своим делом.

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

A>написать можно и за пару часов, а вот получить 100% увереность что то, что написал соотвествует требованиям и работает быстро и без глюков — вот это занимает большего всего времени...

Это ты о реализации алгоритма RSA говоришь, или о List, у которого есть всего 2 поля: m_Array и m_Count?


A>а говорить что я могу написать это за пару часов и оно будет рабочим есть подход делетанский...

Готов согласиться, если ты мне назовёшь какие-нибудь подводные камни в этом вопросе. А так это какое-то запугивание детей квадратным трехчленом.


A>ведь у у них все проходит тестинг и очень "жесткий", и скорость у них высокая разработки из-за того что они пишут код хорошо + каждый занимаеться своим делом.

Ну ты же сам сказал, что нужен разумный подход. Для List нужно одно время на тестирование, для System.Net.Socket другое. Что ты панику-то поднимаешь.

Здравствуйте, mihailik, Вы писали:

A>>написать можно и за пару часов, а вот получить 100% увереность что то, что написал соотвествует требованиям и работает быстро и без глюков — вот это занимает большего всего времени...

M>Это ты о реализации алгоритма RSA говоришь, или о List, у которого есть всего 2 поля: m_Array и m_Count?

A>>а говорить что я могу написать это за пару часов и оно будет рабочим есть подход делетанский...

M>Готов согласиться, если ты мне назовёшь какие-нибудь подводные камни в этом вопросе. А так это какое-то запугивание детей квадратным трехчленом.

мы вообще об ArrayList начинали говорить, а потом ты решил урезать вопрос до List... потому и не понимание...
в ArrayList входит поиск и сортировка, работа с сабсетами (subsets), ридонли колекции, адаптеры на IList ну и остальное там по мелочевке... так что ты сам себя запутал написав List — под которым понимаеш только динамически растущий масив. толку от динамического масива мало... потому на него навешали дополнительную логику, а не только array + Length

A>>ведь у у них все проходит тестинг и очень "жесткий", и скорость у них высокая разработки из-за того что они пишут код хорошо + каждый занимаеться своим делом.

M>Ну ты же сам сказал, что нужен разумный подход. Для List нужно одно время на тестирование, для System.Net.Socket другое. Что ты панику-то поднимаешь.

A>мы вообще об ArrayList начинали говорить, а потом ты решил урезать вопрос до List... потому и не понимание...

А, ну это просто мы с тобой друг друга не поняли. Ладушки.


Вообще, ситуация развивалась так. Влад сказал, что генериковский List тормозит:

Re[7]: Вопросы производительности

Автор: VladD2
Дата: 15.04.04

Дженериковый Лист к сожалению содран под копирку с АррэйЛиста. Причем боксинг там через раз. Тот что был в первой Видбе вообще был полной задницей (в сотни раз мдленнее массива на некоторых операциях). Тот что вновой по шустрее, но тоже тормоз еще тот.

Так что все будет ОК. Или МС поправит свои коллекции или мы родим свои.

На что я ответил, что написать свою коллекцию действительно очень легко:

Re[8]: Вопросы производительности

Автор: mihailik
Дата: 16.04.04

Написать нормальный List — день. Ну ещё день на совесть оттестировать и оптимизировать.

А тут уж ты возмутился и пошло-поехало. То есть моя оценка скорости относилась именно к генериковскому List, и это был ответ на Владовский пост о генериковском List'е.

Здравствуйте, mihailik, Вы писали:

A>>мы вообще об ArrayList начинали говорить, а потом ты решил урезать вопрос до List... потому и не понимание...

M>А, ну это просто мы с тобой друг друга не поняли. Ладушки.

M>

M>Дженериковый Лист к сожалению содран под копирку с АррэйЛиста. Причем боксинг там через раз. Тот что был в первой Видбе вообще был полной задницей (в сотни раз мдленнее массива на некоторых операциях). Тот что вновой по шустрее, но тоже тормоз еще тот.

M>Так что все будет ОК. Или МС поправит свои коллекции или мы родим свои.

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

Здравствуйте, mihailik, Вы писали:

M>>>То есть ты утверждаешь, что скорость регекспов не зависит от входной строки?

VD>>Нет конечно. Исключительно от алгоритмов реализации.

M>То есть сложный регексп типа "подсветка синтаксиса C++ с шаблонами и операторам" на строке из сплошных пробелов будет работать так же быстро, как и на реальном коде C++? Не верится как-то

Практически так же. По крайней мере если рассуждать в терминах скорости алгоритма. Рельно конечно за счет поподания в кэш и т.п. это будет не так. Но существенного ускорения/замедления быть не должно.

M>А регекспы в дотнете генерируют код вообще-то.

Так при включенном режиме компиляции они становтся значительно быстрее. Но, их основная проблема в применяемых алгоритмах. Дело в том, что построение ДКА и эффективное его исполнение — это сама по себе довольно сложная задача. А дотнетные рекексы ко всему прочему еще наворочены как черт знает что.

У ДКА в любой точке разбираемой последовательности всегда только один переход для каждого случая. Так что тормозить просто нечему.

Но это сложный код. И сделать его универсальным просто невозможно. Например, ДКА сканера дотнета из R#-а составляет порядка 6000 строк кода на шарпе.

M>Это неплохо само по себе. Но на каждый случай велосипедов не напасёшься. А есть готовая упрощённая альтернатива?

Я знаком только с Lex-ом и Кокой. Общая их идея упрощающая создание регулярных выражений заключается в ведении именованных правил. Вот например полное описание регулярного выражения C#-а на Коке:

CHARACTERS

tab                = '\u0009'. /*  9 = tabulator */
eol                = '\u000a'. /* 10 = line feed */
cr                 = '\u000d'. /* 13 = carriage return */
newLine            = cr + eol. /* Line separator character (U+2028) + Paragraph separator character (U+2029) */
eof                = '\0'.

letter             = 'A' .. 'Z' + 'a' .. 'z' + UnicodeChar + '_'.
decDigit           = "0123456789".
hexDigit           = decDigit + "ABCDEFabcdef".
notDigit           = ANY - decDigit.

char               = ANY - "'" - '\\' - newLine.
verbatimStringChar = ANY - '"'.
regularStringChar  = ANY - '"' - '\\' - newLine.
inputChar          = ANY - newLine - eof.
fileNameChar       = ANY - '"' - newLine - '\u0022' .
    
notNumSign         = ANY - "#".
notNewLine         = ANY - newLine .
notAsterisk        = ANY - "*" .
notSlash           = ANY - "/".

ws                 = " " + tab + '\u000b' + '\u000c'. /* Any character with Unicode class Zs */

IGNORE eol + cr + tab

TOKENS

literal
= /*--- boolean literal: "true" | "false" -> moved to PrimaryExpr */
  
  /*--- integer literal: */
    /*--- decimal: */
  ( decDigit { decDigit } | decDigit { decDigit } CONTEXT (".")
    /*--- hexadecimal: */
  | ( "0x" | "0X" ) hexDigit { hexDigit }
  )
    /*--- integer type suffix */
  [ "U" | "u" | "L" | "l" | "UL" | "Ul" | "uL" | "ul" | "LU" | "Lu" | "lU" | "lu" ]
  /*--- real literal (without integer part) */
| "." decDigit { decDigit } 
  [ ( "e" | "E" ) [ "+" | "-" ] decDigit { decDigit } ] 
  [ "F" | "f" | "D" | "d" | "M" | "m" ]
  /*--- real literal (with integer part) */ 
| decDigit { decDigit } 
  ( "." decDigit { decDigit } 
    [( "e" | "E" ) [ "+" | "-" ] decDigit { decDigit } ] 
    [ "F" | "f" | "D" | "d" | "M" | "m" ]
  | ( "e" | "E" ) [ "+" | "-" ] decDigit { decDigit }
    [ "F" | "f" | "D" | "d" | "M" | "m" ]
  | "F" | "f" | "D" | "d" | "M" | "m"
  )

  /*--- character literal */
| "'" (    char
        /*--- simple escape sequence */ 
      | "\\\'" | "\\\"" | "\\\\" | "\\0" | "\\a" | "\\b" | "\\f" | "\\n" | "\\r" | "\\t" | "\\v"
        /*--- hexadecimal escape sequence */
      | "\\x" hexDigit [ hexDigit ] [ hexDigit ] [ hexDigit ]
        /*--- unicode character escape sequence */
      | "\\u" hexDigit hexDigit hexDigit hexDigit
      | "\\U" hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit
      ) 
  "'"    

  /*--- regular string literal */
| "\""    { regularStringChar
          /*--- simple escape sequence */ 
        | "\\\'" | "\\\"" | "\\\\" | "\\0" | "\\a" | "\\b" | "\\f" | "\\n" | "\\r" | "\\t" | "\\v"
          /*--- hexadecimal escape sequence */
        | "\\x" hexDigit [ hexDigit ] [ hexDigit ] [ hexDigit ]
          /*--- unicode character escape sequence */
        | "\\u" hexDigit hexDigit hexDigit hexDigit
        | "\\U" hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit hexDigit
        } 
  "\""
  
  /*--- verbatim string literal */
| "@\"" { verbatimStringChar | "\"\"" } "\""
  
  /*--- null literal: "null" -> moved to PrimaryExpr */
.


identifier 
= letter { letter | decDigit } 
/* AW 2002-12-28 isn't the following also an identifier in C#? */ 
| "@" 
  /*--- keywords */
  ( "abstract" | "as"       | "base"       | "bool"      | "break" 
  | "byte"     | "case"     | "catch"      | "char"      | "checked" 
  | "class"    | "const"    | "continue"   | "decimal"   | "default" 
  | "delegate" | "do"       | "double"     | "else"      | "enum" 
  | "event"    | "explicit" | "extern"     | "false"     | "finally" 
  | "fixed"    | "float"    | "for"        | "foreach"   | "goto" 
  | "if"       | "implicit" | "in"         | "int"       | "interface" 
  | "internal" | "is"       | "lock"       | "long"      | "namespace" 
  | "new"      | "null"     | "object"     | "operator"  | "out" 
  | "override" | "params"   | "private"    | "protected" | "public" 
  | "readonly" | "ref"      | "return"     | "sbyte"     | "sealed" 
  | "short"    | "sizeof"   | "stackalloc" | "static"    | "string" 
  | "struct"   | "switch"   | "this"       | "throw"     | "true" 
  | "try"      | "typeof"   | "uint"       | "ulong"     | "unchecked" 
  | "unsafe"   | "ushort"   | "using"      | "virtual"   | "void" 
  | "while"
  )
.

Как видишь понять намного проще чем регекс и объем довольно скромный (все же это весь Шарп).

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

Здравствуйте, mihailik, Вы писали:

M>Для Array.Length можно гарантировать постоянство значения в течении цикла. Для ICollection это не так.

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

VD>>И причем тут массив? Это верно и для любых других инвариантов.

M>Для IList мы не можем делать никаких предположений по инвариантности.

1. Потенциально можем.
2. Это не исключает других случаев.

M> JIT может распознать Array, это быстро. Определить инвариантность реализации IList потенциально можно, но не в режиме JIT.

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

M>То есть, такие оптимизации в JIT возможны только для заранее известных классов. Системных классов.

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

VD>>Тесты показывают ускорение при ручной замене проверки на проверку локальной переменной.

M>Ну что ж. Возможно, в будущем доделают.

В будущем похоже, что МС сольет (да почти слили) оптимизитор джита и С++ в один проект. Вот тогда оптимизация уже по идее должна стать без компромисов. И возможно появится полная оптимизация всего приложения в момент инсталляции. Это было бы самым верным решением.

M>>Для Array.Length можно гарантировать постоянство значения в течении цикла. Для ICollection это не так.

VD>При наличии инлайнинга это так для любого случая.

Вот самый распространённый случай.

public int Count
{
  get { return m_Count; }
}

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




M>>То есть, такие оптимизации в JIT возможны только для заранее известных классов. Системных классов.

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

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