История изменений

На самом деле, оптимизации под современные процессоры не повредили бы Гимпу

Ну, не повредили бы - это конечно да.
Но тут возникает, как мне видится, несколько проблем.
1) просто добавлением флага в компилятор особого прироста не добавиться. Необходимо изначально писать код заточенный под векторизацию и производить её вручную, там где это нужно. А тот, что уже написан, внимательно переделывать. Это не так просто, там куча нюансов.
2) avx таки есть не везде. Надо расставлять дефайны и сделать в gegl функции определения наличия поддержки CPU (это несложно)
3) для всего этого нужен заинтересованный человек с громадным количеством свободного времени и соответствующим опытом.

Вот, допустим, к меня есть некоторый опыт ручной векторизации, но адово не хватает сил и времени даже Фурье покрутить, который в предыдущем топике по Гимпу хотел (и хочу) поделать. Вкратце, я набросал прототип gegl-операции -> собрал/погонял его в Гимпе на фотках с сайта Хаббла -> понял, что kissfft, мягко говоря, не вывозит по производительности (1,5 минуты одно FT на 7500x6500 - это больно, при том, что загрузил все 4 ядра в топ), если мы не попадаем в определённую длину сигнала -> засел урывками велосипедить, авось не надоест.

4) Как мне кажется, у gegl есть несколько других сложностей, которые при их разрешении дали бы очень существенный эффект. Вот, КМК например, невозможность проводить предвычисления перед запуском процессов обработки тайлов.
Поясню. Вот есть в операции 1d блюра вычисление сверточных матриц (iir или fir, не важно), которое, в принципе, зависит только от sigma и вычислить его достаточно 1 раз. Но поскольку предвычислить и предоставить уже готовую матрицу в операцию обработки тайла мы, как я понял, не можем, то перевычислять эту самую сверточную матрицу приходится для каждого тайла, а поскольку тайлы маленькие, то получается вполне такой оверхэд.

На самом деле, оптимизации под современные процессоры не повредили бы Гимпу

Ну, не повредили бы - это конечно да.
Но тут возникает, как мне видится, несколько проблем.
1) просто добавлением флага в компилятор особого прироста не добавиться. Необходимо изначально писать код заточенный под векторизацию и производить её вручную, там где это нужно. А тот, что уже написан, внимательно переделывать. Это не так просто, там куча нюансов.
2) avx таки есть не везде. Надо делать расставлять дефайны и сделать в gegl функции определения наличия поддержки CPU (это несложно)
3) для всего этого нужен заинтересованный человек с громадным количеством свободного времени и соответствующим опытом.

Вот, допустим, к меня есть некоторый опыт ручной векторизации, но адово не хватает сил и времени даже Фурье покрутить, который в предыдущем топике по Гимпу хотел (и хочу) поделать. Вкратце, я набросал прототип gegl-операции -> собрал/погонял его в Гимпе на фотках с сайта Хаббла -> понял, что kissfft, мягко говоря, не вывозит по производительности (1,5 минуты одно FT на 7500x6500 - это больно, при том, что загрузил все 4 ядра в топ), если мы не попадаем в определённую длину сигнала -> засел урывками велосипедить, авось не надоест.

4) Как мне кажется, у gegl есть несколько других сложностей, которые при их разрешении дали бы очень существенный эффект. Вот, КМК например, невозможность проводить предвычисления перед запуском процессов обработки тайлов.
Поясню. Вот есть в операции 1d блюра вычисление сверточных матриц (iir или fir, не важно), которое, в принципе, зависит только от sigma и вычислить его достаточно 1 раз. Но поскольку предвычислить и предоставить уже готовую матрицу в операцию обработки тайла мы, как я понял, не можем, то перевычислять эту самую сверточную матрицу приходится для каждого тайла, а поскольку тайлы маленькие, то получается вполне такой оверхэд.

На самом деле, оптимизации под современные процессоры не повредили бы Гимпу

Ну, не повредили бы - это конечно да.
Но тут возникает, как мне видится, несколько проблем.
1) просто добавлением флага в компилятор особого прироста не добавиться. Необходимо изначально писать код заточенный под векторизацию и производить её вручную, там где это нужно. А тот, что уже написан, внимательно переделывать. Это не так просто, там куча нюансов.
2) avx таки есть не везде. Надо делать расставлять дефайны и сделать в gegl функции определения наличия поддержки CPU (это несложно)
3) для всего этого нужен заинтересованный человек с громадным количеством свободного времени и соответствующим опытом.

Вот, допустим, к меня есть некоторый опыт ручной векторизации, но адово не хватает сил и времени даже Фурье покрутить, который в предыдущем топике по Гимпу хотел (и хочу) поделать. Вкратце, я набросал прототип gegl-операции -> собрал/погонял его в Гимпе на фотках с сайта Хаббла -> понял, что kissfft, мягко говоря, не вывозит по производительности (1,5 минуты одно FT на 7500x6500 - это больно, при том, что загрузил все 4 ядра в топ), если мы не попадаем в определённую длину сигнала -> засел урывками велосипедить, авось не надоест.

4) Как мне кажется, у gegl есть несколько других сложностей, которые при их разрешении дали бы очень существенный эффект. Вот, КМК например, невозможность проводить предвычисления перед запуском процессов обработки тайлов.
Поясню. Вот есть в операции 1d блюра вычисление сверточных матриц (iir или fir, не важно), которое, в принципе, зависит только от sigma и вычислить его достаточно 1 раз. Но поскольку предвычислить и предоставить уже готовую матрицу в операцию обработки тайла мы не можем, то перевычислять эту самую сверточную матрицу приходится для каждого тайла, а поскольку тайлы маленькие, то получается вполне такой оверхэд.

На самом деле, оптимизации под современные процессоры не повредили бы Гимпу

Ну, не повредили бы - это конечно да.
Но тут возникает, как мне видится, несколько проблем.
1) просто добавлением флага в компилятор особого прироста не добавиться. Необходимо изначально писать код заточенный под векторизацию и производить её вручную, там где это нужно. А тот, что уже написан, внимательно переделывать. Это не так просто, там куча нюансов.
2) avx таки есть не везде. Надо делать расставлять дефайны и сделать в gegl функции определения наличия поддержки CPU (это несложно)
3) для всего этого нужен заинтересованный человек с громадным количеством свободного времени и соответствующим опытом.

Вот, допустим, к меня есть некоторый опыт ручной векторизации, но адово не хватает сил и времени даже Фурье покрутить, который в предыдущем топике по Гимпу хотел (и хочу) поделать. Вкратце, я набросал прототип gegl-операции -> собрал/погонял его в Гимпе на фотках с сайта Хаббла -> понял, что kissfft, мягко говоря, не вывозит по производительности (1,5 минуты одно FT на 7500x6500 - это больно, при том, что загрузил все 4 ядра в топ), если мы не попадаем в определённую длину сигнала -> засел урывками велосипедить, авось не надоест.

4) Как мне кажется, у gegl есть несколько других сложностей, которые при их разрешении дали бы очень существенный эффект. Вот, КМК например, возможность проводить предвычисления перед запуском процессов обработки тайлов.
Поясню. Вот есть в операции 1d блюра вычисление сверточных матриц (iir или fir, не важно), которое, в принципе, зависит только от sigma и вычислить его достаточно 1 раз. Но поскольку предвычислить и предоставить уже готовую матрицу в операцию обработки тайла мы не можем, то перевычислять эту самую сверточную матрицу приходится для каждого тайла, а поскольку тайлы маленькие, то получается вполне такой оверхэд.

На самом деле, оптимизации под современные процессоры не повредили бы Гимпу

Ну, не повредили бы - это конечно да.
Но тут возникает, как мне видится, несколько проблем.
1) просто добавлением флага в компилятор особого прироста не добавиться. Необходимо изначально писать код заточенный под векторизацию и производить её вручную, там где это нужно. А тот, что уже написан, внимательно переделывать. Это не так просто, там куча нюансов.
2) avx таки есть не везде. Надо делать расставлять дефайны и сделать в gegl функции определения наличия поддержки CPU (это несложно)
3) для всего этого нужен заинтересованный человек с громадным количеством свободного времени и соответствующим опытом.

Вот, допустим, к меня есть некоторый опыт ручной векторизации, но адово не хватает сил и времени даже Фурье покрутить, который в предыдущем топике по Гимпу хотел (и хочу) поделать. Вкратце, я набросал прототип gegl-операции -> собрал/погонял его в Гимпе на фотках с сайта Хаббла -> понял, что kissfft, мягко говоря, не вывозит по производительности (1,5 минуты одно FT на 7500x6500 -> это больно, при том, что загрузил все 4 ядра в топ), если мы не попадаем в определённую длину сигнала -> засел урывками велосипедить, авось не надоест.

4) Как мне кажется, у gegl есть несколько других сложностей, которые при их разрешении дали бы очень существенный эффект. Вот, КМК например, возможность проводить предвычисления перед запуском процессов обработки тайлов.
Поясню. Вот есть в операции 1d блюра вычисление сверточных матриц (iir или fir, не важно), которое, в принципе, зависит только от sigma и вычислить его достаточно 1 раз. Но поскольку предвычислить и предоставить уже готовую матрицу в операцию обработки тайла мы не можем, то перевычислять эту самую сверточную матрицу приходится для каждого тайла, а поскольку тайлы маленькие, то получается вполне такой оверхэд.