Компилятор D7.

в большом цикле выполнятся оператор Case

всегда выполняется за ~150сек



а если сместить чуть метки, примерно так:



то такой код (с другим диапазоном меток) начинает выполняться быстрее,
всегда ~90 сек.

Причем данный эффект наблюдатся только в консольном приложении, в оконном два примера работают одинаково.

Может есть опции компилятора для разной трансляции case?

>  Random(20,40)

я вот уже плохо помню, но разве это не RandomRange? которая немного не Random(20)

> kilkennycat ©   (24.12.16 20:01) [1]

Это условно, писалось в посте от руки

У меня только одна бредовая идея приходит на ум из этих результатов.

Что когда диапазон маленький те от 1..20 поиск нужного ключа идет перебором, а когда значения поболее от 20..40, то поиск ключа идет бинарным поиском.

Уверен, что распределение равномерное в 0-20 и в 20-40. А у тебя разное количество меток к тому же, т.е. в первом случае каждое 20 значение не попадает ни на одну метку.

> Уверен, что распределение равномерное в 0-20 и в 20-40

на 100%, я просто нумерацию начал не с 0, а с 20, а в метках код остался прежним.

> Гена ©   (24.12.16 20:10) [2]
> Это условно, писалось в посте от руки

ну круто, чё. меряешь время-то неусловно, вопрос задаешь неусловно, а что меряешь, какой код - условно.

>  а когда значения поболее от 20..40,

о возникает вопрос, как сделал от 20. если RandomRange, то это уже модуль Math

а вообще, дизасм в помощь.

> а вообще, дизасм в помощь.

Это б если я был умный а не учился на первом курсе.

Вобщем, кому интересно напишите в чем же дело.

Беру, просто перетосовую беспорядочно метки в Case т.е. не по порядку от 1..20,
а 20,5,3,17 итд и результат выполнения становиться быстрей т.е те же ~90 сек второго примера, а не ~150 как если бы метки ишли по порядку.

Получается компилятор генерирует разный код.

А и еще один прикол: догружаю case кучей пустых меток вида 100:; те варианты выбора которые несут нагрузку (как помните их 20 шт) разбрасываю среди этих вариантов и опять ~90, хотя казалось бы вариантов стало в 5 раз больше и работать должно в 5 раз медленнее, а работает наоборот быстрее.

Наверно точно в одном случая компилятор принимает решение искать метки перебором, а когда их больше - бинарным поиском

> Гена ©   (24.12.16 19:48) 


С кейсом много чюдесов.
Объяснить тебе смогут все деталях только те, кто разбирается в асме.
Я, к сожалению, не разбираюсь...

Смотря какой case, маленький джампами организован, большой через датамап, тут лучше асм листинг смотреть, у меня такого поведения не воспроизвелось

>  у меня такого поведения не воспроизвелось

Так только в консоли, в оконных "не балуется"

Экзешники архивом выложи, завтра или в пн гляну под IDA что там у тебя чудит, желательно с map файлами

> Это б если я был умный а не учился на первом курсе.

)))

вот-вот, универы нынче зло!

Ставишь точку останова (BreakPoint) , потом Ctrl+Alt+D, потом смотришь асм сам и нам показываешь.

> Гена ©   (25.12.16 00:18) [11]
>
>
> >  у меня такого поведения не воспроизвелось
>
> Так только в консоли, в оконных "не балуется"
>

Не вижу разницы для компилятора в этих случаях.
Разница может быть только в настройках конкретных проектов.

> Германн ©   (25.12.16 02:01) [14]
> Не вижу разницы для компилятора в этих случаях.
> Разница может быть только в настройках конкретных проектов.

Вот я бы небыл столь категоричен, знаешь сколько раз я уже натыкался на глюки компилятора? Вполне возможно что это один из таких вариантов.
(Хотя, D7 - блин только обратил внимание, я то на берлине проверял)

> глюки компилятора

необязательно глюки. вот компиль xc8 иногда один и тот же код какой-то функции оптимизирует по-разному, только из-за того, что где-то совершенно далеко изменился размер переменной, которая к этой функции и отношения-то прямого не имеет. Мне так вместо простейшего сдвига такую хренотень замутил, что я не сразу-то и понял, че творится. При этом всё работает, конечно. Правда, не так :)

> Rouse_ ©   (25.12.16 00:07) [10]
> Смотря какой case, маленький джампами организован, большой
> через датамап, тут лучше асм листинг смотреть, у меня такого
> поведения не воспроизвелось


Розыч, а у меня воспроизвелось. Только наоборот: у меня другие рандомы, правда (не думаю, что важно). Разница во времени процентов 20-30%. Чудеса.

> Тимохов Дима ©   (25.12.16 16:45) [17]
> Розыч, а у меня воспроизвелось. Только наоборот: у меня
> другие рандомы, правда (не думаю, что важно). Разница во
> времени процентов 20-30%. Чудеса.

Ну скинь свой вариант, у меня оба варианта кода за 5 секунд (5.7) проходят.
Я специально семерку с образа поднял и протестил именно в консоли.

> kilkennycat ©   (25.12.16 14:10) [16]
>  Мне так вместо простейшего сдвига такую хренотень замутил,
>  что я не сразу-то и понял, че творится. При этом всё работает,
>  конечно. Правда, не так :)

Это скорее всего как раз прыжок через датамап (а вот с ним могут быть чудеса - на 2005 гарантированно воспроизводился один из вариантов, пока не пофиксили).
На кодецентрале там даже большое обсуждение было.