Decrease the step size of GreedyBalancer

[garyparrot]

調低 GreedyBalancer 每次可以走的步長。

[chia7712]

調低 GreedyBalancer 每次可以走的步長。

請問一下這樣做的目的是什麼？跟搜尋品質有關嗎

[garyparrot]

請問一下這樣做的目的是什麼？跟搜尋品質有關嗎

我的直覺是

1. 一次走到 30 步太多, Greedy 的重點在走很多次，而非一次走很遠
2. 走太短有跳不出 Local Minimum 的可能，但我們的問題維度非常高，所以應該不容易困在太差的 Local Minimum。
3. 走太遠很容易走壞，拿到一個更糟糕的分數，這些嘗試最後都浪費掉。

我修改 NetworkCostTest#testCompositeOptimization() 來做一些簡單的測試。

  double testOptimization(HasClusterCost costFunction, TestCase testcase) {
    var newPlan =
        Balancer.Official.Greedy.create(
                AlgorithmConfig.builder()
                    .clusterCost(costFunction)
                    .metricSource(testcase::clusterBean)
                    .build())
            .offer(testcase.clusterInfo(), Duration.ofMillis(300));

    if(newPlan.solution().isEmpty())
      return Double.NaN;
    return newPlan.solution().get().proposalClusterCost().value();
  }

  @Test
  void testCompositeOptimization() {
    var testCase = new LargeTestCase(10, 300, 0xfeed);
    var costFunction =
        HasClusterCost.of(
            Map.of(
                ingressCost(), 1.0,
                egressCost(), 1.0));
    var summary = IntStream.range(0, 100)
        .mapToDouble(i -> testOptimization(costFunction, testCase))
        .filter(i -> !Double.isNaN(i))
        .summaryStatistics();
    System.out.println(summary.getAverage());
  }

上面的 Code 建立一個 10 節點 300 Partition 的情境。重複跑 100 次 Balancer，算分數們的平均。使用的叢集分佈都是同一個，這部分測試結果可能會有點爭議，但問題應該不大。

叢集的初始分數: 1.0757599534006974

Max Step	單次執行時間	100次之平均分數
100	100ms	0.7256766556913288
30	100ms	0.5225263370032216
5	100ms	0.39176987032353333
2	100ms	0.4290735392864061
100	300ms	0.5444628379832751
30	300ms	0.34825746994160023
5	300ms	0.24566621942566308
2	300ms	0.273110301143599

上面的簡單測試結果似乎證實了我的直覺，當 Max Step 開越大，我們分數收斂的速度就越慢這樣。

所以調低一點應該比較好。

[chia7712]

我的直覺是

你的直覺還蠻有道理的

單次執行時間

請問這個時間是指哪一段？每一步的時間？現在看起來好像執行時間的影響程度還比較大一點？

[garyparrot]

請問這個時間是指哪一段？每一步的時間？現在看起來好像執行時間的影響程度還比較大一點

Balancer#offer 傳入的 timeout。

我後來想了一下， Greedy 目前的實作有可能走到比較差的 local min, 所以第二個直覺不太能成立，想要跳脫還是要靠大步伐，但大步伐搭配 shuffle tweaker 走壞的機率很高，是有機會跳脫，但機率不高

[chia7712]

我後來想了一下， Greedy 目前的實作有可能走到比較差的 local min

如果是要討論local optimum 的話，greedy 的概念本來就是這樣，關鍵問題在於那個 local optimum 離 global optimum 有多遠？太遠的話就代表這個題目不適合用 greedy 來做。但很不幸的是global optimum 的估算也是 np-hard。

但大步伐搭配 shuffle tweaker 走壞的機率很高

應該是說 shuffle tweaker 決定了演算法可以“怎麼走”，換言之， shuffle tweaker 其實在整個 balancer 扮演了最重要的角色，如果 shuffle tweaker 每次攤開的“步伐”品質都很差的話，後面演算法怎麼算都是在”很爛的區域內“找一個比較不爛的結果

[chia7712]

LGTM