PLOについての興味深い見解

fxsaber 2021.01.31 12:20 #81

Igor Makanu:

これらのコードは、プロセッサレベルでタクトまで同じ速度で実行されると99％確信しています。プロセッサは、最適化、並列化、その他マイクロコマンドレベルで実行されているものを持っています。

コンパイラが最適なものにブラッシュアップしてくれる」ことを当てにして、どんな品質のコードでも書いていると、ここで弊害が発生しませんか？

ある書き方でコンパイラが正しい動作をすることは、確実に分かっているはずです。別のスタイルでは、コンパイラがより賢いと信じるしかありません。

クロスプラットフォーム、異なるコンパイラなどを考えると、私はコードで何をしているかを意識することを選びます。

Igor Makanu 2021.01.31 12:32 #82

fxsaber:

どんな質の高いコードでも「コンパイラが最適にブラッシュアップしてくれるだろう」と期待して書くと、悪影響があるのでは？

githabにあるtst1とtst2のソースを比較しましたが、どちらもプログラマによく使われているものでした。

だから、コンパイラの開発者はとっくの昔に標準的なコード構成を覚えていて、コンパイラの問題にはならないのだと思うのです。

悪影響 - 上記@TheXpertが書いているように、コードの書式については会社の要件がありますが、要件は概ね同じです - コードは他のチームメンバー、それも来たばかりのメンバーにも理解できるものでなければなりません...。

fxsaber:

ある書き方では、確実にコンパイラが正しいことをするとわかっています。他のスタイルでは、コンパイラがより賢いと信じるしかありません。

今賢くなったのはコンパイラではなく、プロセッサそのものです。イマドキ、高性能なコードを語るなら - 主な性能オーバーヘッドは関数呼び出しではなく、メモリ読み出し（メモリアクセス） - データ/変数の保存を小さな計算値で置き換えることができれば、（プロセッサのマイクロコマンド最適化のレベルで）小さな利得が得られるはずです

...しかし、それ以外は邪道である ))))

SZY：コンパイラのレベルでコードの最適化もあり、私は十分に読んでいない - 推測のレベルですべて、PCハードウェア上で私は定期的に読んで、長い時間私は読んで、私は意見を書いている

fxsaber:

クロスプラットフォーム、異なるコンパイラなどを考えると、私はコードで何をしているかを意識することを選びます。

それなら仕方がない。要するに、「私はアーティストだ、それが私の見方だ」ということです））、気を悪くされなかったでしょうか。

Valeriy Yastremskiy 2021.01.31 12:43 #83

私は、5年後のコードは、コーダーが理解できるものでなければならず、理解できないものは、悪いコードであるというルールを設けています。

そして、他の人に理解されれば、とても良いことです。

fxsaber 2021.01.31 12:59 #84

Valeriy Yastremskiy:

私は、5年後のコードは、コーダーが理解できるものでなければならず、理解できないものは、悪いコードであるというルールを設けています。

そして、他の人に理解されれば、とても良いことです。

ここ（とここ）は非常に良いコードです。しかし、私には理解できない。私の脳はずっと前に成長が止まっているんです。

Valeriy Yastremskiy 2021.01.31 13:13 #85

fxsaber:

ここ（とここ）は非常に良いコードです。しかし、私には理解できない。私の脳はずっと前に成長が止まっているんです。

トピックが複雑で、誰もが理解できるわけではありません。

Georgiy Merts 2021.01.31 14:10 #86

ああ、なんだこの話題は...。そして、私なしで...おかしいな...。声を出さなきゃ。

タイトルの記事について - 正しい前提（コードはできるだけ決定論的でなければならない）が、例として加算演算と累積演算を比較するという、非常に馬鹿げた方法で使われています。そして結論は、加算演算は決定論的であり、常に同じ結果を返すが、累積はそうではなく、結果は常に異なるということである。

しかし、失礼ながら...。これらは異なる操作であり、どちらの場合も結果は完全に正しく、それぞれ加算と累積から期待されるものと全く同じです !

乱数発生器の例も、ランダムな要素を持つ演算であることを考えれば、「非決定論的」とは呼べない。

私には、非決定的というのは、作者がコードの意図とは全く違うことをコードに期待することだと思えるのです。

そして2つ目は、コードの可読性です。「クエスチョンマーク」の操作が非常に有害で、理解しにくいと感じています。質問」を条件演算子に置き換えても、全く同じ効率で実行可能なコードが得られます。この場合、ソースコードのボリュームが目立つようになりますが、同時に非常にクリアになります。これは大きなプラス要素だと思います。

私はいつも、それらの多数の論理式をすべて分割して、中間結果を持つ一連の別々の演算にするようにしています。その結果、実行可能なコードの効率が悪くなったとしても、理解を深めることのメリットの方がはるかに重要だと私は考えています。

Maxim Kuznetsov 2021.01.31 15:02 #87

と、これこそクリスマスツリーを意識したプログラミングの本領発揮です :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }

Georgiy Merts 2021.01.31 15:30 #88

Maxim Kuznetsov:

と、これこそクリスマスツリーを意識したプログラミングの本領発揮です :-)

条件が短い表現であれば、それはそれでいいんです。機能別に分けても良いですが。

また、そのような場合の逆カッコでは、必ず開カッコのヘッダーにコメントを入れて、分かりやすくしています。

Andrey Khatimlianskii 2021.02.01 08:29 #89

fxsaber:

ある書き方では、コンパイラが正しいことをするのは確実です。別のものでは、コンパイラがより賢くなっていることを信じるだけでよいのです。

この実行に差支えはないでしょう。

if ( a() ) return(true);
if ( b() ) return(true);
return(false);

とこれです。

return( a() || b() );

読みやすく、デバッグしやすいコードには大賛成です。

Vitaly Muzichenko 2021.02.01 09:19 #90

Andrey Khatimlianskii:

これをやっても差支えはないでしょう。

とこれです。

読みやすく、デバッグしやすいコードには大賛成です。

このデザインは、読みやすさとごちゃごちゃ感という点で全く好きではありません。

if ( a() ) return(true);
if ( b() ) return(true);
return(false);

PLOについての興味深い見解 - ページ 9