Re[6]: pattern matching для питона :)
От: FR  
Дата: 21.09.06 18:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Просто структуры данных питона очень плохо приспособленны для сопоставления с образцом.


VD>Не "просто", это одна из проблем. Почему ты думаешь при разговоре о паттерн-матчинге все время всплывают алгеброические типы данных (варинаты)? Именно потому, что они сделаны так чтобы по ним можно было делать сложный паттерн-матчинг. Но их наличие это еще не все. Еще нужен ээ... думатель (как точно подметил Ц-Смаил). Этот думатель должен преобразовать паттерн в набор логических предикатов. Это нехилый алгоритм. В Немерле его тупо скомуниздили из одной из реализаций ML-я. Его уже так на коленке не напишишь. Да и в рантайме его отрабатывать слишком накладно.


Я знаю (вернее уже почти забыл) как реализовано это в прологе(там вообще примитивно), это не так сложно как кажется. Вернее на порядки проще чем вывод типов. В общем вполне посильная задача.

FR>>Но в принципе решаемо вводом новых типов, с которыми сможет работать сопоставление (аналог variant из nemerle) и плюс адаптеров к встроенным спискам, туплам и т. п. Но это слишком трудоемко Поэтому мне пока более интересно возится с аналогами мультиметодов, они с одной стороны слабее pattern matching'а c другой наооборот мощнее.


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


Ну эрланг вполне справляется, и в питоне в случае тормозов можно и на си кое что переписать.
Но вообще я пока такую бибилотеку писать не собираюсь, оно хоть и реально, но очень трудоемко
Меня пока устраивают и маленькие трюки типа этого "pattern matching".

VD>Пойми, паттерн-матчинг только выглядит просто. А внтри это довольно высокотезнологичные алгоритмы.


Не совсем, по моему ты переусложняешь.
Re[7]: pattern matching для питона :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.09.06 19:03
Оценка: 6 (1)
Здравствуйте, FR, Вы писали:

FR>Я знаю (вернее уже почти забыл) как реализовано это в прологе(там вообще примитивно), это не так сложно как кажется. Вернее на порядки проще чем вывод типов. В общем вполне посильная задача.


Оба алогоритма на одном и том же языке доступны на сйте Немерла. Вывод типоб объемнее, но оно и понятно, он же по всем выражениям работат. К тому же неясно причем тут вывод типов. Питон его вроде как не поддерживал.
http://nemerle.org/svn/nemerle/trunk/ncc/typing/DecisionTreeBuilder.n (28 кил)
http://nemerle.org/svn/nemerle/trunk/ncc/typing/Typer.n (113 кил).

А вот описание http://www.dina.kvl.dk/~sestoft/papers/match.ps.gz (постскрипт)

FR>Ну эрланг вполне справляется, и в питоне в случае тормозов можно и на си кое что переписать.


Насколько мне извесно паттерн-матчинг в Эрналге встроенный и написан не на Эрланге.

FR>Но вообще я пока такую бибилотеку писать не собираюсь, оно хоть и реально, но очень трудоемко


Вот и я о том же. А результат будет скорее всего не очень хорошим.

FR>Не совсем, по моему ты переусложняешь.


Исходники я привел. Причем это резуальтат достигнут с использованием того самого паттерн-матчинга. Без него все будет намного более объемно и сложно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: BOOST, .NET, String.Split и производительность…
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.09.06 19:03
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> Особенноп риятно этот тест сравнивать с вот этоим произведением человеческой мысли .


Пардон. Забыл ссылку дать. Вот этот код мне больше всего понравился. Истенно в духе С++, т.е. пол лохунгом "зато быстро!".
Re: Наколенный вариант 8-летней давности
Автор: McSeem2
Дата: 20.09.06
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: BOOST, .NET, String.Split и производительность…
От: FR  
Дата: 21.09.06 19:06
Оценка:
Здравствуйте, VladD2, Вы писали:

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


MS>>Влад, ты слова читать умеешь? Напомню, что в моем сообщении речь шла о неком другом случае, а не о split. На Линухе он не проверялся.


VD>О како таком другом случае? Я просто уже второй раз тут вижу, что проблемы в МС. Очень интересна эта теория. Люблю, знаете ли, теорию заговора.


Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.
Re[11]: BOOST, .NET, String.Split и производительность…
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.09.06 19:12
Оценка:
Здравствуйте, FR, Вы писали:

FR>Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.


Извини, а 1.5 раза и 30 раз проигрыша C#-e это сравненимые вещи? А под Линуксом что тормоизило?

А может это и правда заговор? Ну, МС специально подкупили всех писателей библиотек?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: BOOST, .NET, String.Split и производительность…
От: McSeem2 США http://www.antigrain.com
Дата: 21.09.06 19:39
Оценка: +4 :)))
Здравствуйте, VladD2, Вы писали:

VD>Пардон. Забыл ссылку дать. Вот этот код мне больше всего понравился. Истенно в духе С++, т.е. пол лохунгом "зато быстро!".

VD>Re: Наколенный вариант 8-летней давности
Автор: McSeem2
Дата: 20.09.06


Если бы ты был чуть более внимательным, то заметил бы, что тот мой код (напомню — востмилетней давности) умеет еще выполнять trim по ходу дела, выделять токены в кавычках любого вида (аргумент "quote") с маскированием (аргумент mask_chr) и работать с тремя типами разделителей:
single — каждый символ является разделителем (1,,,2 выдаст "1" "" "" "2")
multiple — работает как strtok (1,,,2 выдаст "1" "2")
whole_str — разделителем является вся строка

Все это не нужно в рамках задачи данного треда, но при этом и не мешает. Просто я наивно расчитывал на наличие у тебя некоторых зачатков разума.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: BOOST, .NET, String.Split и производительность…
От: CreatorCray  
Дата: 21.09.06 20:15
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Сначала результатаы (AMD Атлон 64 3500 (2.2 Ггц):

VD>
VD>[123, 345, asdf, 23453, asdfas]
VD>00:00:00.8376620
VD>5000000
VD>00:00:00.2925531
VD>5000000
VD>00:00:00.7282637
VD>5000000
VD>


Господа, ну ей богу как дети малые. Ну выводите вы в единых попугаях значения. Например в % от производительности на тестовой платформе самого первого приведенного исходника. Потому как понять, что быстрее — приведенный код на немерлях или написанный на коленке код на языке ЗЮ, если у меня нет немерле?

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

ЗЫ: Все считать стёбом (Коим он собстна и является), кроме предложения "унифицировать" оценку производительности алгоритмов
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: BOOST, .NET, String.Split и производительность…
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.09.06 22:38
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Если бы ты был чуть более внимательным, то заметил бы, что тот мой код (напомню — востмилетней давности) умеет еще выполнять trim по ходу дела, выделять токены в кавычках любого вида (аргумент "quote") с маскированием (аргумент mask_chr) и работать с тремя типами разделителей:

MS>single — каждый символ является разделителем (1,,,2 выдаст "1" "" "" "2")
MS>multiple — работает как strtok (1,,,2 выдаст "1" "2")
MS>whole_str — разделителем является вся строка

Мне влом все это выписваать, но я тебяуверяю, что размер кода будет все равно не сопоставим с твоим.

MS>Все это не нужно в рамках задачи данного треда, но при этом и не мешает. Просто я наивно расчитывал на наличие у тебя некоторых зачатков разума.


Ага.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: BOOST, .NET, String.Split и производительность…
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.09.06 22:38
Оценка:
Здравствуйте, CreatorCray, Вы писали:

VD>>Сначала результатаы (AMD Атлон 64 3500 (2.2 Ггц):

VD>>
VD>>[123, 345, asdf, 23453, asdfas]
VD>>00:00:00.8376620
VD>>5000000
VD>>00:00:00.2925531
VD>>5000000
VD>>00:00:00.7282637
VD>>5000000
VD>>


CC>Господа, ну ей богу как дети малые. Ну выводите вы в единых попугаях значения. Например в % от производительности на тестовой платформе самого первого приведенного исходника.


А как ты себе это видишь? Вообще-то тест 3 у меня как раз дотнетный сплит. Так что процент можешь посчитать сам.

За одно можно сделать вывод, что 30% производительности легко заменяются 30% стоимости процессора.

CC> Потому как понять, что быстрее — приведенный код на немерлях или написанный на коленке код на языке ЗЮ, если у меня нет немерле?


На самом, деле на Немерле можно написать код 1 в 1 и даже чуть быстрее чем версия из библоиотеки. Но какой смысл доказвать, что джит работат (просто работает)?

CC>А то скучно за вашими писькомерянием наблюдать когда не видно у кого короче


Откровенно говоря эта пенисометрия меня не волоновала. Меня интересовало насколько велик оверхэд у функционального подхода и итераторов. Ведь писать с их использованием иногда намного приятнее. И если это не так уж дорого стоит, то почему бы и нет. Самый разфункциональный варинт показал скорость куда выше чем тормоза на С++ (те что с библиотекой, а не с хардкодингом). Если мне захочется написать действительно максимально быстрый вариант, то я его напишу. Но он будет менее красив чем эти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: BOOST, .NET, String.Split и производительность…
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 22.09.06 03:24
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

MS>Напомню, что в моем сообщении речь шла о неком другом случае


вот меня собственно и озадачило, что к рассматриваемому случаю он никаким боком, разве что по MS проехаться
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[12]: BOOST, .NET, String.Split и производительность…
От: FR  
Дата: 22.09.06 03:38
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


FR>>Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.


VD>Извини, а 1.5 раза и 30 раз проигрыша C#-e это сравненимые вещи? А под Линуксом что тормоизило?


Это уже проблемы бустовцев, как умудрились не знаю, мне некогда серъезно разбиратся.
Ну а проблема со строками в рантайме VC это уже вина ms, это тоже надо умудрится лазить без повода в ядро.

VD>А может это и правда заговор? Ну, МС специально подкупили всех писателей библиотек?


Они еще тестерам на линуксе мозги затуманивают так что нолик лишний пропадает
Re[4]: BOOST, .NET, String.Split и производительность…
От: CreatorCray  
Дата: 22.09.06 04:34
Оценка:
Здравствуйте, VladD2, Вы писали:

CC>>Господа, ну ей богу как дети малые. Ну выводите вы в единых попугаях значения. Например в % от производительности на тестовой платформе самого первого приведенного исходника.

VD>А как ты себе это видишь? Вообще-то тест 3 у меня как раз дотнетный сплит. Так что процент можешь посчитать сам.
Я имел в виду ту черепашку на С++ + буст. Которая 20 секунд ползла... Время других тестов выводить как % от времени исполнения этого черепашьего теста на этой же машине.

VD>За одно можно сделать вывод, что 30% производительности легко заменяются 30% стоимости процессора.


CC>> Потому как понять, что быстрее — приведенный код на немерлях или написанный на коленке код на языке ЗЮ, если у меня нет немерле?

VD>На самом, деле на Немерле можно написать код 1 в 1 и даже чуть быстрее чем версия из библоиотеки. Но какой смысл доказвать, что джит работат (просто работает)?
Нененене! Теоретическое доказательство не интересует. Надо практическое. Потому как в теории — практика не отличается от теории. Но на практике — отличается. (С) "не помню кто"

CC>>А то скучно за вашими писькомерянием наблюдать когда не видно у кого короче

VD>Откровенно говоря эта пенисометрия меня не волоновала.
Сама пенисометрия мне тоже по барабану. Мне больше интересно у которого варианта производительность выше, насколько и почему.
VD>тормоза на С++ (те что с библиотекой, а не с хардкодингом).
Т.е. тормоза самого буста...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: BOOST, .NET, String.Split и производительность…
От: FR  
Дата: 22.09.06 04:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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


MS>>Если бы ты был чуть более внимательным, то заметил бы, что тот мой код (напомню — востмилетней давности) умеет еще выполнять trim по ходу дела, выделять токены в кавычках любого вида (аргумент "quote") с маскированием (аргумент mask_chr) и работать с тремя типами разделителей:

MS>>single — каждый символ является разделителем (1,,,2 выдаст "1" "" "" "2")
MS>>multiple — работает как strtok (1,,,2 выдаст "1" "2")
MS>>whole_str — разделителем является вся строка

VD>Мне влом все это выписваать, но я тебяуверяю, что размер кода будет все равно не сопоставим с твоим.


Вообще то вполне сопоставим, эта не та задача на которй можно демонстрировать большие преимущества функциональщины, даже твой вариант в лоб переписанный на C++ не так уж и страшен:
void split(const char *str, list<string> &lst)
{
struct nevermind 
    {
    static void loop(int start, int i, list<string> &lst, const char *str)
        {
        if(str[i])
         {
         if(str[i] == ' ' || str[i] == '\t' ) 
          {
          lst.push_back(string(str, start, i - start));
          loop(i + 1, i + 1, lst, str);
          }
         else loop(start, i + 1, lst, str);         
         }
        else if (start == i) return;
        else {lst.push_back(string(str, start, i - start)); return;}
        }
    };
    
nevermind::loop(0, 0, lst, str);
}


Re[14]: BOOST, .NET, String.Split и производительность…
От: Denis2005 Россия  
Дата: 22.09.06 08:36
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Ты меня извини, то на Лиспе писать то что есть в бусте в 100 раз проще. Язык банально создан для таких вещей. В метапрограммировании он один из лучших.

VD>Как раз Лисп, по твоим словам "созданный для доказания той или иной точки зрения" прекрасно реализует идею "расширения языка за счет библиотек". А С++ тут выглядит очень убого.

Неспорю, что макросы Лиспа позволяют это делать. Только вот синтаксис глаза режет, всмысле если это можно назвать синтаксисом. Я помню еще давно на отечественной персоналке "Вектор-06Ц" (проц. i8080) баловался с Форт-ом, тоже было интересное занятие, но я бы не стал его использовать в реальных, командных проектах, т.к. не каждый станет свое сознание переворачивать, для того чтобы писать на этом языке.

VD>Элементарно, Ватсон (с). Добавить в язык то что люди безуспешно пытаются прикрутить к нему через одно место. Совместимость от этого не пострадает. К тому же можно ввести некие режимы. Например, в C# можно писать опасный код, но для этого нужно сказтаь об этом компилятору.


Ох, не рассказывай про C# и опысный код (unsafe) . Обычно 'опасные' места пишу на C/C++ и интеропом добираюсь до этой функиональности.

VD>Да, да. Всегда проще найти проблему в оппоненте. Не признавать же свою неравоту?


Какая неправота? Да язык сложен, да в нем куча проблем, но комитет по крайней мере отсеил кучу дибильных предложений (которые существенно могли усугубить положение), которые предлагадись в свое время с неистовым интузиазмом. Почитай "Дизай и эволюция C++", на досуге, а то получается "чукча не читатель — чукча писатель".

VD>А что сейчас то изменеилось? Что опыт доступен только избранным? Что мешало проанализировать его 3, 6, 9 лет назад? Он же был. И он никуда не делся и сейчас. Стандарт 0x явно подразумевает что x — это римская 10. Так что время еще есть. Как раз можно успеть к 10-му году если начать работать уже сейчас.


К 0x никаких существенных изменений не произойдет, если не хотят растерять оставшихся 'пионеров' метапрограммирования.

VD>Мне кажется для языка опаснее оставлять все как есть.


Иногда лучшее действие — это бездействие.

VD>Ничего от размера не зависит. Достаточно месяцок пописать на языке с функциями высшего порядка и поймешь, что фанкторы это костыль. Причем неудобный.

VD>Это еще одна ересь навиваемая С-шными корнями. В современных языках отказваются от указателей вообще. То как передавть объект или фунцию должен определять компилятор и/или рантайм. Если они умны, то без проблем могут вообще устранить сам факт передачи. Ведь код в конечном итоге не более чем инструкции процессора, то есть байты/биты.

Всё, извини, но дальнейшее обсуждение темы "функторы сакс" мне надоели.

D>>Если уж так хочется, то напиши функцию которая будет инкапсулировать begin()/end().


VD>А почему ее не написали в библиотеке?


Потому, что библиотека потенциалоьно рассчитана на нулевые издержки.

VD>Да и как эту инкапсуляцию передавть в те самые функции STD и буста?


Хоть тресни, но я не вижу неудобства в использовании итераторов.

VD>Ага. Не спорю. Но какие задачи тебе удобно писать на С++? Не уж то ты драйверы пишешь?


Драйвера, нет (хотя раньше бывало), а сейчас:
1). порой приходится писать для старых машинок.
2). важные с точти срезния производительности фрагменты (где .NET-кий аллокатор, ведет себя не лучшим образом).

D>>Попробуй пописать на .NET под GBA (Game Boy Advance) или Nintendo DS, или его где нибудь где он просто не применим.

VD>А ты для них пишешь?

Да, немного.

VD>И что С++ это единственный выбор для этих платформ?


Asm, C/C++ (и представь себе STL).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: BOOST, .NET, String.Split и производительность…
От: gid_vvp  
Дата: 22.09.06 08:41
Оценка: 6 (1) +1
Здравствуйте, Denis2005, Вы писали:

D>Доброго времени суток!


D>Понадобилось 'посплитить' строки (вообще задача более сложная, но обо всем по порядку), и по совету “мудрых старцев” (которые по новомодной традиции, при каждом чихе отправляют к boost-у) решил потестировать производительность boost::algoruthm:split.


D>Честно говоря, результаты меня обескуражили…


на сколько я понял очень много жрёт split_iterator который наследуется от find_iterator_base который в свою очередь принимает предикат который внутри хранится... Внимание! вот таким вот образом
typedef function2<
                    match_type, 
                    input_iterator_type, 
                    input_iterator_type> finder_type;
...

private:
                // Finder
                finder_type m_Finder;


и именно этот предикат и делает практически всю работу.

А boost::function это на мой взгляд не самая быстрая вещь.

вот.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: BOOST, .NET, String.Split и производительность…
От: n0name2  
Дата: 22.09.06 15:35
Оценка:
VD>Сначала результатаы (AMD Атлон 64 3500 (2.2 Ггц):
VD>
VD>[123, 345, asdf, 23453, asdfas]
VD>00:00:00.8376620
VD>5000000
VD>00:00:00.2925531
VD>5000000
VD>00:00:00.7282637
VD>5000000
VD>


второй тест некорректен т.к. substring не делает.

вот результаты java. cpu = AMD Opteron 244 (1792.154Mhz). linux. jvm — sun, 1.5.0, 32bit.
используется только одно ядро, плюс надо бы сделать поправку на меньшую частоту камня...

$ java -server -Xmx512m -Xms512m -cp . Test08
5000000
1096.069
5000000
816.764
5000000
799.736
5000000
804.585
5000000
825.1
-------------
5000000
420.443
5000000
400.156
5000000
502.719
5000000
494.193
5000000
492.967



import java.io.*;
import java.util.*;

class Test08 {
    private static int test() {
        int answer = 0;
        final List<String> list = new ArrayList<String>();
        final String text = "123 345 asdf 23453 asdfas".intern();
        for (int i = 0; i < 1000000; i++) {
            list.clear();
            for (final StringTokenizer strtok = new StringTokenizer(text);
                strtok.hasMoreTokens(); list.add(strtok.nextToken())) ;
            answer += list.size();
        }
        return answer;
    }

    private static int test1() throws UnsupportedEncodingException {
        int answer = 0;
        final String [] array = new String[5];
        final String text = "123 345 asdf 23453 asdfas".intern();
        final byte space = " ".getBytes("windows-1251")[0];
        final byte [] chars = text.getBytes("windows-1251");
        final int clen = chars.length;

        for (int i = 0, l = 0; i < 1000000; i++, l = 0) {
            for (int c = 0, x = 0; c < chars.length; c++) {
                if (chars[c] == space) {
                    array[l++] = text.substring(x, c);
                    x = c + 1;
                } else if (c == chars.length - 1 && clen - x > 1) {
                    array[l++] = text.substring(x, clen);
                }
            }
            answer += l;
        }

        return answer;
    }

    public static void x() {
        long start = System.nanoTime();
        System.out.println(test());
        System.out.println((double)(System.nanoTime() - start) / 1.0e6);
    }

    public static void y() throws UnsupportedEncodingException {
        long start = System.nanoTime();
        System.out.println(test1());
        System.out.println((double)(System.nanoTime() - start) / 1.0e6);
    }

    public static void main(String [] args) throws UnsupportedEncodingException {
        for (int i = 0; i < 5; i++) x();
        System.out.println("-------------");
        for (int i = 0; i < 5; i++) y();
    }
}
Re[9]: pattern matching для питона :)
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.09.06 16:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Можно.
Только маленькое замечание: из-за ключевых сообщений, не может быть два одинаковых метода с разными списками параметров.

VD>Если это возможно, то второй вопрос. Как среда отделяет вызовы методов в случае когда например, объект передается в качестве параметра и не ясно что за тип будет у этого объекта?


/Я могу рассказать только за VW. С другими средами я недостаточно знаком./

Автоматически — никак. Появляется превью откуда можно удалить лишние методы. По практике, переименовать стандартный метод, например, с именем printString (то что toString() в java) — абсолютно нереально. Невозможно и переименовать какой-то метод в другой, если метод с новым именем уже есть выше в иерархии. Это единственное ограничение, которое меня реально бесило. А вот со своими собственными методами проблем возникает мало, из-за того как образуются имена методов в ST. То есть они скорее уникальны чем нет.

Броузер так-же содержит функцию "Spawn" которая умеет открывать броузер в котором виден только отдельный выбранный пакет или иерархия классов. Что удивительно, функции "find senders/find implementors" учитывают эту информацию и ищут только в пределах отображаемого пакета (или нескольких пакетов), а вот рефакторилка эту информацию игнорит. Подозреваю, что поддержка подобного ограничения области видимости удовлетворила бы всех вообще
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Синтаксический оверхед!
От: Андрей Хропов Россия  
Дата: 22.09.06 20:59
Оценка: 6 (1)
Здравствуйте, VladD2, Вы писали:

VD>for(mutable i = 0; i < 1000000; ++i)

VD> count += Parse.Split("123 345 asdf 23453 asdfas").Length;

А зачем такой синтаксический оверхед?

Надо
repeat(1000000)
    count += Parse.Split("123 345 asdf 23453 asdfas").Length;


или хотя бы

foreach(_ in $[1 .. 1000000])
    count += Parse.Split("123 345 asdf 23453 asdfas").Length;
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: BOOST, .NET, String.Split и производительность…
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.06 01:13
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Сама пенисометрия мне тоже по барабану. Мне больше интересно у которого варианта производительность выше, насколько и почему.


Очень похоже на строку из Двенадцати стульев: "Он бескорыстно любил деньги...".

На самом деле тут все очень просто. Языки имеющие компилирующий и оптимизирующий бэкнэнд позволяют написать подобный код с эффективностью близкой к ассемблерной реализации. Разницу до 1.5-2 раз могут составлять вычираемые компиляторами паттерны и качество оптимизации. Оптимальный вариант должен стараться избегать динамического выделения памяти, так как при таком объеме итераций (сентетическом, не реальным), это становится самым узким местом (что во всю присутствует в первом и последнем примере). Вторым узким местом будет использование виртульных методов (что во всю присутствует во втором моем примере). Но все это актуально если нет явных косяков вроде тех что опосредованно присуствуют в С++-коде.

Оптимальный с точки зрения быстродействия код обычно оказывается убогим и не красивым. Так что, как всегда за красоту приходится платить. Вот мне и интересно сколько стоит та самая красота. В бусте она оказалась неприемлемо дорга. А вот потери в дотнете изменяются в процентах, что лично мне кажется приемлемым.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Синтаксический оверхед!
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.06 01:13
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, VladD2, Вы писали:


VD>>for(mutable i = 0; i < 1000000; ++i)

VD>> count += Parse.Split("123 345 asdf 23453 asdfas").Length;

АХ>А зачем такой синтаксический оверхед?


АХ>Надо

АХ>
АХ>repeat(1000000)
АХ>    count += Parse.Split("123 345 asdf 23453 asdfas").Length;
АХ>


Чтобы у людей лишних вопросов не возникало. Откровенно говоря оверхэд в тестах меня не трогает. Намного интереснее как выглядит алгоритм. Вот явщик меня в этом смысле порадовал
Автор: n0name2
Дата: 22.09.06
. Он наверно думает, что доказал кому-то крутость Явы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.