Информация об изменениях

Сообщение Re[86]: Реальная производительность WebAssembly? от 07.11.2017 17:28

Изменено 07.11.2017 17:40 CodeMonkey

Re[86]: Реальная производительность WebAssembly?
Здравствуйте, Ikemefula, Вы писали:

I>Бенчмарки показывают влияние шины на _общую_ производительность системы в конкретной задаче. И здесь 5-10% это очень много.

I>В нашем случае у нас микробенчмарк — перетасовка одной лишь памяти. Фактически, здесь всё время даёт именно шина.

Тебе осталось только доказать, что причина именно в ней. Так что давай, показывай доказательства.
Память то у тебя какая, кстати? А то вдруг на твоем тормозожелезе стоит какой-нибудь PC4-12800

I>Опаньки! А как бодро начиналось "сортировка в JS у тебя сработала намного быстрее".


Ну так я думал, что ты измерял среднее или медианное время, как делают все нормальные люди.
И это мы еше временно исключили из картины Firefox — а он, между тем, по прежнему есть. Так что по хорошему, надо усреднять и с ним.

I>А щас выходит у тебя среднее меньше, а нижняя граница вовсе на 20% меньше моей


А должна быть — меньше в два раза.

I>Инициализация доказыет, что сортировка есть аномалия. И именно её нужно объяснять. Понемногу я тебе разжевываю, как это было например с CompareOrdinal. Глядишь, к НГ управимся.


Какая такая аномалия? Мы сравниваем твой код, только на разных компьютерах.

I>GC дотнета, джавы работают похоже. Ради пару мб памяти GС и напрягаться не будет — её навалом. Кстати, в твоём коде даже GC.Collect не вызывается


И такого огромного разброса, как в JS, нет. Вот ведь удивительно.

I>Мне это не нужно делать


Нужно, достаточно вспомнить про баг в стандартной сортировке Java. Давай, обосновывай. В общем виде.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[86]: Реальная производительность WebAssembly?
Здравствуйте, Ikemefula, Вы писали:

I>Бенчмарки показывают влияние шины на _общую_ производительность системы в конкретной задаче. И здесь 5-10% это очень много.

I>В нашем случае у нас микробенчмарк — перетасовка одной лишь памяти. Фактически, здесь всё время даёт именно шина.

1. Тебе осталось только доказать, что причина именно в ней. Так что давай, показывай доказательства.
2. Не общую производительность, а именно в отдельных программах (при том, что в других программах DDR4 проигрывает). Так что — те же самые микробенчмарки.
Так что твоя любимая шина, в самом лучше для нее случае, может иногда дать +10%.
Память то у тебя какая, кстати? А то вдруг на твоем тормозожелезе стоит какой-нибудь PC4-12800

I>Опаньки! А как бодро начиналось "сортировка в JS у тебя сработала намного быстрее".


Ну так я думал, что ты измерял среднее или медианное время, как делают все нормальные люди.
И это мы еше временно исключили из картины Firefox — а он, между тем, по прежнему есть. Так что по хорошему, надо усреднять и с ним.

I>А щас выходит у тебя среднее меньше, а нижняя граница вовсе на 20% меньше моей


А должна быть — меньше в два раза.

I>Инициализация доказыет, что сортировка есть аномалия. И именно её нужно объяснять. Понемногу я тебе разжевываю, как это было например с CompareOrdinal. Глядишь, к НГ управимся.


Какая такая аномалия? Мы сравниваем твой код, только на разных компьютерах.

I>GC дотнета, джавы работают похоже. Ради пару мб памяти GС и напрягаться не будет — её навалом. Кстати, в твоём коде даже GC.Collect не вызывается


И такого огромного разброса, как в JS, нет. Вот ведь удивительно.

I>Мне это не нужно делать


Нужно, достаточно вспомнить про баг в стандартной сортировке Java. Давай, обосновывай. В общем виде.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>