[deveac]

>The fact that they found a code path that ensures particular programs get the full hardware speed does not mean that no other code path enables that performance level.

When those particular programs are benchmarks and the path is coded specifically to boost performance on a unique set of said benchmarks in contrast to the most common use cases, that's an issue regardless of whether or not you can imagine an outlier real-world scenario that utilizes a code path that tweaks the performance.

You have to bend over backwards to see that as anything other than dishonest.

[Schlaefer]

> You have to bend over backwards to see that as anything other than dishonest.

"Our new hot device has this awesome performance mode but those benchmarks aren't aware for it and it won't be utilized in the device reviews. So let's make sure it's used in these benchmark applications."

If they just flip the switches available to every developer/application it's not necessarily dishonest just tech marketing.

[joesb]

1. If this awesome performance mode is turned on automatically when the app needs it. Then it must have turn on automatically for the benchmark without actually checking the application name, right?

2. Otherwise, if it require the application to be aware to utilize this feature, then why hasn't Samsung announce this "mode" to developer to utilize it yet?

[deveac]

A high-performant mode would be a feature that would be marketed and lauded by the OEM, not something hidden from view and hardcoded only to benchmark testers.

Also, benchmarks are designed to compare apples to apples, so if, as you suggest, the high-performant mode wouldn't be triggered by benchmark use-cases normally, then hard coding the exception is dishonest, as the only explanation is turning your apple into an orange.