Quote from: Replica9000 on 2023-04-12 22:32:28

has about a 4 second advantage
about a 4 second disadvantage compared to Clang when enabled.

Second ... per what? (Did you mean percent?)

On my Ryzen 5850U, building with AOCC 4.0 is the same performance as regular Clang 16.  Building with -march=znver3 or the generic x86-64-v3 doesn't make a difference either.  For 44.1/16 audio, GCC has about a 4 second advantage with my 1.2GB file over Clang with ASM optimizations disabled, and about a 4 second disadvantage compared to Clang when enabled.

by the way, geniuses, with senior audiophiles, I wasn't referring to people with ears made up of gold... I was talking about people who are senior in age, the 50-60 year old crowd which isn't as computer savvy as us and are possibly using their 2002 marantz receiver because it's dac sounds warmer to them.. pun intended.. equipment like that is not made with intel processors smh... those Motorola or other Chinese chips could indeed mess up if you give them an input or a task too complex. The same goes for car receivers which are manufactured even today, except the extreme top of the line, none of them are using the latest and greatest in processing power or their operating system. A few lines of unoptimised code in their decoding mechanism and there you have a stuttering player that cannot decode a 256mb flac file without choking thrice every minute.. I have seen this happen, literally in my brand new car or in my friend's cars... just connecting them with AirPlay through a lightning cable sometimes makes the devices hang.. which is a fact.

Maybe start using a pragmatic lens and view the reality rather than throwing slurs and bookish know-how at me. No one is siding with anti-vaxxer style audiophiles that use gold-plated ram, but rather with actual human beings who seem to be stuck with inferiorly manufactured equipment. Those equipment would still be used by these people irrespective of what you tell them because they love the sound that the device is creating from other mediums and they'd rather not replace their beloved DAC just because they cannot get it to play some huge file properly. Same goes for car receivers, the airplay may very well not work in my car, but it is integrated really well with all the sensors present inside, due to which, no matter what anyone tells me, I'm not gonna change that device just because it performs poor in one area. There are other things to consider as well. That's what a practical view is. Tell me which part of this does not strike true in the real world. Rather than slurring or mocking a genuine perspective, maybe develop some patience and humility. Certain devices like these which are integrated have various other limitations as well, for instance, only supporting SATA1.0 hard drivers or the older IDE hard drives. Try doing benchmarks on such trash equipment. Seeking a file would crash you out in seconds. Yet these machines remain heavy in use because barring the particular problematic aspect, they perform reliably and excellently in all other facets.

No one is saying that your work is trash or that the audiophiles that behave like karens are right, rather all I'm saying is treat some of them with respect because even they have genuine points at times. Going all psycho on them is neither a pragmatic nor a humble way to treat anyone.

All of the above is not some fairytale or highly specific text book style example that has no relevance to the real world, but is literally a bunch of incidents that I keep striking with every now and then.. which is why some points do seem valid to me, and by now, hopefully to you as well.

I'm done posting on this particular facet, irrespective of whatever I just said about humility, I know that talking this further would only escalate it to hostile levels, which is clearly not my goal here. So I'm done talking about this topic.

Peace

Quote from: Replica9000 on 2023-04-12 22:32:28

On my Ryzen 5850U, building with AOCC 4.0 is the same performance as regular Clang 16.  Building with -march=znver3 or the generic x86-64-v3 doesn't make a difference either.  For 44.1/16 audio, GCC has about a 4 second advantage with my 1.2GB file over Clang with ASM optimizations disabled, and about a 4 second disadvantage compared to Clang when enabled.

Could you please share this AOCC version? It's the official AMD compiler, I am keen on testing it.

Thank you very much.

* Going full -l32 on high sampling rates:
My first reaction was, this will shock those who use "-8e", I checked one high-resolution file that now takes 4x the time of 1.4.2. That is even if the reduced number of apodization functions speeds up -8el12 to half the time of 1.4.2.

But the thing is, -e still has a mission on some high sampling rates, that is the problem. At least it had on 1.4.2, I'll test this one

To take this a bit I ran a five minutes long stereo stupid-resolution 384/32 file (download link), same as mentioned here. FLAC can compress it to below 40 percent of WAVE, yay.  -l32 makes for bigger files (at three-ish times the time consumption!) but that is not the point here: the point is how the proposed -8 will likely get you complaints from -e users:
at -l 12, a "-e" increases time by a factor of five-ish; at -l 32, the "-e" increases time by a factor of 11-ish

(Actually -8el32 encodes slower than realtime on an i5 CPU. Even the retune, which is three times faster due to ... stepping down the subdivide_tukey I guess?)

-e has its merits at this sample rate: 1.4.2 at -8 vs -8e, the latter saves 7% file size. Would be good if the new order selection algorithm could do something about it - it is easier to reply "then don't use -e" if you can point at it not doing much anymore.