アカウント名:
パスワード:
対応されてしまって正当な評価ができないならそれはもう使えなくて。別の手段で評価するしかないだろうけど、めんどくさいからチートとして晒して区別して終わるのかな。と邪推。いや、ほんまはそういうの対応する方があらぬ方向の徒労というかご苦労様でその分正統に努力しろよってことなんだけど。
Android端末メーカーは「Futuremarkのベンチマークのルール」を守らないといけないと(Googleに?)定められているのかってのが少し気になる。それともそれは、業界内での暗黙のルールというかフェアプレイ精神でしょうか。そこを守らないとお互いの開発結果が正当に評価できないから、ちゃんと守ろうぜってな感じ。
だとしたらそれはきっとアジアの片隅ではあまりなじみが無い習慣だというのに欧州か北欧の人たちにはわからなかったんだろうね。#それはちょっと言い過ぎか
ベンチマークだけクロックアップしている時点で詐欺。PCでも散々発覚して叩かれてきたことだけれど、まさかアジアの片隅では馴染みが薄いなんて表現が飛び出すとは。しかもGalaxyはGalaxy 2で既におこなっているのが明白だったし、ずっと継続して詐欺をおこなっている状態。
ベンチマークの結果を参照しながらチューニングは普通にしたりする。そうすると、そのベンチマークに特化した(ベンチマーク結果が上がるが通常使用では意味なし)チューニングしてしまうことがある。そういう面から見るとこういう方法を取ってしまったのも分かる気がする。
使用されてる命令基準ならそうなるのもわかりますが、サムチョンは「ベンチマークのプロセス名」で、リミッタはずすってやってますので、
>ベンチマークの結果を参照しながらチューニング
とは全くの別物です。同じバイナリでプロセス名かえるとスコア7ががくんと落ちますw
ベンチマークでの数値が開発目標に入っていると、以下をたどるんだよ。
チューニング目的がベンチマークでいい結果を出すことになってしまう。↓命令の並びとかも決めうちでチューニングする。↓ベンチマークを早くする結果しかもたらさない。↓じゃあ、もうベンチマーク結果が良かったらなんでもいいじゃん。
>命令の並びとかも決めうちでチューニングする。
だからこれならOKなんですよ。開発ソフトのチューニングではなく、ハード(とそのファーム)の話ですので。
同じ並びの命令があるソフトなら「固定のベンチマークソフト」以外でも、たまたま同じ並びの命令であれば恩恵が受けられる(同じパフォーマンスがでる。 同じソフトであればプロセス名が違っても同じ結果がでる)
>じゃあ、もうベンチマーク結果が良かったらなんでもいいじゃん。これはアウトです。ユーザーが実際の使用時にそのパフォーマンスが出ることはないので。
「ベンチマークプロセス名(ホワイトリスト)をもとにクロックアップ」なんてした場合、そのベンチマーク以外でそのパフォーマンスが出ることはなく、同じベンチマークでもプロセス名変えただけででなくなります。
最初から「スコアを詐欺する事だけが目的」になってしまう。
ベンチマークソフト以外もホワイトリストに含まれているならグレーなんですけどね。
> これはアウトです。ユーザーが実際の使用時にそのパフォーマンスが出ることはないので。
ベンチマークプロセス名がたまたま同じのに出くわしたらそのパフォーマンスがでるでしょ。
ベンチマーク結果を元に汎用的なチューニングをするんじゃなくて個別チューニングを許容するんなら、その延長上にあるクロックをあげるってのもやってしまうかもしれない。やっぱり。
>ベンチマークプロセス名がたまたま同じのに出くわしたらそのパフォーマンスがでるでしょ。
でません。そもそも「ベンチマークプロセス名がたまたま同じの」がありえないので。
「クロックをあげるチューニング、プロセス名を元にクロックを可変にする」これ自体は電池、やCPUアイドルを作って高負荷のプロセスになるべく回すためには許容範囲です。
ただ、「クロックをあげるホワイトリストにベンチマークプログラムしか書かれていない」
これがアウトなのです。ユーザーが使用する段階でそのパフォーマンスが出ることはないので、詐欺だけが目的です。
なので、「ベンチマーク以外の他のプログラムがホワイトリストにない以上黒、あるならばグレー」となります。
ごめん。やっぱり「ベンチマークプロセス名がたまたま同じ」はありえなくて、「ベンチマークに特化した命令の並び」の最適化はありえる、のは理解できないよ。
汎用ライブラリを作ったときに、ベンチマーク決め打ちの引数の時だけ早くなることをしたことあるが、この作業に意味は見出せなかったな。※引数は一般的に多用される値という根拠はなく、むしろ使われないという認識だった。
>ベンチマークに特化した命令の並びこれ自体はあくまでも、「命令の並び」に過ぎないでしょ。
普通のゲームでも、アプリでも、同じような処理があれば同じ命令文が並ぶ。結果、通常使用でもベンチマークと同じパフォーマンスが出ます。プロセス名、アプリ関係なく同じパフォーマンスが出ます。
極端な話、 1+1の単純計算を1000回やるとして、これが「命令特化」にふくまれている場合、ベンチマークに含まれていても、表計算ソフトに含まれていてもかかる時間は同じ。
「プロセス名でクロック制御」の場合は結果が変わる。つまりパフォーマンスが変わる。
プロセス名はアプリ固有なので、「プロセス名ホワイトリストでクロックを変える処理」なんてサムソンみたいな事をやった場合、「ホワイトリストにベンチマークしか含まれていない以上、実際にそのパフォーマンスが出ることはありません。」
なのでアウト。 ベンチマーク以外もホワイトリストにあるならユーザーはソフトによってはきちんとそのパフォーマンスが出るのでグレーそれだけの話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
評価方法 (スコア:-1, フレームのもと)
対応されてしまって正当な評価ができないならそれはもう使えなくて。
別の手段で評価するしかないだろうけど、めんどくさいからチートとして晒して区別して終わるのかな。
と邪推。
いや、ほんまはそういうの対応する方があらぬ方向の徒労というかご苦労様でその分正統に努力しろよってことなんだけど。
Android端末メーカーは「Futuremarkのベンチマークのルール」を守らないといけないと(Googleに?)定められているのかってのが少し気になる。
それともそれは、業界内での暗黙のルールというかフェアプレイ精神でしょうか。
そこを守らないとお互いの開発結果が正当に評価できないから、ちゃんと守ろうぜってな感じ。
だとしたらそれはきっとアジアの片隅ではあまりなじみが無い習慣だというのに欧州か北欧の人たちにはわからなかったんだろうね。
#それはちょっと言い過ぎか
Re:評価方法 (スコア:0)
ベンチマークだけクロックアップしている時点で詐欺。
PCでも散々発覚して叩かれてきたことだけれど、まさかアジアの片隅では馴染みが薄いなんて表現が飛び出すとは。
しかもGalaxyはGalaxy 2で既におこなっているのが明白だったし、ずっと継続して詐欺をおこなっている状態。
Re: (スコア:0)
ベンチマークの結果を参照しながらチューニングは普通にしたりする。
そうすると、そのベンチマークに特化した(ベンチマーク結果が上がるが通常使用では意味なし)チューニングしてしまうことがある。
そういう面から見るとこういう方法を取ってしまったのも分かる気がする。
Re: (スコア:0)
使用されてる命令基準ならそうなるのもわかりますが、サムチョンは「ベンチマークのプロセス名」で、
リミッタはずすってやってますので、
>ベンチマークの結果を参照しながらチューニング
とは全くの別物です。
同じバイナリでプロセス名かえるとスコア7ががくんと落ちますw
Re: (スコア:0)
ベンチマークでの数値が開発目標に入っていると、以下をたどるんだよ。
チューニング目的がベンチマークでいい結果を出すことになってしまう。
↓
命令の並びとかも決めうちでチューニングする。
↓
ベンチマークを早くする結果しかもたらさない。
↓
じゃあ、もうベンチマーク結果が良かったらなんでもいいじゃん。
Re: (スコア:0)
>命令の並びとかも決めうちでチューニングする。
だからこれならOKなんですよ。開発ソフトのチューニングではなく、ハード(とそのファーム)の話ですので。
同じ並びの命令があるソフトなら「固定のベンチマークソフト」以外でも、たまたま同じ並びの命令であれば恩恵が受けられる
(同じパフォーマンスがでる。 同じソフトであればプロセス名が違っても同じ結果がでる)
>じゃあ、もうベンチマーク結果が良かったらなんでもいいじゃん。
これはアウトです。ユーザーが実際の使用時にそのパフォーマンスが出ることはないので。
「ベンチマークプロセス名(ホワイトリスト)をもとにクロックアップ」なんてした場合、そのベンチマーク以外で
そのパフォーマンスが出ることはなく、同じベンチマークでもプロセス名変えただけででなくなります。
最初から「スコアを詐欺する事だけが目的」になってしまう。
ベンチマークソフト以外もホワイトリストに含まれているならグレーなんですけどね。
Re: (スコア:0)
> これはアウトです。ユーザーが実際の使用時にそのパフォーマンスが出ることはないので。
ベンチマークプロセス名がたまたま同じのに出くわしたらそのパフォーマンスがでるでしょ。
ベンチマーク結果を元に汎用的なチューニングをするんじゃなくて個別チューニングを許容するんなら、その延長上にあるクロックをあげるってのもやってしまうかもしれない。やっぱり。
Re: (スコア:0)
>ベンチマークプロセス名がたまたま同じのに出くわしたらそのパフォーマンスがでるでしょ。
でません。
そもそも
「ベンチマークプロセス名がたまたま同じの」がありえないので。
「クロックをあげるチューニング、プロセス名を元にクロックを可変にする」
これ自体は電池、やCPUアイドルを作って高負荷のプロセスになるべく回すためには許容範囲です。
ただ、「クロックをあげるホワイトリストにベンチマークプログラムしか書かれていない」
これがアウトなのです。ユーザーが使用する段階でそのパフォーマンスが出ることはないので、
詐欺だけが目的です。
なので、「ベンチマーク以外の他のプログラムがホワイトリストにない以上黒、あるならばグレー」
となります。
Re: (スコア:0)
ごめん。やっぱり
「ベンチマークプロセス名がたまたま同じ」はありえなくて、
「ベンチマークに特化した命令の並び」の最適化はありえる、
のは理解できないよ。
汎用ライブラリを作ったときに、ベンチマーク決め打ちの引数の時だけ早くなることをしたことあるが、この作業に意味は見出せなかったな。
※引数は一般的に多用される値という根拠はなく、むしろ使われないという認識だった。
Re: (スコア:0)
>ベンチマークに特化した命令の並び
これ自体はあくまでも、「命令の並び」に過ぎないでしょ。
普通のゲームでも、アプリでも、同じような処理があれば同じ命令文が並ぶ。
結果、通常使用でもベンチマークと同じパフォーマンスが出ます。
プロセス名、アプリ関係なく同じパフォーマンスが出ます。
極端な話、 1+1の単純計算を1000回やるとして、これが「命令特化」にふくまれている場合、
ベンチマークに含まれていても、表計算ソフトに含まれていてもかかる時間は同じ。
「プロセス名でクロック制御」の場合は結果が変わる。つまりパフォーマンスが変わる。
プロセス名はアプリ固有なので、「プロセス名ホワイトリストでクロックを変える処理」なんてサムソンみたいな事をやった場合、
「ホワイトリストにベンチマークしか含まれていない以上、実際にそのパフォーマンスが出ることはありません。」
なのでアウト。 ベンチマーク以外もホワイトリストにあるならユーザーはソフトによってはきちんとそのパフォーマンスが出るのでグレー
それだけの話。