Acceler8 2011並列プログラミングコンテストに参加しましたか？ 次に、この投稿はあなたについてです。
現在のAccelerate 2012コンテストに参加していますか？ 次に、この投稿はあなたのためです。
スポーツプログラミング競技に参加しましたか、または参加する予定ですか？ または、最初の独立プロジェクトを開始する予定ですか？ それでは、スターリッツ、私たちと一緒にいてください。
この投稿は、ju審員の1人によって行われた昨年のIntelコンテスト-Acceler8 2011の「報告会」です。 彼は重要な競争ポイントについてコメントし、そのようなコンテストへの参加やプロジェクト管理について、平凡で明白な、しかし関連するアドバイスも与えました。
だから 行こう！
主催者が最初に直面したのは、参加者の誠実な関心、ブログやフォーラムでのライブコミュニケーションでした。 率直に言って、フォーラムで多くの「継承」を行った参加者の決定を、特に偏りをもって検討しました。 審査員の各メンバーにはお気に入りがありましたが、テストマシンには好みがなかったため、これは競技の最終結果には影響しませんでした。
競争の挑戦
ああ、コンテストのオーガナイザーがこの仕事について聞いたことのない卑劣な言葉。 試行錯誤によって、多かれ少なかれ受け入れられる形になりました。 しかし、最初の決定を受け取った後、私たちは彼女がさまざまな最適化にどれほど豊かであるかを認識しました。 参加者（予想）の主な重点は、「周期的な」行列と並列化の計算にありました。 しかし、一部の競技者は、アルゴリズムの理論的研究も行い、メモリの割り当てを最適化し、行列を保存し、それらを埋め、それらをバイパスする方法を講じました。 審査員の目には、問題を解決するためのこのアプローチは、参加者のカルマに少なくとも+100を追加しました。
ヒント ：世界中でアプリケーションを作成する方法は多数ありますが、北西隅の方法が最も一般的です。 これは、カーソルが画面の左上隅に置かれ、コードの詰め込みが始まるときです。 これは間違った方法です。 すぐにプロジェクトの実装を開始することはせず、紙の研究から始めて、プロジェクト全体をinterfaces-functions-modulesに分割してください。 すぐに困難や微妙な瞬間に出くわすかもしれません。これにより、プロジェクトの実施前に多くの工数を節約できます。
コード品質
ここで、コンテストの主催者は、中国の民prove「ネズミを捕まえたら猫の色は関係ない」という真実を感じました。 どのような華やかな構造と式がコードに含まれていませんでした。 主催者は、同じように書いたとき、彼らの若さを思い出しました。 以下は、プロジェクトのトップ5の「厄介な」場所です。
5位 （コンストラクターでのポインターのトリッキーな初期化）：
m_memory_pointer((char*)this + 1024)
4位 （変数の初期化）：
static const int min_int = -2147483648;
3位 ：構造体をポインターと比較します。 これはLinuxでどのようにコンパイルされましたか？
2位 ：1900行のmain.cファイル。 みんな、真剣に、どうやってナビゲートしますか？
1位 （ほぼ12人の応募者）：入出力形式の非準拠。
時々、脳は単に爆発し、参加者の意味を理解しようとしました。 コメントの欠如は全体像を悪化させただけです（私は嘘をついていますが、いくつかのファイルではコメントの中でコードが失われました）。 しかし、最も印象的なことは、これらの複雑な読み取り不能な構造が、誰よりも速く動作し、正しく動作し、時々動作したことです。
このスタイルでプロジェクトを作成する場合、開発者が遭遇する問題は、コードのサポートとメンテナンスです。 時にはプロジェクトが何年も続き、プロジェクトの完了時に開発者が自分が書いたものを覚えている場合、1か月後にはうまくいかないことがあります。 私たちの意見では、コードの品質が低い主な理由は時間の不足でした。 そして、主催者が競技の期間を延長した後でも。 競争が終わる前の週末に、ほとんどすべての参加者がコンピューターに座っていたことを提案したいと思います。
ヒント ：プロジェクト全体を小さな段階に分け、毎日1つの段階を実装します。アプリケーションの一般的なインフラストラクチャ—メインアルゴリズム—テスト—メインアルゴリズムの最適化。 その美しさと読みやすさのために天国か地獄へのパスが作成されるかのようにコードを書きます。 プログラマーに履歴書を書くとき、外部リポジトリを書くのが良い習慣だということをみんなが知っていることを願っていますか？ これは、潜在的な雇用主が求職者のスキルに精通できるようにするために行われます。 現実的には、美しく読みやすいコードは、読めないコードが閉じるのと同じ速さでドアを開きます。
アルゴリズムの品質
前回の大会でお気に入りだったのはコムソモリスクDVチームでした。 そのような競技会への参加において、彼らはかなり豊富な経験を持っていると感じられます。 彼らは、アルゴリズムの理論的時間をサイクル単位で計算するほどに、アルゴリズムの研究に非常に丁寧にアプローチしました。 すべての参加者がそのような調査を実施した場合、アプリケーションを実行する必要はありません。 理論計算時間を比較するだけで十分でしょう。
また、一部の参加者は、付属文書で自分の考えの経過、どこから始めたのか、どのように考えが発展したのかを説明しました。
参加者の思考の流れをグラフの形で提示すると（うーん、そのようなグラフは可能かしら？）、ほとんどすべての参加者が基本的な改善を思いつきました。 cの成長とアイデアの複雑さにより、成功した参加者の数は急激に減少しました。
結果を含むファイナルテーブルを見ると、最初の5つの場所のパフォーマンスが他の場所と大きく異なっていることがわかります。 理由を知っていますか？ これらのチームは、他の参加者よりもわずかに重要なソリューションを考え出したからです。
ヒント ：紙の上の競争のタスクの理論的研究を行い、図や絵を描きます。 アルゴリズムの微妙な点や脆弱性を発見する可能性があります。これにより、ソリューションの速度が大幅に向上し、競争の他の参加者よりも有利になります。
結論として、コンテストの参加者は主催者に多くの楽しい時間を提供したと言いたいです。
ほとんどのアドバイス ：プログラミングを深刻なゲームとして扱います。 一方では、すべてが機能するはずです。他方では、開発プロセスが喜びをもたらすはずです。
たとえば、コメントに将来の世代のための「メッセージ」を残してみませんか？