• Java programming народ я малость того: в программе осуществляется много раз преобразование цвета из пространства YUV в RGB и обратно, так вот, сделал математику для этого, сделал её целочисленной (домножая на 2^n и потом делая смещение вправо на n бит). математика работает. Решили попробовать оптимиздинг: число цветов 2^24, вполне можем выделить памяти на два массива по 64 метров, предварительно рассчитать, заполнить таблички, и потом по индексу, которым будет сам цвет, брать нужные значения. Внимание вопрос: в каком месте я туплю, но почему из массива данные берутся МЕДЛЕННЕЕ чем расчет по формуле. Причем значительно так: алгоритм работает с математикой на 15 секунд быстрее (40 и 55 секунд соответственно).

    массивы: byte[] rgb2yuv_table = new byte[size]; // size = 2^24*3

Replies (6)

  • @hatred, Наверняка, из–за времени доступа к произвольному участку памяти. Обращение к незакешированной строчке памяти в сотни раз медленнее может быть.
  • @hatred, этот твой пост — почти как роман на ночь =) надеюсь конец у него будет счастливый =)
  • @ladynoname, ну у меня-то день)))) а вообще, погляди, у меня такого много)
  • @OCTAGRAM, да я несколько раз наталкивался на утверждения что при доступе к массиву время константно и быстро... наверное верно для Си (хотя видел в контексте именно java-тредов), просто java плохо знаю, нюансы такие). Да, ByteBuffer что директ, что индирект, ещё медленней.
  • @hatred, Оно константно и быстро по сравнению со связными списками, AVL деревьями etc. Разница в скорости из–за архитектуры — современные процессоры работают быстрее, чем память, и разница достигает сотен раз. Язык программирования значения не имеет. Имеет значение частота процессора и памяти. На мобильных устройствах с относительно небыстрыми процессорами, скорее всего, этой разницы не будет заметно.
  • @OCTAGRAM, не задумывался, блин и про кеш теперь понял