Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Resurrecting/Preserving the Helix MP3 encoder (Read 94083 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #575 –
@Case thanks for testing. It appears that 32 vs. 64 bit and GCC vs Visual Studio makes much more of a difference than -ffast-math or not. So I guess that in the future, one can simply enable fast math.

@KeB5379 Those speeds are indeed wild. I'm on a Ryzen 7 PRO 4750G APU, which is the previous generation of what you have.

For me, a CD album of 4501 seconds (1:15:01) of play time encodes in 8.5 seconds (64 bit Linux GCC build), which is about 529.5x speed. So I guess your encodes are done in parallel, which, of course, is fine.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #576 –
Quote from: maikmerten on
@Case thanks for testing. It appears that 32 vs. 64 bit and GCC vs Visual Studio makes much more of a difference than -ffast-math or not. So I guess that in the future, one can simply enable fast math.

@KeB5379 Those speeds are indeed wild. I'm on a Ryzen 7 PRO 4750G APU, which is the previous generation of what you have.

For me, a CD album of 4501 seconds (1:15:01) of play time encodes in 8.5 seconds (64 bit Linux GCC build), which is about 529.5x speed. So I guess your encodes are done in parallel, which, of course, is fine.

Yes, I am using foobar2000 at it's default encoding preferences, so it's utilizing all 8 cores and 16 threads.  I've thought about trying to encode on say 4 cores and see what happens...or maybe even just one.  I am very impressed with Helix, it's good quality coupled with lightning fast speed.

I've also tried the SIMD optimized version of LAME you pointed to me once in a PM, and I tried the 64 bit version.  With that and foobar's default encoding preferences, I get about 1200 ~ 1500x realtime.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #577 –
Interesting...

I'm getting 1900x realtime on i5 10400F (Joshua's Clang version) using foobar2000 v1.68 (default settings) on double CD album (28 songs).

BTW, I'm following this thread closely and I'm wondering which of all these versions should be considered standard/reliable?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #578 –
@synclagz As far as I know, none of the compiles discussed here have exhibited particular problems. So I'd recommend just going with a build that works well for your machine and please report back if you encounter problems.

@KevinB52379 Btw, can you re-try a 64 bit build that causes freezing-problems, but with SMT (two threads per CPU core) disabled? On my Ryzen 7 4750G on Linux, I sometimes encounter sluggish response behavior when maxing out all 16 threads. Alternatively, the 64 bit builds should be faster when restricted to 8 threads (loading all CPU cores), compared to the 32 bit builds running on 16 threads (loading all CPU threads).

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #579 –
Quote from: maikmerten on
@synclagz As far as I know, none of the compiles discussed here have exhibited particular problems. So I'd recommend just going with a build that works well for your machine and please report back if you encounter problems.

@KevinB52379 Btw, can you re-try a 64 bit build that causes freezing-problems, but with SMT (two threads per CPU core) disabled? On my Ryzen 7 4750G on Linux, I sometimes encounter sluggish response behavior when maxing out all 16 threads. Alternatively, the 64 bit builds should be faster when restricted to 8 threads (loading all CPU cores), compared to the 32 bit builds running on 16 threads (loading all CPU threads).

I did go in foobar2000 advanced options, I searched for thread and changed the number to 8 under the converter branch.

Do you have a 64 bit version that meets that criteria?  I'll give it a shot, why not?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #580 –
I've tried to build a PGO version with clang18, seems the optimized version have about 5% speed gain under my system.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #581 –
Quote from: KevinB52379 on
I did go in foobar2000 advanced options, I searched for thread and changed the number to 8 under the converter branch.

Do you have a 64 bit version that meets that criteria?  I'll give it a shot, why not?

If I understand correctly, basically any 64 bit version that is not clang caused problems for you. Wombat provided both a clang and a gcc build at https://hydrogenaud.io/index.php/topic,123331.msg1045509.html#msg1045509 - and I wonder if with reduced thread count, the gcc build ends up working okay.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #582 –
Quote from: JoshuaChang on
I've tried to build a PGO version with clang18, seems the optimized version have about 5% speed gain under my system.
Thanks! This must be the fastest non fast-math generic CPU attempt. On my 5900x foobar does it in ~4750x speed against  ~4700x with lto only.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #583 –
Quote from: Wombat on
Quote from: JoshuaChang on
I've tried to build a PGO version with clang18, seems the optimized version have about 5% speed gain under my system.
Thanks! This must be the fastest non fast-math generic CPU attempt. On my 5900x foobar does it in ~4750x speed against  ~4700x with lto only.

Yes, for me on AMD Ryzen 7 5700g, this compile is the fastest speeds I've seen yet, 2300x to 2700x using all cores and threads.

I also tried Wombat's 64 bit compile with just using 8 threads, and this now seems fine as well, but not as fast as Joshua's build.

Thanks for the suggestion to limit the threads!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #584 –
Quote from: maikmerten on
Quote from: KevinB52379 on
I did go in foobar2000 advanced options, I searched for thread and changed the number to 8 under the converter branch.

Do you have a 64 bit version that meets that criteria?  I'll give it a shot, why not?

If I understand correctly, basically any 64 bit version that is not clang caused problems for you. Wombat provided both a clang and a gcc build at https://hydrogenaud.io/index.php/topic,123331.msg1045509.html#msg1045509 - and I wonder if with reduced thread count, the gcc build ends up working okay.

Wait, let me clarify.  The GCC version of Wombat's 64 bit version causes the freezing issue.  The Clang version works perfectly fine.
Thanks @Wombat

@JoshuaChang - your version works great too Thanks!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #585 –
Quote from: JoshuaChang on
I've tried to build a PGO version with clang18, seems the optimized version have about 5% speed gain under my system.

I confirm a small speedup with my setup on older Intel mobile platform as well:
rel. 5.2.4 (Joshua's Clang), 190x = rel. 5.2.4 (Wombat's Clang), 185x
The difference is a tiny bit bigger, as it was with John's fast-math GCC, impressive.
But yeah, many things influence this, so everyone chooses according to what her/his platform tastes best.
Thanks a lot for the builds, guys!
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #587 –
One thing I've been pondering for a future release is improving hmp3's ability to serve as a web-radio encoder. MP3 still is very much in use there for maximum compatibility. Also, it seems most radios use CBR (meh) - and CBR is pretty robust in Helix.

Currently, hmp3 buffers quite a lot of data before flushing output to file or stdout: The encoding application will wait for ~126 KB before triggering a flush (variable "bs_trigger" in tomp3.cpp). For 128 kpbs streams, that's about 10 seconds of delay, for low-bitrate streams like 32 kbps (for that authentic dialup multimedia experience), that's about 40 seconds of delay.

For web radio, I guess it's best to flush encoded frames directly. This is trivial to fix, and I consider flushing packets directly if the output is stdout...

@Case Any opinions if "always quick flush to stdout" makes sense - or should this be behind a switch ("-QF" for quick flush or "-LD" for low delay....)

Flushing every packet (to stdout, to file can be another story) doesn't seem to impact performance significantly, so I wonder if a switch makes any sense at all here.

Code: [Select]
time hmp3 test.wav - > test.mp3

(Duration of test.wav: 01:15:01.00)


Flush on every packet:

real	0m8,593s
user	0m8,467s
sys	0m0,108s

real	0m8,591s
user	0m8,445s
sys	0m0,138s

real	0m8,615s
user	0m8,448s
sys	0m0,128s


Flush every ~126 KB:

real	0m8,594s
user	0m8,515s
sys	0m0,072s

real	0m8,666s
user	0m8,565s
sys	0m0,092s

real	0m8,571s
user	0m8,457s
sys	0m0,112s

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #588 –
Intuitively I expected the rather big output buffer to be a benefit speedwise and against file fragmentation, but changing writes to happen all the time doesn't seem to cause any slowdown and file fragmentation seems to actually be reduced in my quick test. At this point I don't think a switch is needed and the change seems safe.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #591 –
Heh, thanks for your reliable services, john :-)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #592 –
It really seems for me on my AMD Ryzen 7 5700g that any 64 bit GCC compiles seem to cause the weird hang/system unresponsiveness issue.

Yet, the CLANG 64 bit builds work fine.

John's 32 bit development build above works fine, but the 64 bit version causes my system to hang (so the intel compile 32 bit version works as expected, although slower than 64 bit build of CLANG compile of Helix).

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #594 –
Quote from: john33 on
@KevinB52379, could you try this Clang build please, just out of curiosity?
https://www.rarewares.org/files/mp3/hmp3-dev-5.2.4-20240612-clang.zip
and let me know whether that runs. TIA.

Yes, this works perfectly.  No hangups or system freezing and encoding speed with foobar is 2300~2700x on all cores/threads.

Thank you!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #595 –
Not exactly related but since we did some speed testing here i see an update to Win11 26100.712 24H2 preview drops performance from ~4750 to ~4600 with the fast builds together with my 5900x.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #596 –
Might be some CPU-related operating system shenanigans, e.g., another round of security mitigation, CPU scheduling changes or power management.

(A few weeks back, when hmp3 was much more syscall-heavy (progress printing), I saw a rather surprising impact of disabling CPU mitigations for my Ryzen 4750G)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #597 –
This was my first idea also. A script reads out the mitigations show the exact same settings for my last 23H2 and 24H2. It may be some new mitigation maybe. Energy savings are the same also.
Maybe some debugging code is still running because it is still a preview.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #598 –
Quote from: KevinB52379 on
Yes, this works perfectly.  No hangups or system freezing and encoding speed with foobar is 2300~2700x on all cores/threads.

Thank you!
Thanks for letting me know. I'll include a Clang compile in the future.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #599 –
@KevinB52379, could you please give this GCC x64 build a try? All my previous GCCx64 offerings had the 'msvcrt' dependency whereas this one has the 'ucrt' dependency which the Clang compiles also depend on. Will it make any difference? I guess we're about to find out!
https://www.rarewares.org/files/mp3/hmp3-dev-5.2.4-20240612-UCRT64.zip