Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Просто структуры данных питона очень плохо приспособленны для сопоставления с образцом.
VD>Не "просто", это одна из проблем. Почему ты думаешь при разговоре о паттерн-матчинге все время всплывают алгеброические типы данных (варинаты)? Именно потому, что они сделаны так чтобы по ним можно было делать сложный паттерн-матчинг. Но их наличие это еще не все. Еще нужен ээ... думатель (как точно подметил Ц-Смаил). Этот думатель должен преобразовать паттерн в набор логических предикатов. Это нехилый алгоритм. В Немерле его тупо скомуниздили из одной из реализаций ML-я. Его уже так на коленке не напишишь. Да и в рантайме его отрабатывать слишком накладно.
Я знаю (вернее уже почти забыл) как реализовано это в прологе(там вообще примитивно), это не так сложно как кажется. Вернее на порядки проще чем вывод типов. В общем вполне посильная задача.
FR>>Но в принципе решаемо вводом новых типов, с которыми сможет работать сопоставление (аналог variant из nemerle) и плюс адаптеров к встроенным спискам, туплам и т. п. Но это слишком трудоемко Поэтому мне пока более интересно возится с аналогами мультиметодов, они с одной стороны слабее pattern matching'а c другой наооборот мощнее.
VD>В принципе все решаемо. Только это будет уже не Питон, а Гюрза или еще что-то. И решать конечно такие вещи лучше на уровне компилятора, а не на уровне интепретируемого в рантайме метапрограммирования.
Ну эрланг вполне справляется, и в питоне в случае тормозов можно и на си кое что переписать.
Но вообще я пока такую бибилотеку писать не собираюсь, оно хоть и реально, но очень трудоемко
Меня пока устраивают и маленькие трюки типа этого "pattern matching".
VD>Пойми, паттерн-матчинг только выглядит просто. А внтри это довольно высокотезнологичные алгоритмы.
Здравствуйте, FR, Вы писали:
FR>Я знаю (вернее уже почти забыл) как реализовано это в прологе(там вообще примитивно), это не так сложно как кажется. Вернее на порядки проще чем вывод типов. В общем вполне посильная задача.
Насколько мне извесно паттерн-матчинг в Эрналге встроенный и написан не на Эрланге.
FR>Но вообще я пока такую бибилотеку писать не собираюсь, оно хоть и реально, но очень трудоемко
Вот и я о том же. А результат будет скорее всего не очень хорошим.
FR>Не совсем, по моему ты переусложняешь.
Исходники я привел. Причем это резуальтат достигнут с использованием того самого паттерн-матчинга. Без него все будет намного более объемно и сложно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: BOOST, .NET, String.Split и производительность…
Здравствуйте, VladD2, Вы писали:
VD> Особенноп риятно этот тест сравнивать с вот этоим произведением человеческой мысли .
Пардон. Забыл ссылку дать. Вот этот код мне больше всего понравился. Истенно в духе С++, т.е. пол лохунгом "зато быстро!". Re: Наколенный вариант 8-летней давности
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, McSeem2, Вы писали:
MS>>Влад, ты слова читать умеешь? Напомню, что в моем сообщении речь шла о неком другом случае, а не о split. На Линухе он не проверялся.
VD>О како таком другом случае? Я просто уже второй раз тут вижу, что проблемы в МС. Очень интересна эта теория. Люблю, знаете ли, теорию заговора.
Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.
Re[11]: BOOST, .NET, String.Split и производительность…
Здравствуйте, FR, Вы писали:
FR>Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.
Извини, а 1.5 раза и 30 раз проигрыша C#-e это сравненимые вещи? А под Линуксом что тормоизило?
А может это и правда заговор? Ну, МС специально подкупили всех писателей библиотек?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: BOOST, .NET, String.Split и производительность…
Здравствуйте, VladD2, Вы писали:
VD>Пардон. Забыл ссылку дать. Вот этот код мне больше всего понравился. Истенно в духе С++, т.е. пол лохунгом "зато быстро!". VD>Re: Наколенный вариант 8-летней давности
Если бы ты был чуть более внимательным, то заметил бы, что тот мой код (напомню — востмилетней давности) умеет еще выполнять trim по ходу дела, выделять токены в кавычках любого вида (аргумент "quote") с маскированием (аргумент mask_chr) и работать с тремя типами разделителей:
single — каждый символ является разделителем (1,,,2 выдаст "1" "" "" "2")
multiple — работает как strtok (1,,,2 выдаст "1" "2")
whole_str — разделителем является вся строка
Все это не нужно в рамках задачи данного треда, но при этом и не мешает. Просто я наивно расчитывал на наличие у тебя некоторых зачатков разума.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: BOOST, .NET, String.Split и производительность…
Господа, ну ей богу как дети малые. Ну выводите вы в единых попугаях значения. Например в % от производительности на тестовой платформе самого первого приведенного исходника. Потому как понять, что быстрее — приведенный код на немерлях или написанный на коленке код на языке ЗЮ, если у меня нет немерле?
А то скучно за вашими писькомерянием наблюдать когда не видно у кого короче
ЗЫ: Все считать стёбом (Коим он собстна и является), кроме предложения "унифицировать" оценку производительности алгоритмов
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: BOOST, .NET, String.Split и производительность…
Здравствуйте, 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 и производительность…
CC>Господа, ну ей богу как дети малые. Ну выводите вы в единых попугаях значения. Например в % от производительности на тестовой платформе самого первого приведенного исходника.
А как ты себе это видишь? Вообще-то тест 3 у меня как раз дотнетный сплит. Так что процент можешь посчитать сам.
За одно можно сделать вывод, что 30% производительности легко заменяются 30% стоимости процессора.
CC> Потому как понять, что быстрее — приведенный код на немерлях или написанный на коленке код на языке ЗЮ, если у меня нет немерле?
На самом, деле на Немерле можно написать код 1 в 1 и даже чуть быстрее чем версия из библоиотеки. Но какой смысл доказвать, что джит работат (просто работает)?
CC>А то скучно за вашими писькомерянием наблюдать когда не видно у кого короче
Откровенно говоря эта пенисометрия меня не волоновала. Меня интересовало насколько велик оверхэд у функционального подхода и итераторов. Ведь писать с их использованием иногда намного приятнее. И если это не так уж дорого стоит, то почему бы и нет. Самый разфункциональный варинт показал скорость куда выше чем тормоза на С++ (те что с библиотекой, а не с хардкодингом). Если мне захочется написать действительно максимально быстрый вариант, то я его напишу. Но он будет менее красив чем эти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: BOOST, .NET, String.Split и производительность…
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Там на самом деле частично виноват ms только не писатели операционки, а те кто писал рантайм к VC. Поэтому та же первоначальная версия теста откомпилированная со STLPort отрабатывает в полтора раза шустрее.
VD>Извини, а 1.5 раза и 30 раз проигрыша C#-e это сравненимые вещи? А под Линуксом что тормоизило?
Это уже проблемы бустовцев, как умудрились не знаю, мне некогда серъезно разбиратся.
Ну а проблема со строками в рантайме VC это уже вина ms, это тоже надо умудрится лазить без повода в ядро.
VD>А может это и правда заговор? Ну, МС специально подкупили всех писателей библиотек?
Они еще тестерам на линуксе мозги затуманивают так что нолик лишний пропадает
Re[4]: BOOST, .NET, String.Split и производительность…
Здравствуйте, 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 и производительность…
Здравствуйте, 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++ не так уж и страшен:
Здравствуйте, 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 и производительность…
Здравствуйте, Denis2005, Вы писали:
D>Доброго времени суток!
D>Понадобилось 'посплитить' строки (вообще задача более сложная, но обо всем по порядку), и по совету “мудрых старцев” (которые по новомодной традиции, при каждом чихе отправляют к boost-у) решил потестировать производительность boost::algoruthm:split.
D>Честно говоря, результаты меня обескуражили…
на сколько я понял очень много жрёт split_iterator который наследуется от find_iterator_base который в свою очередь принимает предикат который внутри хранится... Внимание! вот таким вот образом
вот результаты java. cpu = AMD Opteron 244 (1792.154Mhz). linux. jvm — sun, 1.5.0, 32bit.
используется только одно ядро, плюс надо бы сделать поправку на меньшую частоту камня...
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();
}
}
Здравствуйте, VladD2, Вы писали:
VD>Правильно ли я понял эти строки, что можно переименовывать только все методы с одинаковым мменем во всех классах одновременно? Или все же можно изменить имя метода в одном классе и оставить без изменений другие методы с тем же именем и списком параметров?
Можно.
Только маленькое замечание: из-за ключевых сообщений, не может быть два одинаковых метода с разными списками параметров.
VD>Если это возможно, то второй вопрос. Как среда отделяет вызовы методов в случае когда например, объект передается в качестве параметра и не ясно что за тип будет у этого объекта?
/Я могу рассказать только за VW. С другими средами я недостаточно знаком./
Автоматически — никак. Появляется превью откуда можно удалить лишние методы. По практике, переименовать стандартный метод, например, с именем printString (то что toString() в java) — абсолютно нереально. Невозможно и переименовать какой-то метод в другой, если метод с новым именем уже есть выше в иерархии. Это единственное ограничение, которое меня реально бесило. А вот со своими собственными методами проблем возникает мало, из-за того как образуются имена методов в ST. То есть они скорее уникальны чем нет.
Броузер так-же содержит функцию "Spawn" которая умеет открывать броузер в котором виден только отдельный выбранный пакет или иерархия классов. Что удивительно, функции "find senders/find implementors" учитывают эту информацию и ищут только в пределах отображаемого пакета (или нескольких пакетов), а вот рефакторилка эту информацию игнорит. Подозреваю, что поддержка подобного ограничения области видимости удовлетворила бы всех вообще
Здравствуйте, CreatorCray, Вы писали:
CC>Сама пенисометрия мне тоже по барабану. Мне больше интересно у которого варианта производительность выше, насколько и почему.
Очень похоже на строку из Двенадцати стульев: "Он бескорыстно любил деньги...".
На самом деле тут все очень просто. Языки имеющие компилирующий и оптимизирующий бэкнэнд позволяют написать подобный код с эффективностью близкой к ассемблерной реализации. Разницу до 1.5-2 раз могут составлять вычираемые компиляторами паттерны и качество оптимизации. Оптимальный вариант должен стараться избегать динамического выделения памяти, так как при таком объеме итераций (сентетическом, не реальным), это становится самым узким местом (что во всю присутствует в первом и последнем примере). Вторым узким местом будет использование виртульных методов (что во всю присутствует во втором моем примере). Но все это актуально если нет явных косяков вроде тех что опосредованно присуствуют в С++-коде.
Оптимальный с точки зрения быстродействия код обычно оказывается убогим и не красивым. Так что, как всегда за красоту приходится платить. Вот мне и интересно сколько стоит та самая красота. В бусте она оказалась неприемлемо дорга. А вот потери в дотнете изменяются в процентах, что лично мне кажется приемлемым.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Чтобы у людей лишних вопросов не возникало. Откровенно говоря оверхэд в тестах меня не трогает. Намного интереснее как выглядит алгоритм. Вот явщик меня в этом смысле порадовал