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

CC>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Хм, а при чем тут UTF8 ? Я ведь программу писал для Юникода, а не для UTF8! Для того Юникода, в котором на каждый символ ровно по 2 байта, а в начале стоит FEFF. Естественно, на UTF8 я не рассчитывал.
CC>Т.е. для UTF16 если его BOM = FEFF. Вот только незадача, у UTF16 символ может состоять из более чем 1 WORD-a. Двубайтовый "Уникод" с одним словом на символ это упрощенная (устаревшая) версия и называется UCS2. Работать с ней правда гораздо удобнее...

Именно ее я и имел в виду. Ее делает Notepad, если его попросить сохранить в Unicode. Ее же использует regedit при экспорте по умолчанию и т.д.

CC>Воскуривать тут http://en.wikipedia.org/wiki/UCS2

Спасибо за ссылку.

CC>Ну а полноценный Unicode это UTF32.

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

PD>Это можно и без библиотек сделать. Помню втык, который я устроил одному студенту за транспонирование квадратной матрицы. Он для этого новую матрицу создал .
PD>Но вот для этого преподаватель и нужен. Чтобы сказал — так не делают, ищи решение получше. А когда перед глазами лишь фреймворк

Ох, Павел, учись я у Вас, был бы круглым двоечником Лично мне ближе позиция студента. Раз уж пошли примеры из жизни, приведу и я один.

К нам обратилась одна фирма, занимающаяся продажей неких товаров. От поставщиков им приходят прайсы, причём часто либо набранные ручками, либо неизвестно откуда (хотя подозреваю, что из 1С) экспортированные. Разброд полный, но прайсов много и ручками их не обработаешь. Была у этой фирмы какая-то прога на делфи, котоая жутко тормозила, и очень неэффективно работала. Чтобы объяснить почему, расскажу, как вообще она работает. Среди характеристик, которые надо выделять, есть такие, которые принимают одно значение из какого-либо конечного множества (такие характеристики описаны в базе знаений, которую пополняет пользователь). Например, таковыми являюся фирма-производитель, название модели и т.п (причём обратите внимание — наименований моделей может быть несколько тысяч, может быть, несколько десятков тысяч). Остальные характеристики выделяются как-то кривовато, по какому-то подобию шаблона. Короче, работало медленно и неэффективно.

Когда это дело пришло к нам, я вот на что сразу обратил внимание. Как выделить из ячейки прайс-листа, скажем, название модели? Думаю, самый разумный подход — регулярные выражения, причём это ещё и самый гибкий подход (можно искать не в точности такую же строку, а "приближённо такую же"). Регулярные выражения в типовых библиотеках работают на бэктрекинге, реже — на НКА, и только в TCL применён хитрый гибридный подход, что позволяет, в частности, делать неплохой subpattern addressing. Т.е. будем долго искать. Если же генерить ДКА то возникает обратная проблема — долго генерятся А ведь регулярное выражение для модели даже в "лучшем" случае — это model1 | model2 | .. | model9999. Т.е. состояний действительно дофига. Ко всему этому надо ещё добавить поддержку unicode.

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

Далее, конечно же, на каждого поставщика пишется шаблон. В шаблоне помимо регулярных выражений ещё куча всего. Так вот: я совершенно не заботился по поводу какой-либо сериализации данных. Т.е. при каждом считывании данные честно парсятся XML-парсером, текстовое содержимое парсится парсерами моих DSL-ей и т.п. AST и DOM даже и не думают сериализоваться/десериализоваться. А всё потому, что размер типового шаблона — 5-10Кб. И вряд ли когда-то станет 100Кб или тем более 100Мб. И парсятся эти шаблоны в общей сложности меньше секунды (на 100 шаблонов). Зато при каждой "синхронизации с БЗ" (так обозван процесс перегенерации ДКА) приходится ждать секунд 40. Спрашивается: оно мне надо было оптимизировать, чтобы снизить время ожидания на 2-3 сек? Кроме того, данные между гридом, где всё это выводится и обработчиком передаются жутко неэффективно, всюду копируются, хранятся в в структурах типа List и Dictionary, которые, как известно, жрут памяти поболее, чем им реально нужно. Ну и что? У меня одни только ДКА отжирают 90Мб. Лишние 2-3 Мб-не проблема.

PS: А история собиралась уже было закончиться хэппиэндом — на обработку одного прайса уходило менее 1 сек, так что была сделана, в отличие от предыдущего продукта, итерактивная обработка. Но потом мне вздумалось приделать недетерминированный поиск (чтобы решить некоторые проблемы и повысить качество обработки). Так вот теперь уже на один прайс может уходить от 5 до 60 сек. Придётся мне опять днями и ночами сидеть в профайлере, а так же придумывать эвристики, чтобы обрубать ветки дерева решений.

PPS: А если бы я ещё и на месте данные преобразовывал, не копируя, то даже боюсь представить, сколько времени у меня уходило бы на выявление глюков... Да и разобраться в этой махине, где что-то куда-то передаётся и там мутируется... Нет уж, лучше убить себя об стену

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

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

FR>>У меня кстати работала, но я что-то на автомате подправил, что не помню

PD>А время не замерил ? Интересно бы узнать. Вообще-то оно еще и от диска зависит, но для этого надо файл размером в сотню Мб взять, 0.015 — слишком мало для выводов.

Лучше не спрашивай

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

CC>>И затраты на вызовы хавают почти весь выигрыш?
SH>Аналогичный вопрос для асма: и вызов функции (параметры в стек, сброс конвейера) сожрут весь выигрыш?
В C++ для передачи параметров ассемблерной вставке далеко не всегда надо бросать что либо в стек и уж точно не нужно делать сброс конвейера (ЛОЛ!!!)

SH>Нет, просто надо знать что, где и как оптимизировать.
Разумеется. Та куча кода, через которую пройдет COM вызов мне лично кажется достаточно толстой, чтоб перекрыть не очень большую асм вставку.

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

CC>>ICC 10.1.x ?
SH>Если мне ничего не изменяет, пользоваться SSE для того, чтобы обрабатывать одновременно несколько операндов он тоже не умеет. А именно тут заложен основной выигрыш.

Сам — нет. Слишком навороченная уж должна быть логика анализа С++ кода для такого рода оптимизаций
Зато предоставляет очень удобные интринзики для использования SSE

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

CC>>Ну, под разные задачи, в разное время созданные, с разным рантаймом.
SH>Отлично! Ты тоже с этим согласен.
Трудно не согласиться с фактами. Вот только видим похоже мы с тобой в них несколько разное.
SH> И я тоже считаю, что "под разные задачи, в разное время созданные".

SH>И считаю, что время изменилось и теперь задачи C# более актуальны.
Отнюдь. Задач добавилось. И для определенного круга задач С# стал более удобным чем то, что уже имелось. Собственно потому он и появился — как реакция на появление и рост того самого круга задач.

SH> И что время C++ потихоньку уходит.
Ты посчитай сколько лет оно уже все "уходит"

Ты смотришь со своей колокольни. И видишь рядом с собой те задачи, которыми ты занимаешься. И для которых лучше подходит не С++.
Где то дальше стоит колокольня Павла, и он с нее видит свои задачи, много и отчетливо. Для них классно подходит С++. Твои же задачи видны где то далеко и потому мелкие. Ну и наоборот.
Понятно изложил?

SH> И не понимаю, как ты, придерживаясь того же мнения можешь отстаивать преимущества С++.
Ох ёлы палы. Ты слеп, камрад.
Вот моё мнение, которого я придерживаюсь:

Каждый инструмент лучше всего подходит для решения определенного рода задач — раз
У каждого инструмента есть недостатки, которые делают его непригодным для решения некоторого круга задач — два
Нет инструмента, который бы решал все задачи — три
Для достижения максимальной выгоды часто приходится использовать несколько инструментов — четыре

Я отстаиваю то, что С++ лучше подходит для решения определенного круга задач. Ты же походу утверждаешь что С++ уже почти ни на что не годен, а С# рулит везде.

SH>Конечно, есть области, где C# отстанет. Но если он покрывает 99%..
Он никогда не покроет 99%. По множеству причин.
Равно как никакой другой язык.
В лучшем случае по грубой оценке — половину задач.
Но 99% — нереально.

CC>>Ждем выхода следующей ревизии С++.
SH>Жди. Я уже не жду.
Появится — посмотрим.
До этого момента — нет смысла булькать в лужу...

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

CC>В C++ для передачи параметров ассемблерной вставке далеко не всегда надо бросать что либо в стек

Не всегда. Только когда оптимизатору не доступен весь проект. Например, если ты пишешь dll, lib или что-то подобное.

CC>и уж точно не нужно делать сброс конвейера (ЛОЛ!!!)

Это происходит само, если переход предсказан неправильно.

CC>Разумеется. Та куча кода, через которую пройдет COM вызов мне лично кажется достаточно толстой, чтоб перекрыть не очень большую асм вставку.

Читаем мой ответ Павлу на эту же тему.

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

CC>Ты смотришь со своей колокольни. И видишь рядом с собой те задачи, которыми ты занимаешься. И для которых лучше подходит не С++.

Я занимаюсь очень разными задачами. Но если оценивать в процентах, причём не по моему опыту, а шире, то окажется, что мест, где актуален С++ осталось очень немного. Только те, где критична производительность/память.

CC>Каждый инструмент лучше всего подходит для решения определенного рода задач — раз
CC>У каждого инструмента есть недостатки, которые делают его непригодным для решения некоторого круга задач — два
CC>Нет инструмента, который бы решал все задачи — три
CC>Для достижения максимальной выгоды часто приходится использовать несколько инструментов — четыре

CC>Я отстаиваю то, что С++ лучше подходит для решения определенного круга задач. Ты же походу утверждаешь что С++ уже почти ни на что не годен, а С# рулит везде.

Я чуть выше обозначил область работы C++. Можешь свой вариант написать?
А С# тут просто для примера. Я на нём даже не писал почти

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

SH>Не, ты не понял. Я не рекомендую на C# решать задачи, в которых нужен SSE. Я указал на способ повышения производительности — обращение к более подходящему для задачи языку, и на то, что C++ этот способ тоже использует.
В С++ нет надобности использовать медленный COM механизм для вызова ассеблерного кода.

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

K>Ох, Павел, учись я у Вас, был бы круглым двоечником

Не думаю. Пару раз не принял бы, ну и все — сделал бы все как следует .

>Лично мне ближе позиция студента. Раз уж пошли примеры из жизни, приведу и я один.

>Зато при каждой "синхронизации с БЗ" (так обозван процесс перегенерации ДКА) приходится ждать секунд 40. Спрашивается: оно мне надо было оптимизировать, чтобы снизить время ожидания на 2-3 сек?

Нет , не надо. А может, надо разбираться с перегенерацией БЗ. Хотя черт тут знает. У меня тоже была собственная БД , генерация которой шла 5 часов, при том. что я оптимизировал под не могу. Но время там не лимитировало, перегенерация производмлась один раз в полгода.

>Кроме того, данные между гридом, где всё это выводится и обработчиком передаются жутко неэффективно, всюду копируются, хранятся в в структурах типа List и Dictionary, которые, как известно, жрут памяти поболее, чем им реально нужно. Ну и что? У меня одни только ДКА отжирают 90Мб. Лишние 2-3 Мб-не проблема.

Значит, не надо было оптимизировать. Или надо было — эти самые List и Dictionary или передачу данных.

K>PS: А история собиралась уже было закончиться хэппиэндом — на обработку одного прайса уходило менее 1 сек, так что была сделана, в отличие от предыдущего продукта, итерактивная обработка. Но потом мне вздумалось приделать недетерминированный поиск (чтобы решить некоторые проблемы и повысить качество обработки). Так вот теперь уже на один прайс может уходить от 5 до 60 сек.

Ну тогда надо понять, что там творится с этим недетерминированным поиском.

>Придётся мне опять днями и ночами сидеть в профайлере, а так же придумывать эвристики, чтобы обрубать ветки дерева решений.

Наверное.

Я, в общем-то, почти со всем согласен. Конечно, не надо оптимизировать то, что не имеет смысла оптимизировать. Если это 100% знать заранее со 100% надежностью. Но это не значит, что надо писать как бог на душу положит, взять первое попавшееся решение, не проанализировав его, и применить. Потому что если такое делать, то и профайлер не поможет, так как тормозить в конечном счете будет все . Поэтому все же без надобности писать что бог на душу положит я не стал бы. В конце концов, рассмотрим опять пример с чтением строки из файла. IT предложил код, на написание которого уйдет 2 минуты. Я свой код писал 30 минут (когда-то, сейчас я его просто оттуда вытащил, а сделал бы тогда класс — тоже в 2 минуты уложился бы). Ну и что, это принципиально ? Зато я точно знаю — здесь тормозить не будет. Здесь я выжал все, что можно. Хотите — в цикл вставляйте, что хотите делайте, лучше не будет (я так думаю . И все, я об этом забыл, есть другие проблемы. Это — o(1) по сравнению с другим.

А у IT однажды этот код в одну строчку боком выйдет...

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

Вот здесь, между прочим, собака отчасти и зарыта. Когда в проекте почти одни только стандартные действия (классический пример — web-сайты — юзеровский ввод/вывод (HTML), ввод/вывод с диска (БД) + логика на уровне расширенного поиска плюс арифметика на уровне 6 класса средней школы + 5 запросов пользователя в минуту + 5 пользователей одновременно максимум , то действительно, можно писать что бог на душу положит, поскольку тут не Pentium-4 нужен, а и Pentium -1 с 32 Мб сойдет. Беда же в том, что адепты этого web-программировния пытаются перенести эти принципы на все остальное, и тем самым калечат неокрепшие души студентов

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

FR>Лучше не спрашивай

Не понял. Что, в 0.015 не уложилась ?

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

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

FR>>Лучше не спрашивай

PD>Не понял. Что, в 0.015 не уложилась ?

Да нет я подумал ты о скорости питоновского варианта спрашивал
Я уже не помню сейчас под рукой нет, но цифры с 0.0... были, питон раз в 15 медленее.

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

Извиняюсь за вмешательство не в свой тред...

SH>Я занимаюсь очень разными задачами. Но если оценивать в процентах, причём не по моему опыту, а шире, то окажется, что мест, где актуален С++ осталось очень немного.

Почти все десктопное ПО как писали на C++, так и пишут.

Я тут не раз проводил голосование о том, сколько десктопных приложений на C# установлено на машине. У большинства — до 5 всего лишь.

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

CC>>В C++ для передачи параметров ассемблерной вставке далеко не всегда надо бросать что либо в стек
SH>Не всегда. Только когда оптимизатору не доступен весь проект. Например, если ты пишешь dll, lib или что-то подобное.
Вызов в DLL гораздо дешевле вызова через COM
lib же влинкуется в проект — оверхэд почти нулевой.

CC>>и уж точно не нужно делать сброс конвейера (ЛОЛ!!!)
SH>Это происходит само, если переход предсказан неправильно.
это только в случае conditional jump. Остальные варианты не рассматриваем, т.к. их в прикладном коде быть не должно.

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

CC>>Ты смотришь со своей колокольни. И видишь рядом с собой те задачи, которыми ты занимаешься. И для которых лучше подходит не С++.
SH>Я занимаюсь очень разными задачами. Но если оценивать в процентах, причём не по моему опыту, а шире, то окажется, что мест, где актуален С++ осталось очень немного. Только те, где критична производительность/память.

SH>Я чуть выше обозначил область работы C++. Можешь свой вариант написать?
Я бы сказал, где важна производительность и потребление ресурсов.
Потребление ресурсов по мне так важно везде. Потому как если маленькая утилита хавает 30 метров private bytes — это просто не приемлемо. Для большой проги, которая делает много чего и является основной рабочей средой на компе — есть много и думать долго еще можно простить. Но для тула помельче, если к примеру это не АРМ а какой нить утиль типа офиса — потребление ресурсов должно быть оправданным — столько сколько реально необходимо. Потому как мы все пользуемся многозадачными ОС в которой может быть запущено много разных процессов. И когда каждый из них начинает жрать сколько ему вздумается — это уже бардак.

Самое интересное, что начали то с того, что плохо когда "пофиг как работает зато я решаю это одной строкой"

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

PD>read = 56, а len почему-то 512, цикл выполняется один раз. Я что-то не так делаю ?

что б те было спокойнее

            using (FileStream fs = File.OpenRead("D:\\Пример2.txt"))
            {
                int read = 0;
                byte[] b = new byte[1024];
                while ((read = fs.Read(b, 0, b.Length)) > 0)
                {
                    string str = Encoding.Unicode.GetString(bytes, 0, read);
                    int len = str.Length;
                    Console.WriteLine(len);
                }
            }

PD>И , кстати, маленький вопрос. Что здесь будет, если длина строки окажется больше 512 символов (1024 байт) ?

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

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

PD>Я тут не раз проводил голосование о том, сколько десктопных приложений на C# установлено на машине. У большинства — до 5 всего лишь.
К примеру у меня кроме йануса можно только MSVC причислить — в нем части на дотнете...
И всё.
При этом к производительности и потреблению памяти янусом у меня много претензий. (Private: 68 Mb, Working set: 49 Mb, Virtual 715 Mb)

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

SH>>Я занимаюсь очень разными задачами. Но если оценивать в процентах, причём не по моему опыту, а шире, то окажется, что мест, где актуален С++ осталось очень немного. Только те, где критична производительность/память.

SH>>Я чуть выше обозначил область работы C++. Можешь свой вариант написать?
CC>Я бы сказал, где важна производительность и потребление ресурсов.

Так, а теперь мы будем спорить, что нам важнее — производительность, поддерживаемость, скорость написания?
Понятно, что важен баланс. Понятно, что за счёт роста мощностей и прогресса в компиляторах, он постепенно смещается от ассемблера (одна крайность) к скриптам (другая крайность). На мой взгляд, С++ как язык реализации сейчас уже редко является разумным выбором. Что, конечно не мешает многим его использовать.

CC>Потребление ресурсов по мне так важно везде. Потому как если маленькая утилита хавает 30 метров private bytes — это просто не приемлемо.

Маленькая утилитка пишется на Питоне и хавает немеряно байт и процессора. Но, тем, не менее, это гораздо, гораздо удобнее, чем писать её на C++.

CC>Самое интересное, что начали то с того, что плохо когда "пофиг как работает зато я решаю это одной строкой"

Это не я писал. Игорь высказался очень неаккуратно, предоставлю ему защищаться самому.

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

SH>>>Я чуть выше обозначил область работы C++. Можешь свой вариант написать?
CC>>Я бы сказал, где важна производительность и потребление ресурсов.
SH>Так, а теперь мы будем спорить, что нам важнее — производительность, поддерживаемость, скорость написания?
Это ты куда то в сторону от дискуссии отходишь. Мы говорим про вотчину С++. При наличии необходимых качественных библиотек и вменяемых программистов скорость написания и поддерживаемость будут на уровне. Вопрос в том, что нужны эти самые библиотеки и программисты.
Впрочем при отсутствии нужных библ и наличии только тупых быдлокодеров проект на С# будет тормозной, неподдерживаемый и долгоразрабатываемый.
Так что пришли к тому, что дело не столько в том, на каком языке. Дело в том, как на этом самом языке. Т.е. дело в людях.

CC>>Потребление ресурсов по мне так важно везде. Потому как если маленькая утилита хавает 30 метров private bytes — это просто не приемлемо.
SH>Маленькая утилитка пишется на Питоне и хавает немеряно байт и процессора. Но, тем, не менее, это гораздо, гораздо удобнее, чем писать её на C++.
Я в первую очередь имел в виду не одноразовое — запустил, отработало и все — а софт более длительного времени интерактивного использования.
Если эта маленькая утилитка мне нужна достаточно часто и работает при этом медленнее чем С++ аналог — я лучше напишу аналог на С++, пусть это будет мне менее удобно в процессе написания.

SH>Это не я писал. Игорь высказался очень неаккуратно, предоставлю ему защищаться самому.
Гм. Эт я не обратил внимания что автор другой.

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

CC>Это ты куда то в сторону от дискуссии отходишь. Мы говорим про вотчину С++. При наличии необходимых качественных библиотек и вменяемых программистов скорость написания и поддерживаемость будут на уровне. Вопрос в том, что нужны эти самые библиотеки и программисты.
CC>Впрочем при отсутствии нужных библ и наличии только тупых быдлокодеров проект на С# будет тормозной, неподдерживаемый и долгоразрабатываемый.
CC>Так что пришли к тому, что дело не столько в том, на каком языке. Дело в том, как на этом самом языке. Т.е. дело в людях.



А чего тогда не на ассемблере? Люди же важнее! Действительно, найдём классных программеров, которые напишут нам Янус на асме.



Да, я опять преувеличиваю. Разница между C++ и C# меньше чем между C++ и ассемблером. Но тем не менее, есть что-то и в языках. И в библиотеках. Библиотеку для работы на асме с SOAP найти очень сложно. На C++ — довольно легко. Но на C# она входит в стандартный комплект — не надо ни искать, ни устанавливать.

CC>Я в первую очередь имел в виду не одноразовое — запустил, отработало и все — а софт более длительного времени интерактивного использования.
CC>Если эта маленькая утилитка мне нужна достаточно часто и работает при этом медленнее чем С++ аналог — я лучше напишу аналог на С++, пусть это будет мне менее удобно в процессе написания.

А так же в процессе поддержки, исправления ошибок и добавления фич. И всё это будет верно только если ты это "медленнее" замечаешь. И оно не теряется на фоне ещё более медленного чего-то там. И если переписать на C++ реально по трудоёмкости.

На питоне тоже можно писать интерактивные приложения. Они будут к тому же кроcсплатформенными и исходного кода будет меньше, чем на C++. Я вот недавно писал утилитку на Питоне. 3 месяца писал вдвоём с коллегой. Я не возьмусь повторить это на C++ в обозримые сроки — очень долго получится.

И, хотя проблемы с производительностью были, они оказались в графической библиотеке PyQt4, которая опиралась на неудачную реализацию Qt4 (там работа со стилями тормозит), которая написана .. на C++ В следующем релизе Qt, возможно, исправят.