Здравствуйте, alexzzzz, Вы писали:
I>>Будешь смеяться, на на этом фортране до сих пор кучу математики пишут. Думаешь ради чего его оптимизируют ?
A>Я знаю, что на нём пишут. Есть Фортран, у которого «компилер генерит качественный код». Что-то не видно, чтобы народ на нём «смело начинал пилить целую кучу задач».
Знаешь что пишут, но при этом есть сомнения действительно ли пишут ? Область в которой есть Фортран до сих пор никуда не делась. Туда более крутые языки не сильно то и проникают. Особенность отрасли.
I>>Так вроде очевидно что сортировка и эти тесты вобщем сравнивают вещи совершенно разные, но для тебя это почему то вариации на одну и ту же тему
A>Мы говорим каждый о чём-то своём и друг друга не понимаем вообще. Аминь.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Ikemefula, Вы писали:
I>>Там адъ почище виндовса. В большинстве случаев принято чуть не всю работу делать сторонними либами. Объем кода в депенденсах считается в сотнях мегабайт и больше.
Ops>Так я не хочу побороть этот ад, это вряд ли кому-то по силам, только закешировать его, а то иная утилита только грузится секунду, хотя отрабатывает за десяток миллисекунд.
А кто будет кешировать, товариащи из v8 ? Им это нахрен не нужно, ибо node для них есть помеха для Dart и Go. Товарищи из node ? У них руки коротки.
Возможно, когда webassembly раскочегарится, модули Node можно будет пред-компилировать. Но мне пока это кажется маловероятным сценарием. Во фронтенде такой проблемы нет, только в ноде. Во фронтенде никто не грузит на клиент сотни мегабайт джаваскрипта
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, alexzzzz, Вы писали:
A>>В C# в районе 40% времени приходится на стандартный рандом и 50% на ToString с параметром.
НС>И это после того, как я прямо в этом топике написал, что дотнетный и JS tostring не эквивалентны. Ну чо, меряйте дальше.
Очень легко добиться эквивалентности. Можно ведь и свою функцию вызвать
Здравствуйте, Ikemefula, Вы писали:
НС>>И это после того, как я прямо в этом топике написал, что дотнетный и JS tostring не эквивалентны. Ну чо, меряйте дальше. I>Очень легко добиться эквивалентности.
Ну так добейтесь, а после уже меряйте. А то измеряете погоду в Африке.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И это после того, как я прямо в этом топике написал, что дотнетный и JS tostring не эквивалентны. Ну чо, меряйте дальше. I>>Очень легко добиться эквивалентности. НС>Ну так добейтесь, а после уже меряйте. А то измеряете погоду в Африке.
Что за фетиш такой — эта эквивалентность? Надо решать поставленную задачу имеющимися средствами и смотреть на скорость полученного решения. Весь код существует только ради решения задач. Если бы кого парила эквивалентность, существовал бы ровно один язык и один набор библиотек для него.
) с вариантами решения на C# и JS. Я после нескольких попыток дал решение этой задачи на C#, которое работает быстрее оригинального грубо в 15 раз в однопоточном варианте и в 35 раз в многопоточном. Хотите «эквивалентности», ускорьте JS так же. А то у меня складывается впечатление, что тут JS никто не знает и не умеет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>И это после того, как я прямо в этом топике написал, что дотнетный и JS tostring не эквивалентны. Ну чо, меряйте дальше. I>>Очень легко добиться эквивалентности.
НС>Ну так добейтесь, а после уже меряйте. А то измеряете погоду в Африке.
У меня всё сильно. Дотнетчиков слишком много, не могут договориться.
Здравствуйте, alexzzzz, Вы писали:
A>Что за фетиш такой — эта эквивалентность? Надо решать поставленную задачу имеющимися средствами и смотреть на скорость полученного решения. Весь код существует только ради решения задач. Если бы кого парила эквивалентность, существовал бы ровно один язык и один набор библиотек для него.
Исследователь дождевого червя однажды сказал так: "Жизнь такая короткая, а червяк такой длинный!"
A>alex_public предложил задачу (http://rsdn.org/forum/flame.comp/6905867.1
) с вариантами решения на C# и JS. Я после нескольких попыток дал решение этой задачи на C#, которое работает быстрее оригинального грубо в 15 раз в однопоточном варианте и в 35 раз в многопоточном. Хотите «эквивалентности», ускорьте JS так же. А то у меня складывается впечатление, что тут JS никто не знает и не умеет.
Хы, я что-то не смотрел код твоих последних вариантов, а сейчас глянул — смотрю ты там совсем захардкордил всё. ))) Подозреваю что при таком подходе на JS (а уж про C++ с его любовью к таким играм вообще молчу) можно тоже существенно изменить результаты. Но мне уже как-то лень играться в это. )
Кстати, а как и где задавать вот эту строчку:
<gcServer enabled="true"/>
а то у меня твой последний код выдаёт 200 мс, видимо как раз из-за этой опции. Если что, я компилирую .Net из командной строки. )
Здравствуйте, alex_public, Вы писали:
_>Хы, я что-то не смотрел код твоих последних вариантов, а сейчас глянул — смотрю ты там совсем захардкордил всё. ))) Подозреваю что при таком подходе на JS (а уж про C++ с его любовью к таким играм вообще молчу) можно тоже существенно изменить результаты. Но мне уже как-то лень играться в это. )
Если бы я знал JS и знал, что это возможно, сам бы сделал из любопытства, но я не знаю ни того, ни другого. Если ты не улучшишь результат, скорее всего, никто не улучшит.
_>Кстати, а как и где задавать вот эту строчку: _>
_><gcServer enabled="true"/>
_>
_>а то у меня твой последний код выдаёт 200 мс, видимо как раз из-за этой опции. Если что, я компилирую .Net из командной строки. )
Можно вместо копирования, делать инициализацию по месту
internal unsafe struct TestStruct
{
public string id;
public string value;
private static readonly Random random = new Random();
public void Init()
{
id = GenerateRandomNumber();
value = GenerateRandomNumber();
}
public override string ToString() => id;
private static string GenerateRandomNumber()
{
var buffer = stackalloc char[11];
int num = random.Next(100_000_000);
var p = buffer;
*p++ = '0';
*p++ = '0';
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p++ = (char)('0' + num % 10); num /= 10;
*p = (char)('0' + num % 10);
return new string(buffer);
}
}
Здравствуйте, alexzzzz, Вы писали: _>>Хы, я что-то не смотрел код твоих последних вариантов, а сейчас глянул — смотрю ты там совсем захардкордил всё. ))) Подозреваю что при таком подходе на JS (а уж про C++ с его любовью к таким играм вообще молчу) можно тоже существенно изменить результаты. Но мне уже как-то лень играться в это. ) A>Если бы я знал JS и знал, что это возможно, сам бы сделал из любопытства, но я не знаю ни того, ни другого. Если ты не улучшишь результат, скорее всего, никто не улучшит.
Ну я вообще то тоже не эксперт по JS. ))) Т.е. я его конечно более менее знаю (как и все сейчас наверное), но не настолько, чтобы написать за одну минуту (без копания в документации, что уже лень) самый оптимальный вариант. В отличие от C++ (который как раз входит в число моих инструментов), на котором я реально могу за пару минут накидать нужное.
Вот сейчас перевёл твой хардкорный код в C++ вариант и был несколько шокирован результатом. Т.е. я конечно знаю про силу бесплатных абстракций C++, но такого не ожидал даже я: хардкорный код, заточенный под один конкретный случай, оказался медленнее универсального кода, допускающего произвольное сложное форматирование! Надо будет потом ещё глянуть ради интереса, что там авторы Spirit'а наоптимизировали, что оно так летает. ))) _>>Кстати, а как и где задавать вот эту строчку: _>>
Ага, работает, подтверждаю. ) Кстати, но мне кажется, что всё же не совсем корректно сравнивать такие реализации, потому что в реальной жизни большинство программистов будет всё же использовать готовые функции. Так что я бы представил результаты всех этих наших измерений приблизительно так:
время заполнения массива, с помощью стандартных функций, мс
время заполнения массива, с помощью ручного кода, мс
JS
node
500
?
Firefox
200
?
C#
normal
500
200
server
380
100
C++
14
120
52
17
60
52
Boost
49
52
P.S. разница между C++14 и C++17 в том, что в первом используется функция форматирования, использующая системную локаль (прямо как в C#), а во втором используется только что добавленная в стандарт функция, не использующая локаль (прямо как в JS).
C++ код, если что, сразу для всех вариантов)
class Test
{
inline static mt19937 rnd;
auto create_id()//Boost
{
string s(10, '0');
generate(s.begin()+2, sp::uint_, uniform_int_distribution<>(0, 99'999'999)(rnd));
return s;
}
auto create_id1()//хардкор
{
string s(10, '0');
for(int i=2, n=uniform_int_distribution<>(0, 99'999'999)(rnd); n>0; i++, n/=10) s[i]='0'+n%10;
return s;
}
auto create_id2()//C++17
{
string s(10, '0');
to_chars(&s[0]+2, &s[0]+10, uniform_int_distribution<>(0, 99'999'999)(rnd));
return s;
}
public:
Test(): id(create_id()), value(create_id()) {}
string id;
string value;
};
int main()
{
for(int i=0; i<5; i++){
auto start=high_resolution_clock::now();
vector<Test> vals(1000*1000);
auto end=high_resolution_clock::now();
cout<<duration_cast<milliseconds>(end-start).count()<<" ms."<<endl;
}
}
Здравствуйте, alex_public, Вы писали:
А где .Net Native?
А насчет реальной жизни, если есть возможность подкрутить лимитирующую стадию процесса,
то большинство программистов начинают оптимизировать.И .Net это позволяет.
Пример https://stackoverflow.com/
А там где скорость не важна, то там и 1С прекрасно себя чувствует
– Ваше решение построено полностью на С#, или есть части на других языках, типа C++, Java, Python или других?
– Я бы сказал, что на 99% у нас С#. У нас, конечно, есть немного на C++ или С, но в строчках кода это совсем мало. Естественно, у нас есть TypeScript и JavaScript. JavaScript у нас на сервере используется для компиляции бандлов и минификации кода. Мы также пользуемся SQL, это другой язык. Вот и все.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Ага, работает, подтверждаю. ) Кстати, но мне кажется, что всё же не совсем корректно сравнивать такие реализации, потому что в реальной жизни большинство программистов будет всё же использовать готовые функции.
Соображения такие:
1. Если участку программы нужна скорость, тут и профайлером смотрят, и бенчмарки гоняют-сравнивают, и используют любые доступные средства — цель оправдывает.
2. Остальной программе (99%) скорость не критична, код пишется как можно проще. Померить скорость, погонять бенчмарки можно, но результаты никому не будут нужны.
Т.е. если и мерить скорость стандартных функций, то только ради первого пункта — чтобы примерно представлять, насколько она быстрая/медленная и насколько её можно будет ускорить, если понадобится.
Здравствуйте, alexzzzz, Вы писали:
_>>Ага, работает, подтверждаю. ) Кстати, но мне кажется, что всё же не совсем корректно сравнивать такие реализации, потому что в реальной жизни большинство программистов будет всё же использовать готовые функции. A>Соображения такие: A>1. Если участку программы нужна скорость, тут и профайлером смотрят, и бенчмарки гоняют-сравнивают, и используют любые доступные средства — цель оправдывает. A>2. Остальной программе (99%) скорость не критична, код пишется как можно проще. Померить скорость, погонять бенчмарки можно, но результаты никому не будут нужны. A>Т.е. если и мерить скорость стандартных функций, то только ради первого пункта — чтобы примерно представлять, насколько она быстрая/медленная и насколько её можно будет ускорить, если понадобится.
Угу, я согласен. Поэтому и говорю, что надо отдельно два столбика рассматривать и оба они несут определённый полезный смысл. ) Вот если кто-то (может Ikemefula?) подкинет недостающее решение для JS — тогда будет всё совсем корректно. )
S>> Ну и еще попробовать Net Native A>Попробую, если научусь делать консольные приложения. Никогда не пробовал.
Насчет консольного не знаю, но аналог WPF или Xamarin легко https://metanit.com/sharp/uwp/
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alexzzzz, Вы писали:
A>Соображения такие: A>1. Если участку программы нужна скорость, тут и профайлером смотрят, и бенчмарки гоняют-сравнивают, и используют любые доступные средства — цель оправдывает.
Код должен быть относительно читабельным после оптимизаций. В противном случае его выбросят после долгого геморроя с майнтенансом.
Скажем, в JS можно много чего придумать, правда такой код никто в своём уме не пишет. Соответственно и сравнивать смысла большого нет.
A>2. Остальной программе (99%) скорость не критична, код пишется как можно проще. Померить скорость, погонять бенчмарки можно, но результаты никому не будут нужны.
Это не совсем так. Скажем, энергосбережение, загрузку процессора никто не отменял.
Здесь интересный момент, связаный с теми тестами про сортировку. Большинство программистов на разных языках одну и ту же задачу решат одним и тем же способом, идентичной структурой и алгоритмами и тд и тд. То есть, выбор решения обычно делается до написания кода и тд. И если в одном из языков производительности хватит, то в другом это может стать узким местом и только тогда появляются оптимизации.
То есть, если обычный код на одном языке устраивает своей производительностью, то с большой вероятностью любой язык, который выдаст аналогичный перформанс, так же сгодится для решения задачи.
Здравствуйте, Ikemefula, Вы писали:
A>>Соображения такие: A>>1. Если участку программы нужна скорость, тут и профайлером смотрят, и бенчмарки гоняют-сравнивают, и используют любые доступные средства — цель оправдывает. I>Код должен быть относительно читабельным после оптимизаций. В противном случае его выбросят после долгого геморроя с майнтенансом.
Выбросят, участок программы снова станет в 10 раз медленнее, и кто-то за это получит по шапке. Но если оптимизацию можно выбросить так, что никто не заметит, то тогда она конечно лишняя.
Область в которой есть Фортран до сих пор никуда не делась. Туда более крутые языки не сильно то и проникают. Особенность отрасли.
Т.е. я конечно знаю про силу бесплатных абстракций C++, но такого не ожидал даже я: хардкорный код, заточенный под один конкретный случай, оказался медленнее универсального кода, допускающего произвольное сложное форматирование! Надо будет потом ещё глянуть ради интереса, что там авторы Spirit'а наоптимизировали, что оно так летает. )))