Была аналогичная ситуация, когда proguard мешал рефлексии, но там обошелся сравнением instaceof/Class.cast().
Еще был вариант — получал ВСЕ поля, и сравнивал типы.
… А потом все равно пришлось от этой глючной возможности отказываться.
Кроме того, что в OpenCL мне разобраться показалось намного сложнее, чем в Куде,
в первом же результате:
«Although the portability resulted in a slightly reduced performance (10–35%) of the OpenCL-accelerated FDTD simulations compared with… Open Multiprocessing implementations»
Акустикой я никогда не занимался. Знаю, что впервые такие сетки использовались в гидродинамике, для векторов давления и скорости.
Нужно смотреть конкретные уравнения. Возможно, в акустике будет проще.
По сути, это уравнения Максвелла — то, что до волн. Если нужны просто волны — там более быстрые методы.
131 МБайт — это и есть объем массивов двух компонент. А Джава-машина сама жрет много.
Но главное — я проверил gcc 64 6.2 -march=native. На широких задачах (16384 — лучше для 4 ядер) на 35% быстрее старого.
Но VisualStudio еще на 3-10% быстрее.
Мой старый проект завален какими-то левыми файлами, создал чистый 4-ядерный.
https://cloud.mail.ru/public/8K8G/VCRZSJQTt
Есть профит по сравнению с ГСС во всех случаях.
Скоро обновлю в статье
У вас что-то не так с компилятором. Возможно, О3 рулит.
i7-4771
Моя версия выполняется 22,3 секунд
ваша в моем компиляторе 22,4 (конечно, это тоже самое)
Ваш АВХ 23,2
Ваша без инструкций 93,5 секунд
Еще вычитал:
«Согласно протоколам согласованности кеша (cache coherence protocols), если ядро пишет в кеш-строку, то строка в другом ядре, ссылающаяся на ту же память, признаётся недействительной (пробуксовка кеша, cache trashing). В результате при каждой операции записи возникают блокировки памяти.»
У меня такое возможно на середине массива. То есть задача влазит в кеш, но пишется с проблемами.
В JDK 9.
И про Сорс на картинке.
Еще был вариант — получал ВСЕ поля, и сравнивал типы.
… А потом все равно пришлось от этой глючной возможности отказываться.
в первом же результате:
«Although the portability resulted in a slightly reduced performance (10–35%) of the OpenCL-accelerated FDTD simulations compared with… Open Multiprocessing implementations»
https://github.com/VolodymyrKoliadenko/FDTD-2threads/tree/master/Matlab
TE TM версии и матричную.
Но там весьма неаккуратно.
Нужно смотреть конкретные уравнения. Возможно, в акустике будет проще.
По сути, это уравнения Максвелла — то, что до волн. Если нужны просто волны — там более быстрые методы.
значит таяние льда — около 273,148 К, потому что шкалу сдвинули
Так что главное в работе программиста — довести работу до конца.
Но главное — я проверил gcc 64 6.2 -march=native. На широких задачах (16384 — лучше для 4 ядер) на 35% быстрее старого.
Но VisualStudio еще на 3-10% быстрее.
https://cloud.mail.ru/public/8K8G/VCRZSJQTt
Есть профит по сравнению с ГСС во всех случаях.
Скоро обновлю в статье
i7-4771
Моя версия выполняется 22,3 секунд
ваша в моем компиляторе 22,4 (конечно, это тоже самое)
Ваш АВХ 23,2
Ваша без инструкций 93,5 секунд
После установки гсс оно появится?
Под студию был 1-ядерный.
Постараюсь сегодня сделать 2-4.
«Согласно протоколам согласованности кеша (cache coherence protocols), если ядро пишет в кеш-строку, то строка в другом ядре, ссылающаяся на ту же память, признаётся недействительной (пробуксовка кеша, cache trashing). В результате при каждой операции записи возникают блокировки памяти.»
У меня такое возможно на середине массива. То есть задача влазит в кеш, но пишется с проблемами.
И добавив в конце FDTDmainFunction
Чтоб я мог сравнить скорость программы и результат