v4.0: Changed parts of functions fftconv2 and gfbank_calcaxis

[allevity]

For a speed-up of about 1.4 on tested matrices

[m-r-s]

Thank you for your contribution!

Could you provide the matrices or their size and number?
Typical sizes would be probably between 23x100 and 31x1000.

Did you benchmark the code with Matlab (which version) or Octave (which version and BLAS library)?

Best regards,
Marc

[allevity]

Hi Marc-René,

My pleasure!

I tested yesterday on a few matrices not output by log_el_spectrogram, so I just did test this. Tested with num_bands=31, 62 and 23, code v3.0 and v.4.0 (6 different colours), and a matrix logmelspec initially of size 31x408 (when the waveform 'signal' is of length 65639). I vary the length of the signal to be in [500 1000 5000 10000 50000 100000 500000].

Code used:

[signal, fs] = audioread(listWavsTIMIT{kk});
logmelspec = log_mel_spectrogram(sig,fs);
listt = [1 floor(2.^(1.2:0.5:5))];
bigsig = repmat(signal, 20,1);
listLengths = [500 1000 5000 10000 50000 100000 500000];
num_bandslist = [23 31 62];
t1 = zeros(length(listLengths), length(num_bandslist));
t2 = zeros(length(listLengths), length(num_bandslist));
for nn=1:length(num_bandslist)
num_bands = num_bandslist(nn);
for kk=1:length(listLengths)
fprintf('%d,%d\n',nn,kk);
%nr = listt(kk);
%bigsig = repmat(sig, nr,1);
sig = bigsig(1:listLengths(kk));
logmelspec = log_mel_spectrogram(sig,fs, [], [], [], num_bands);

    tic
    gbfbOriginal(logmelspec); % v3
    t1(kk,nn)=toc;

    tic
    gbfb(logmelspec); %v4
    t2(kk,nn) = toc;
end

end

figure ;
for nn=1:length(num_bandslist)
loglog(listLengths, t1(:,nn), 'DisplayName', sprintf('v3.0 - %d numbands', num_bandslist(nn)));
hold on;
loglog(listLengths, t2(:,nn), 'DisplayName', sprintf('V4.0 - %d numbands', num_bandslist(nn)));
end
legend show;
xlabel('Length of waveform')
ylabel('Time (s)');
title('Comparison of v3 and v4 for a matrix of varying sizes')
legend('Location', 'NorthWest')

Version :

MATLAB Version: 9.0.0.341360 (R2016a)
MATLAB License Number: 646274
Operating System: Mac OS X Version: 10.10.5 Build: 14F1808

Java Version: Java 1.7.0_75-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode

Result:

and

t1./t2

ans =

1.0168    1.1116    1.0456
0.9962    1.0451    1.0557
1.0785    1.1166    1.0520
1.0636    1.0229    1.0992
1.1237    1.0578    1.1842
1.0786    1.1750    1.1515
1.2661    1.1939    1.0521

So almost systematically v4 is faster, but less than what I observed yesterday.

By the way, I’m using your code to compare results on the TIMIT dataset. If the results are of interest to you, we can discuss it on Skype. I’m Alban, from the IHR in Nottingham we met last year in Groningen.

Cheers,
—
Alban

On Sep 16, 2016, at 08:37, Marc René Schädler notifications@github.com wrote:

Thank you for your contribution!

Could you provide the matrices or their size and number?
Typical sizes would be probably between 23x100 and 31x1000.

Did you benchmark the code with Matlab (which version) or Octave (which version and BLAS library)?

Best regards,
Marc

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #1 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ADHX9Krsu-O9m4kfU78ZJjkzlmPLmqc3ks5qqkdSgaJpZM4J-hrb.

[m-r-s]

Hi Alban,

thank you for your report! I appreciate that you use and try to improve the code.

This repository contains a reference implementation and mainly targets educational and academic use (at the cost of performance).
I want to keep the code easily understandable, and wont accept changes that improve performance at the cost of readability.

However, if you are interested in a high-performance version of the (S)GBFB feature extraction, we could think about a performance-optimized implementation in Matlab/Octave or an implementation in C. I don't have the resources for that at the moment because the performance of the feature extraction has never really been a bottleneck in my experiments.

By the way, the separable Gabor filter bank (SGBFB) processing is more efficient than the GBFB processing if it is used with, e.g., phases = {[0 0], [pi/2 pi/2]}; (c.f. the corresponding publication). And histogram equalization (HEQ) is much slower that mean-and-variance normalization (MVN).

I am always interested in published results that use GBFB or, even better, SGBFB features.
If you would like feedback on some unpublished results, you can send me an e-mail and I will see what I can do :)

Best,
Marc

[allevity]

Hi Marc,

I appreciate your code is meant to remain clean. In the previous
weeks, I was continuously running simulations, so I simply looked for
simple ways to speed-up the runs, rather than looking for a proper
performance-optimised version. Note that given the GBFB function, I’m
not sure that a C implementation would be faster than a GPU-boosted
Matlab implementation.

In the beginning, I wasn’t using the SGBFB function much since in my
evaluations it was giving fairly similar results, but I think that the
best score I obtained was with it in the end.

Thank you for your offer to discuss the results. At the moment, I
stopped working with those features and TIMIT, and am shifting to a
simpler task (digits). I’d be happy to verify with you I use those
functions correctly at some point, in order to give them a fair
comparison ;)

Best,

—

Alban

On Sep 19, 2016, at 09:51, Marc René Schädler notifications@github.com wrote:

Hi Alban,

thank you for your report! I appreciate that you use and try to
improve the code.

This repository contains a reference implementation and mainly targets
educational and academic use (at the cost of performance).

I want to keep the code easily understandable, and wont accept changes
that improve performance at the cost of readability.

However, if you are interested in a high-performance version of the
(S)GBFB feature extraction, we could think about a
performance-optimized implementation in Matlab/Octave or an
implementation in C. I don't have the resources for that at the moment
because the performance of the feature extraction has never really
been a bottleneck in my experiments.

By the way, the separable Gabor filter bank (SGBFB) processing is more
efficient than the GBFB processing if it is used with, e.g., phases =
{[0 0], [pi/2 pi/2]}; (c.f. the corresponding publication). And
histogram equalization (HEQ) is much slower that mean-and-variance
normalization (MVN).

I am always interested in published results that use GBFB or, even
better, SGBFB features.

If you would like feedback on some unpublished results, you can send
me an e-mail and I will see what I can do :)

Best,

Marc

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub, or mute the thread.