Re[87]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.11.17 13:19
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

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

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

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


Да, надо перепроверить на разном железе, в т.ч. ddr4. У меня все что есть, это DDR3 1600

CM>2. Не общую производительность, а именно в отдельных программах (при том, что в других программах DDR4 проигрывает). Так что — те же самые микробенчмарки.


Не вижу связи между "отдельная программа" и "микробенчмарк". Что делает эта "отдельная программа" ? Если исключительно память туда-сюда копирует или сортирует, это микробенчмарк. А если, скажем, зип упаковывает-распаковывает, или рисует-вычисляет чего, то совсем другая вещь.

CM>Так что твоя любимая шина, в самом лучше для нее случае, может иногда дать +10%.

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

wmic MemoryChip get BankLabel, Capacity, MemoryType, TypeDetail, Speed, Tag
BankLabel  Capacity    MemoryType  Speed  Tag                TypeDetail
BANK 3     8589934592  24          1600   Physical Memory 3  128


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

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

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


Обоснуй. В моём понимании процессор не занимается пересылкой данных. Пересылкой занимается шина и сама память, т.е. в сортировке процессору делать почти что и нечего.
Итого — можешь обосновать или ... ?

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

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

Ты как поляк, который смеётся с анекдота трижды — когда ему рассказывают, когда объясняют и когда доходит
Читаем медленно:
Аномалия в том, что: 
1 замеры в сортировке     не соответствуют разнице в мощности железа. ( НЕ СООТВЕТСТВУЮТ)
2 замеры в инициализации     соответствуют разнице в можности железе. (    СООТВЕТСТВУЮТ)


Вот если бы оба соответствовали — все в порядке.
Оба не соответсвуют — тоже аномалия, но другая.
Теоретически, у нас может любой случай, т.к. у тебя не то много медленнее, не то быстрее чем у меня. Сам определить не можешь.
Может даже окажется так, что и сортировка и инициализация показывают одну и ту же разницу, если померить среднее время по первому числу из пары десятков прогонов.
Вобщем, толку от тебя никакого нет.

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

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

А почему они должны показывать одно и то же ? Если ты один и тот же GC запускаешь в разных условиях, с разной частотой, из разных потоков — ты получаешь совершенно разные вещи.

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

CM>Нужно, достаточно вспомнить про баг в стандартной сортировке Java. Давай, обосновывай. В общем виде.

Мне достаточно того факта, что ты не можешь даже источник указать, т.е. код _на_коленке_.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.