Сообщение 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. Давай, обосновывай. В общем виде.
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. Давай, обосновывай. В общем виде.
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>>