Здравствуйте, Kerbadun, Вы писали:
K>>http://www.oberhumer.com/opensource/lzo/
K>Если не ошибаюсь, на современных компьютерах оно работает быстрее, чем memcpy.
Несколько сомнительно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Ищу простой быстрый алгоритм сжатия на С (не ++)
Не уверен на 100% насчет именно этого алгоритма, но данные были получены экспериментально и довольно легко объяснимы: общее количество памяти, которое нужно прочитать/записать у memcpy больше, а процессор работает очень быстро и не вносит большого вклада, то есть все упирается в скорость памяти. Закономерно получается быстрее.
Я конечно, тоже сначала офигел, когда увидел цифры ("Э-э, погодите, memcpy медленнее?! Но оно же просто копирует!").
Когда он умрет, его мозг заспиртуют в стакане
Re[5]: Ищу простой быстрый алгоритм сжатия на С (не ++)
Здравствуйте, Kerbadun, Вы писали:
K>>>>http://www.oberhumer.com/opensource/lzo/ K>>>Если не ошибаюсь, на современных компьютерах оно работает быстрее, чем memcpy. CC>>Несколько сомнительно.
K>Не уверен на 100% насчет именно этого алгоритма, но данные были получены экспериментально и довольно легко объяснимы: общее количество памяти, которое нужно прочитать/записать у memcpy больше
Считать как минимум столько же.
Записать да, меньше.
Но обработка она всё равно не настолько бесплатная.
K>Я конечно, тоже сначала офигел, когда увидел цифры ("Э-э, погодите, memcpy медленнее?! Но оно же просто копирует!").
У них на сайте:
Here are some original timings done on an Intel Pentium 133. Multiply by a constant factor for modern machines.
Здравствуйте, Kerbadun, Вы писали:
K>>>>http://www.oberhumer.com/opensource/lzo/ K>>>Если не ошибаюсь, на современных компьютерах оно работает быстрее, чем memcpy. CC>>Несколько сомнительно.
K>Не уверен на 100% насчет именно этого алгоритма, но данные были получены экспериментально и довольно легко объяснимы: общее количество памяти, которое нужно прочитать/записать у memcpy больше, а процессор работает очень быстро и не вносит большого вклада, то есть все упирается в скорость памяти. Закономерно получается быстрее.
Вики про него говорит:
On modern architectures, decompression is very fast; in non-trivial cases able to exceed the speed of a straight memory-to-memory copy due to the reduced memory-reads.
Насчёт существенного буста скорости на минимизации чтения для non-trivial cases для LZ несколько сомнительно.
Похоже больше на то, что сжатый текст весь сидит в кэше, cache miss при распаковке не происходит и потому доставание из словаря дёшево на чтении.
Надо тест.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Ищу простой быстрый алгоритм сжатия на С (не ++)
