Re[15]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 16.09.17 01:35
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>Ну давай начнём. ))) На моём компьютере этот код выполняется в среднем за 200 миллисекунд. Ну естественно, если заменить бредовую в данном контексте строку "toLocaleString('en-US', {minimumIntegerDigits: 10, useGrouping:false})" на эквивалентную ей по эффекту, но подходящую "toString().padStart(10, '0')".


CM>Это очень интересно, потому что у меня он исполняется 30 секунд и выжирает до 7 гигов максимум. Так что, видимо, не очень то эквивалентную.


Эквивалентную по выдаваемым данным. У тебя же в задачке стоит цель создания строки с id, а не траты процессорных таков, не так ли? Во всяком случае я на это надеюсь... )))

Ну и давай подведём итоги нашей дискуссии. Тебе почему-то не понравился результат моего теста, в котором C# (без unsafe) показывал близкие к JS результаты по быстродействию. И для аргументации своей позиции ты привёл свой тест, в котором по факту оказалось, что C# в 8 раз медленнее аналогичного кода на JS. Я считаю это было просто феерично!
Re[16]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 16.09.17 15:21
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Эквивалентную по выдаваемым данным. У тебя же в задачке стоит цель создания строки с id, а не траты процессорных таков, не так ли? Во всяком случае я на это надеюсь... )))


Нет. Моя задачка — найти пример кода, в котором JS катастрофически сливается. И я его нашел

_>в котором по факту оказалось, что C# в 8 раз медленнее аналогичного кода на JS. Я считаю это было просто феерично!


Не оказалось. Не надо было так откровенно врать, я ведь могу и проверить данные
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[17]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 16.09.17 16:19
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>Эквивалентную по выдаваемым данным. У тебя же в задачке стоит цель создания строки с id, а не траты процессорных таков, не так ли? Во всяком случае я на это надеюсь... )))

CM>Нет. Моя задачка — найти пример кода, в котором JS катастрофически сливается. И я его нашел

А, ну это очень милый подход. Только же его ведь можно применять в обе стороны.... Например так:
  C++
cpp_int a=1, b=2;
auto c=a+b;

  JS
var a=1, b=2;
var c=a+b;

И потом делать выводы типа: "аааа, JS быстрее C++ на элементарных арифметических операциях!".

_>>в котором по факту оказалось, что C# в 8 раз медленнее аналогичного кода на JS. Я считаю это было просто феерично!

CM>Не оказалось. Не надо было так откровенно врать, я ведь могу и проверить данные

Так каждый может проверить) Вот твой замечательный тест:
  C#
using System;
using System.Diagnostics;
using System.Linq;

namespace QuickSort
{
    class Program
    {
        static void Main(string[] args)
        {
            var watch = Stopwatch.StartNew();     
            var vals = Enumerable.Range(0, 1000 * 1000).Select(x => new TestClass()).ToArray();
            watch.Stop();
            Console.WriteLine("Total secs: "+watch.Elapsed.TotalSeconds);
        }
    }
    class TestClass
    {
        public string Id = CreateGuid();
        public string Value = CreateGuid();
        static Random gen=new Random( );

        static string CreateGuid()
        {
            return Math.Floor(gen.NextDouble()*Math.Pow(10, 8)).ToString().PadLeft(10, '0');
        }
    }
}

  JS
function CreateId()
{
    return Math.floor(Math.random()* Math.pow(10, 8)).toString().padStart(10, '0');
}

class TestClass
{
    constructor() {
        this.Id = CreateId();
        this.Value = CreateId();
    }
}
        
var startInit = performance.now();

var vals = [];
for (var i = 0; i < 1000 * 1000; i++)
{
    vals.push(new TestClass());
}

var endInit = performance.now();
log("Init: " + (endInit - startInit) + " msecs");


Соответственно к тебе два очевидных вопроса:
1. Являются ли это два кода эквивалентными (а не как пример выше на C++ или твоя изначальная глупость)?
2. Как соотносятся их времена исполнения?

Будет очень смешно послушать... )))
Re[18]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 16.09.17 16:35
Оценка:
Здравствуйте, alex_public, Вы писали:

_>И потом делать выводы типа: "аааа, JS быстрее C++ на элементарных арифметических операциях!".


Неа. Одно дело, когда возникает какая-то мелкая разница. Пусть даже в 2-3 раза. И совсем другое — когда какой-то язык (то есть JS) дико тормозит на несложном примере и выжирает бешеное количество оперативки

_>Так каждый может проверить) Вот твой замечательный тест:


Неа, не замечательный. Просто набросанный на скорую руку тест.

_>1. Являются ли это два кода эквивалентными (а не как пример выше на C++ или твоя изначальная глупость)?


А давай ты перестанешь хамить в каждом сообщении, для начала?

_>2. Как соотносятся их времена исполнения?


JS — 400, C# — 1200. Что, конечно, позорненько для C#. Но даже близко не сравнимо с твоими числами и с катастрофическим провалом JS при вызове другого метода
Я так понимаю, скомпилировать для Release и запускать без отладчика ты не сообразил?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[19]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.09.17 17:22
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>JS — 400, C# — 1200. Что, конечно, позорненько для C#. Но даже близко не сравнимо с твоими числами и с катастрофическим провалом JS при вызове другого метода


Вот жеж паскудство. Не иначе как заговор против тебя ? И похоже, что ты его возглавил

C# может обогнать джаваскрипт за счет использования всяких структур. Если же структур нет, то оба языка будут перемалывать не кеш первого-второго уровня, а виртуальную память. Это из за того, что косвенность вызовов длинная. А вот виртуальная память в зависимости от разных обстоятельств бывает то физической, то дисковой.
В рабочей обстановке скорее всего оба при внятной нагрузке будут пилить примерно одинаково часто пилить дисковую память. Даже если в остальном C# заруливет JS в минуса, то за счет дисковой памяти они тупо сравняются.

Собственно, если смотреть на тесты Techempower, видно, что дотнет почти везде уступает ноду или идет в ногу с ним. Вот так.
Re[20]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 16.09.17 18:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>В рабочей обстановке скорее всего оба при внятной нагрузке будут пилить примерно одинаково часто пилить дисковую память. Даже если в остальном C# заруливет JS в минуса, то за счет дисковой памяти они тупо сравняются.


На самом деле — нет. Чтобы выжрать всю оперативку и упереться в диск, в случае C# надо очень-очень сильно постараться. А для жабоскрипта, надо очень постараться, чтобы ее не выжрать По потреблению оперативки, браузеры очень давно на лидирующих позициях, с большим отрывом. Даже мегатормоз VS2017 не идет ни в какое сравнение
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[19]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 16.09.17 20:12
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>И потом делать выводы типа: "аааа, JS быстрее C++ на элементарных арифметических операциях!".

CM>Неа. Одно дело, когда возникает какая-то мелкая разница. Пусть даже в 2-3 раза. И совсем другое — когда какой-то язык (то есть JS) дико тормозит на несложном примере и выжирает бешеное количество оперативки

Ну вообще то мы уже выяснили, что в твоём примере тормозил не "язык", а какая-то одна специфическая библиотечная функция национального форматирования чисел, причём применённая тобой абсолютно не по делу.

И кстати мы так и не видели аналога данного кода на C# (с национальными форматированиями и т.п.), чтобы сравнить результат. )))

_>>Так каждый может проверить) Вот твой замечательный тест:

CM>Неа, не замечательный. Просто набросанный на скорую руку тест.

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

_>>1. Являются ли это два кода эквивалентными (а не как пример выше на C++ или твоя изначальная глупость)?

CM>А давай ты перестанешь хамить в каждом сообщении, для начала?

А ты хочешь сказать, что использование функции форматирования чисел в соответствие с национальными правилам для заполнения нулями начала строки — это не глупость? )))

_>>2. Как соотносятся их времена исполнения?

CM>JS — 400, C# — 1200. Что, конечно, позорненько для C#. Но даже близко не сравнимо с твоими числами и с катастрофическим провалом JS при вызове другого метода

Я запускал JS в Firefox55 64 бита — попробуй проверить в нём (там сейчас вроде как самый эффективный движок JS). Ну и компьютер у меня топовый Xeon. )))

CM>Я так понимаю, скомпилировать для Release и запускать без отладчика ты не сообразил?


Какой отладчик или Release? ))) У меня давно уже не стоит VisualStudio, так что все примеры на C# я компилирую так: "csc /unsafe /o /nologo /out:test.exe source.cs". Возможно в моём системном .Net'е и не самая последняя версия jit, но у большинства пользователей стоит наверное даже более старая версия (т.к. сейчас доминирующая ОС на десктопе — это Win7).

Но в любом случае это всё не принципиальные вопросы, которыми ты похоже пытаешься замылить главный смысл. Вот сам посмотри: мы начали с твоего утверждения, что JS в 10-20 раза медленнее C#, а сейчас ты пытаешься доказать, что C# медленее JS не в 8 раз, а всего в 3... Это разве не забавно? )))
Re[20]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 16.09.17 20:32
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну вообще то мы уже выяснили, что в твоём примере тормозил не "язык", а какая-то одна специфическая библиотечная функция национального форматирования чисел, причём применённая тобой абсолютно не по делу.


А эта функция, вероятно, написана не на JS?

_>И кстати мы так и не видели аналога данного кода на C# (с национальными форматированиями и т.п.), чтобы сравнить результат. )))


Ты ведь и так знаешь, что это ничего особо не изменит. Национальное — не национальное, а провал — все равно провал.

_>Замечательный в том смысле, что он оказался опровергающим твои же утверждения. )))


Какое избирательное зрение. Разницу в 25 раз в упор не замечает, а в 3 раза — великолепно видит.

_>А ты хочешь сказать, что использование функции форматирования чисел в соответствие с национальными правилам для заполнения нулями начала строки — это не глупость? )))


Функция есть — значит, должна работать нормально. Хватит уже выкручиваться.

_>Я запускал JS в Firefox55 64 бита — попробуй проверить в нём (там сейчас вроде как самый эффективный движок JS).


Я в нем и проверял. И увидел, что там разработчики чего-то страшного нахимичили и разброс значений получается от ~200 до >1000. Но если прогнать тест 1000 раз и усреднить, а не взять самое маленькое значение, как это сделал ты — получается как раз 400.

_>Ну и компьютер у меня топовый Xeon. )))


И который там сейчас топовый, Xeon Platinum 8180? Да ты невероятно крут, гонять жабаскрипт на процессоре за 10 килобаксов
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[20]: Реальная производительность WebAssembly?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.09.17 21:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>Собственно, если смотреть на тесты Techempower, видно, что дотнет почти везде уступает ноду или идет в ногу с ним. Вот так.

Вот интересно Net Native это тоже .Net, так он почти вровень с C++. http://rsdn.org/forum/dotnet/6738556.1
Автор: Serginio1
Дата: 28.03.17


Да и CLR подтягивается http://rsdn.org/forum/dotnet/6808392.1
Автор: Serginio1
Дата: 13.06.17
и солнце б утром не вставало, когда бы не было меня
Отредактировано 17.09.2017 7:27 Serginio1 . Предыдущая версия .
Re[21]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 16.09.17 22:31
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>Ну вообще то мы уже выяснили, что в твоём примере тормозил не "язык", а какая-то одна специфическая библиотечная функция национального форматирования чисел, причём применённая тобой абсолютно не по делу.

CM>А эта функция, вероятно, написана не на JS?

Ну судя по этому https://dxr.mozilla.org/mozilla-central/source/js/src/builtin/Number.js#18 исходнику, в FF она действительно частично написана на JS (и при своём выполнение каждый раз создаёт экземпляр весьма нетривиального объекта https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat) и частично на C++ (https://dxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.cpp#1916).

Только вот непонятно какое это всё имеет отношение к производительности языка.

_>>И кстати мы так и не видели аналога данного кода на C# (с национальными форматированиями и т.п.), чтобы сравнить результат. )))

CM>Ты ведь и так знаешь, что это ничего особо не изменит. Национальное — не национальное, а провал — все равно провал.

Ну так если C# вариант будет работать не 30 секунд, а 90 секунд, то... )))

_>>Замечательный в том смысле, что он оказался опровергающим твои же утверждения. )))

CM>Какое избирательное зрение. Разницу в 25 раз в упор не замечает, а в 3 раза — великолепно видит.

А где ты видишь разницу в 25 раз? C# кода аналогичного глупому медленному варианту на JS в данной темке никто так и не видел. Хотя в любом случае это был бы тест не языка, а стандартной функции, но у тебя даже и такого не было.

=====

Ну и в любом случае, возвращаясь к истокам нашей беседы — надеюсь теперь тебе уже не кажется подозрительным тест, в котором производительность C# и JS находятся на сравнимом уровне? )))
Re[20]: Реальная производительность WebAssembly?
От: Ночной Смотрящий Россия  
Дата: 17.09.17 11:33
Оценка:
Здравствуйте, alex_public, Вы писали:

_>И кстати мы так и не видели аналога данного кода на C# (с национальными форматированиями и т.п.), чтобы сравнить результат. )))


В шарпе по умолчанию локаль используется.
Re[21]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 17.09.17 13:06
Оценка: -1 :)
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>И кстати мы так и не видели аналога данного кода на C# (с национальными форматированиями и т.п.), чтобы сравнить результат. )))

НС>В шарпе по умолчанию локаль используется.

Ты бы в начале хотя бы ознакомился с проблемой... ))) Автор как раз форматирует не к системной (русской там или какой-то ещё), а к американской локали, указывая её явно. Это в JS коде (то, что подобное форматирование там вообще не нужно — это другой вопрос, который здесь уже обсудили). А C# аналога данного кода вообще в темке не было.
Re[21]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 15:59
Оценка: -2 :)
Здравствуйте, CoderMonkey, Вы писали:

I>>В рабочей обстановке скорее всего оба при внятной нагрузке будут пилить примерно одинаково часто пилить дисковую память. Даже если в остальном C# заруливет JS в минуса, то за счет дисковой памяти они тупо сравняются.


CM>На самом деле — нет. Чтобы выжрать всю оперативку и упереться в диск, в случае C# надо очень-очень сильно постараться. А для жабоскрипта, надо очень постараться, чтобы ее не выжрать По потреблению оперативки, браузеры очень давно на лидирующих позициях, с большим отрывом. Даже мегатормоз VS2017 не идет ни в какое сравнение


Не смеши людей. В реале оператива нужна всем приложениям, а не только твоему. То есть, коммита 1 к 1 нет и никогда не будет.
Ты распоряжаешься исключительно виртуальной памятью, что в C#, что в JS. Усёк ?
Как только страницы физической закончились, а это довольно быстро начинается, будем пилить диск. То есть, не ты один такой весь такой умный.
Re[22]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 16:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Только вот непонятно какое это всё имеет отношение к производительности языка.


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

_>А где ты видишь разницу в 25 раз? C# кода аналогичного глупому медленному варианту на JS в данной темке никто так и не видел. Хотя в любом случае это был бы тест не языка, а стандартной функции, но у тебя даже и такого не было.


Элементарно, Ватсон.
            var num = Math.Floor(RandomGen.NextDouble() * Math.Pow(10, 8));
            var res = num.ToString("0000000000", CultureInfo.GetCultureInfo("en-us"));
            return res;

Разница — минимальная.

_>Ну и в любом случае, возвращаясь к истокам нашей беседы — надеюсь теперь тебе уже не кажется подозрительным тест, в котором производительность C# и JS находятся на сравнимом уровне? )))


Где же на сравнимом, если вылезает разница в ~25 раз на совершенно ровном месте? В JS всегда так — запустишь какую-нибудь простенькую синтетику, и вроде всё нормально и даже не тормозит. А потом шаг право, шаг влево — и из под ног начинает хлестать жижа с очень характерным цветом и запахом.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[22]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 16:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Не смеши людей. В реале оператива нужна всем приложениям, а не только твоему. То есть, коммита 1 к 1 нет и никогда не будет.

I>Ты распоряжаешься исключительно виртуальной памятью, что в C#, что в JS. Усёк ?
I>Как только страницы физической закончились, а это довольно быстро начинается, будем пилить диск. То есть, не ты один такой весь такой умный.

Это было верно лет 20 назад, когда оперативка была дороже золота. Сейчас она стоит недорого, и поставить достаточно, чтобы хватило всем приложениям — элементарно.
Так что поздравляю с выходом из гибернации.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[23]: Реальная производительность WebAssembly?
От: vsb Казахстан  
Дата: 17.09.17 16:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Это было верно лет 20 назад, когда оперативка была дороже золота. Сейчас она стоит недорого, и поставить достаточно, чтобы хватило всем приложениям — элементарно.


И как мне её поставить на последний айфон, например, на котором её всего 2 гигабайта (при том, что процессор быстрей, чем на топовом макбуке)?

То же про ноутбуки с распаянной памятью, которых всё больше и больше.

Недорогие десятки гигабайтов оперативы это прерогатива рабочих станций, которых среди персональных устройств доли процента.
Отредактировано 17.09.2017 16:47 vsb . Предыдущая версия .
Re[23]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 16:49
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Не смеши людей. В реале оператива нужна всем приложениям, а не только твоему. То есть, коммита 1 к 1 нет и никогда не будет.

I>>Ты распоряжаешься исключительно виртуальной памятью, что в C#, что в JS. Усёк ?
I>>Как только страницы физической закончились, а это довольно быстро начинается, будем пилить диск. То есть, не ты один такой весь такой умный.

CM>Это было верно лет 20 назад, когда оперативка была дороже золота. Сейчас она стоит недорого, и поставить достаточно, чтобы хватило всем приложениям — элементарно.

CM>Так что поздравляю с выходом из гибернации.

Браво. Ты похоже не слышишь. Еще раз и медленно:
1 — кроме тебя есть и другие пользователи физической памяти
2 — коммит 1 к 1 практически недостижим в реальном мире

Представь себе кейс — серверное приложение. Еще кейс — виртуалка. Еще кейс — мобильное приложение. Еще кейс — ноутбук.
Расскажи, как ты здесь будешь память добавлять ?
Re[24]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 16:51
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>И как мне её поставить на последний айфон, например, на котором её всего 2 гигабайта (при том, что процессор быстрей, чем на топовом макбуке)?


А в этом виноват главным образом жабаскрипт и веб, всем остальным приложениям ее вполне хватает. Лет 15 назад этого было более чем достаточно и для рабочей станции. У меня самое тяжеловесное приложение — VS2017 с решарпером — и сейчас редко выжирает больше, чем пол-гига.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 16:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Представь себе кейс — серверное приложение. Еще кейс — виртуалка. Еще кейс — мобильное приложение. Еще кейс — ноутбук.

I>Расскажи, как ты здесь будешь память добавлять ?

А ты еще раз расскажи мне, почему выжрать в 10 раз больше оперативки (и соответственно в 10 раз больше дисковых операций, если оперативки не хватает) — это совсем не проблема.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[23]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 17.09.17 17:07
Оценка: :))) :))
Здравствуйте, CoderMonkey, Вы писали:

_>>Только вот непонятно какое это всё имеет отношение к производительности языка.

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

Если какая-то библиотечная функция становится бутылочным горлышком по производительности, то я элементарно могу её не использовать (написав свою или взяв из какой-то другой библиотеки). Такое даже в C++ бывает (скажем стандартные потоки ввода-вывода никогда не считались приемлемым инструментом для тяжёлых нагрузок). А вот в случае проблем с производительностью самого языка (его базовой модели, оптимизатора компилятора и т.п.) уже ничего нельзя поделать.

Ну и кстати если говорить про JS в браузере, то там очень многие встроенные функций реализованы на C++.

_>>А где ты видишь разницу в 25 раз? C# кода аналогичного глупому медленному варианту на JS в данной темке никто так и не видел. Хотя в любом случае это был бы тест не языка, а стандартной функции, но у тебя даже и такого не было.

CM>Элементарно, Ватсон.
CM>
CM>            var num = Math.Floor(RandomGen.NextDouble() * Math.Pow(10, 8));
CM>            var res = num.ToString("0000000000", CultureInfo.GetCultureInfo("en-us"));
CM>            return res;
CM>

CM>Разница — минимальная.

О, наконец то корректный аналогичный пример. Ну у меня он исполняется 1900 мс (вместо 1600 мс с PadLeft). ОК, принимается, что функция национального форматирования чисел в .Net реализована более эффективно по производительности, чем в Firefox.

При этом создание большого массива экземпляров некоторого класса работает в Firefox эффективнее, чем в .Net. Что важнее, думаю ты можешь оценить сам. )))

_>>Ну и в любом случае, возвращаясь к истокам нашей беседы — надеюсь теперь тебе уже не кажется подозрительным тест, в котором производительность C# и JS находятся на сравнимом уровне? )))

CM>Где же на сравнимом, если вылезает разница в ~25 раз на совершенно ровном месте? В JS всегда так — запустишь какую-нибудь простенькую синтетику, и вроде всё нормально и даже не тормозит. А потом шаг право, шаг влево — и из под ног начинает хлестать жижа с очень характерным цветом и запахом.

Я говорил про свой изначальный тест с вычислениями в двухмерных массивах. Там точно не использовались никакие встроенные функции, так что этот тест демонстрировал именно способности языка/компилятора/оптимизатора.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.