Блог пользователя MaxBuzz

Автор MaxBuzz, 13 лет назад, перевод, По-русски
Этот код зависает, если его запустить на серверной JVM:

public class OptimizerBug {<br>    private static final int ITERATIONS = 1000;<br>    private static int doNotOptimizeOut = 0;<br><br>    public static long bitCountShort() {<br>        long t0 = System.currentTimeMillis();<br>        int sum = 0;<br>        for (int it = 0; it < ITERATIONS; ++it) {<br>            short value = 0;<br>            do {<br>                sum += Integer.bitCount(value);<br>            } while (++value != 0);<br>        }<br>        doNotOptimizeOut += sum;<br>        return System.currentTimeMillis() - t0;<br>    }<br><br>    public static void main(String[] args) {<br>        for (int i = 0; i < 4; ++i) {<br>            System.out.println((i + 1) + ": " + bitCountShort());<br>        }<br>        System.out.println("doNotOptimizeOut value: " + doNotOptimizeOut);<br>    }<br>}<br>

Ниже пример результатов (на одной и той же машине, Linux Gentoo 64-bit, java 1.6.0_24):
  • [64-bit] java OptimizerBug:
1: 380
2: 373
<зависает>
  • [32-bit] java -server OptimizerBug:
1: 386
2: 365
<зависает>
  • [32-bit] java -client OptimizerBug
1: 525
2: 520
3: 518
4: 526
doNotOptimizeOut value: -100663296

Под линуксом (java 1.6.0_24), при подвисании процесс поедает оба (все доступные?) ядра процессора, и его можно убить только девяткой (kill -9).

Все то же самое верно про 64-битный Windows (java 1.6.0_23), только там процесс занимает только одно ядро и легко снимается диспетчером задач.

Получен ID бага 7020614:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7020614.

UPD: баг открыли для всеобщего обозрения (по ссылке выше), можно зайти и проголосовать.

Полный текст и комментарии »

  • Проголосовать: нравится
  • +15
  • Проголосовать: не нравится

Автор MaxBuzz, 13 лет назад, По-английски
The following code produces strange results while compiling it under GCC with different optimization levels:
  • gcc source.cpp -> 0.440 s
  • gcc -O2 source.cpp -> 2.750 s (-O, -O1, -O2 the same)
  • gcc -Os source.cpp -> 0.223 s
For N=500, it is as follows:
  • gcc source.cpp -> 3.931 s
  • gcc -Os source.cpp -> 2.704 s
  • gcc -O2 source.cpp -> 42.142 s
The setup is GCC 4.4.4 on 64-bit Gentoo Linux.

Somehow optimizations by speed significantly slow the code, while optimizations by size speed it up :-)

Could anybody compile and test the code on your machines? Or, possibly, explain why it is like this?

Полный текст и комментарии »

  • Проголосовать: нравится
  • +10
  • Проголосовать: не нравится

Автор MaxBuzz, 14 лет назад, По-русски
В связи с тем, что редактирование собственных комментариев не предусмотрено, здесь будут размещаться тестовые комментарии, предназначенные для ответственных постов, в которых предположительно будут всплывать баги парсера.

Полный текст и комментарии »

  • Проголосовать: нравится
  • +6
  • Проголосовать: не нравится