Здравствуйте, rg45, Вы писали:
R>Я не пойму, ты правда такой или прикидываешься? Речь о двух С++ примерах — один мой, второй твой — тот, который в пять раз медленнее, который упоминался в стартовом сообщении. Этого примера так никто и не видел до сих пор. Как, интересно, ты понял высказывание
Здравствуйте, rudzuk, Вы писали:
r>> R>Ты принес на форум, заявив, что оно в два раза быстрее шарпа
r>> И?
R>Это не совсем для "себя". Не, я понимаю желание уделать шарп, но, блин, уделывай на общих условиях.
Я всего лишь выложил код и результаты замеров времени прогона. Это медицинские факты. Я так же сделал определенные выводы — для себя. Я ими поделился, но никому ничего не навязываю. Хочешь принимай, хочешь, нет. Не пойму, что ты от меня требуешь. Я ж в долги вроде не влезал.
--
Re[22]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>Один из возможных подходов — отсутствие обработки ошибок. В этом случае просто описываются прекондишены, которые обязан обеспечить программист, в противном случае — behavior is undefined и досвидос.
Перекладываешь затраты на других? Грешновато.
R>В стандартной библиотеке навалом таких функций — тот же memcpy, например.
Вообще ничего общего.
Ад пуст, все бесы здесь.
Re[19]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C>Перекладываешь затраты на других? Грешновато.
Я не говорю, что делать нужно именно так. Но так делают иногда, в т.ч. по соображениям производительности. Иногда опасная но быстрая функция оказыется востребованнее тормознутого монстра со встроенными памперсами.
Здравствуйте, rg45, Вы писали:
R>Это был ответ всего лишь на твое хамство, завуалированное под высказывание мудреца.
Э, нет. Ты сам начал раскидываться высосанными из пальца обвинениями, на что я и указал.
R>В реальной жизни я бы тебе не позволил безнаказанно так себя вести, уверяю тебя. Ты злоупотребляешь своей безнаказанностью.
Ну а твои угрозы — это так и надо, всё правильно. Видимо, в жизни тебе пока что везло.
Ад пуст, все бесы здесь.
Re[14]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>P.S. Заглянул в майкрософтовскую реализацию std::from_chars. Если в двух словах — это жопа. На какое там быстродействие можно надеяться, я х.з.
Ну раз так, то интересно посмотреть что иожет выдать какая-нибудь другая реализация.
Ад пуст, все бесы здесь.
Re[15]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали:
R>1. Итерация символов требует несколько проверок последовательностей (4), вместо единственной в UTF-16;
О каких проверках речь? На практике в 90% случаем обработка UTF-8 строк почти не отличается от таковой же в ASCII. Если мы итерируемся именно по символам, то символы в Юникоде в общем виде могут занимать несколько кодпоинтов, идти справа на лево, даже в UTF-32, так что не надо упрощать.
R>2. Все что за пределами ascii кодируется, либо тем же количеством байт, что и в UTF-16, либо большим.
Зависит от данных и статистики. На практике, многие многих форматы (Code, JSON, XML и т.д.) и наиболее распространенные языки будут занимать меньше.
R>3. В UTF-16 почти все что нужно лежит в пределах BMP (т.е. суррогатная пара не требуется), а значит такие строки могут иметь индексный доступ.
Что нужно ?! В Юникоде куча символов может состоять из нескольких кодпоинтов, независимо от суррогатных пар, и это в любой кодировке: UTF-8/16/32.
Re[22]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
r> R>Это не совсем для "себя". Не, я понимаю желание уделать шарп, но, блин, уделывай на общих условиях.
r> Я всего лишь выложил код и результаты замеров времени прогона. Это медицинские факты. Я так же сделал определенные выводы — для себя. Я ими поделился, но никому ничего не навязываю. Хочешь принимай, хочешь, нет. Не пойму, что ты от меня требуешь. Я ж в долги вроде не влезал.
Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.
Здравствуйте, Videoman, Вы писали:
V> О каких проверках речь? На практике в 90% случаем обработка UTF-8 строк почти не отличается от таковой же в ASCII. Если мы итерируемся именно по символам, то символы в Юникоде в общем виде могут занимать несколько кодпоинтов, идти справа на лево, даже в UTF-32, так что не надо упрощать.
Итеририровать кодпоинты. В utf-8 четыре проверки, в utf-16 — одна. Вопрос нормализации выносим за скобки т.к. он существует вне зависимости от кодировки.
V> R>2. Все что за пределами ascii кодируется, либо тем же количеством байт, что и в UTF-16, либо большим.
V> Зависит от данных и статистики. На практике, многие многих форматы (Code, JSON, XML и т.д.) и наиболее распространенные языки будут занимать меньше.
Я вроде согласился, что как кодировка для сериализации utf-8 удобна, но мы говорим о хранении и обработке строк. При хранении той же кириллицы от utf-8 профита никакого, при хранении китайских иероглифов utf-8 еще и более требовательна к памяти. Единственный выигрыш это латиница.
V> R>3. В UTF-16 почти все что нужно лежит в пределах BMP (т.е. суррогатная пара не требуется), а значит такие строки могут иметь индексный доступ.
V> Что нужно ?! В Юникоде куча символов может состоять из нескольких кодпоинтов, независимо от суррогатных пар, и это в любой кодировке: UTF-8/16/32.
Я о том, что кодпоинты вне BMP это эмоджи и прочее.
Здравствуйте, rudzuk, Вы писали:
R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.
Ну это грубые оценки, я ж этого и не скрывал. Лично для меня очевидно, что сделать плюсовую реализацию более быстрой, чем сишарпную реально. Если кто-то с этим не согласен — пожалуйста, спорить не стану. Вы импеете право на свое мнение, я — на свое.
--
Re[21]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C>memcpy не работает с внешними данными, в отличие от.
memcpy возлагает на программиста ответсвенность за корректность переданных данных. И если программист не обеспечил эти требования, тогда "behaviour is undefined" — это сказано в спецификации к функции. И те данные, которые передает программисты для функции являеются внешними (сформированными извне).
--
Re[23]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали: R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.
Ну пожалуйста, добавляю контроль корректности входной последовательности:
C++ 840 ms
#include <iostream>
#include <vector>
#include <string>
#include <chrono>
#include <random>
std::vector<std::wstring> MakeIntSequence(int size)
{
std::random_device rd; //Will be used to obtain a seed for the random number engine
std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
std::uniform_int_distribution<> distrib(0, std::numeric_limits<int>::max());
std::vector<std::wstring> v;
v.reserve(size);
for (int i = 0; i < size; ++i)
{
v.push_back(std::to_wstring(distrib(gen)));
}
return v;
}
int ParseInt(const std::wstring& wstr)
{
int res{};
for (auto d : wstr)
{
if ('0' <= d && d <= '9')
{
res = res * 10 + d - '0';
}
else
{
throw std::out_of_range("'" + std::to_string(d) + "': Symbol is out of range");
}
}
return res;
}
int main()
{
namespace tm = std::chrono;
const auto vals = MakeIntSequence(0x4000000);
const auto t0 = tm::steady_clock::now();
int hash{};
for (const auto& val : vals)
{
hash ^= ParseInt(val);
}
const auto dt = tm::duration_cast<tm::milliseconds>(tm::steady_clock::now() - t0);
std::cout << "Hash = " << std::hex << hash << std::endl;
std::cout << "Processing time: " << std::dec << dt.count() << "ms" << std::endl;
}
Уже быстрее C#. При том, что возможности по оптимизации не исчерпаны. Если использовать таблицы и обрабатывать сотнями-тысячами будет еще заметное ускорение.
Вопросы?
--
Re[25]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C>Э, нет. Ты сам начал раскидываться высосанными из пальца обвинениями, на что я и указал.
То есть, любой неудобный вопрос — это обвинение. Понятно. Но, в любом случае, я тебе не хамил.
C>Ну а твои угрозы — это так и надо, всё правильно. Видимо, в жизни тебе пока что везло.
Во-первых, никакие это не угрозы, просто объясняю тебе сидуацию. Во-вторых, не было бы твоего хамства, не было бы моих "угроз".
--
Re[22]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>memcpy возлагает на программиста ответсвенность за корректность переданных данных. И если программист не обеспечил эти требования, тогда "behaviour is undefined" — это сказано в спецификации к функции. И те данные, которые передает программисты для функции являеются внешними (сформированными извне).
Данные, которые ты получаешь для парсинга — от пользователя. Никаких гарантий по их корректности никакой другой программист за тебя не обеспечит.
Ад пуст, все бесы здесь.
Re[26]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>То есть, любой неудобный вопрос — это обвинение.
Только если он высосанный из пальца и хамский.
R>Во-первых, никакие это не угрозы, просто объясняю тебе сидуацию. Во-вторых, не было бы твоего хамства, не было бы моих "угроз".
А, ну-ну. Не забывай про анекдот.
Ад пуст, все бесы здесь.
Re[23]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C> C> Данные, которые ты получаешь для парсинга — от пользователя. Никаких гарантий по их корректности никакой другой программист за тебя не обеспечит.
Ты путаешь теплое с мягким.
--
Re[24]: [performance] чего-то я не понимаю в этой жизни