Re: И еще раз о goto
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.04.13 11:37
Оценка:
Здравствуйте, VladD2, Вы писали:


VD> if (_bestResult == null) goto good;
VD> if (endPos > _bestResult.EndPos) goto good;
VD> if (endPos < _bestResult.EndPos) return;
VD> if (startPos < _bestResult.StartPos) goto good;
VD> if (startPos > _bestResult.StartPos) return;
VD> if (stackLevel < _bestResult.StackLevel) goto good;
VD> if (stackLevel > _bestResult.StackLevel) return;
VD> if (startState < _bestResult.StartState) goto good;
VD> return;

По сути это у тебя Компарер. Я бы сделал функцию и анализировал её значение.
и солнце б утром не вставало, когда бы не было меня
Re[2]: И еще раз о goto
От: IT Россия linq2db.com
Дата: 05.04.13 13:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>Производительность имеет значение, так что вариант на класса/лямбдах/дополнительных функциях/использующий лишние проверки не принимается (не приветствуется).
S>А это уже другой вопрос. После того, как написан понятный код, в котором сложно сделать ошибку, можно заняться оптимизацией.
S>С тем, чтобы получить ассемблерный выхлоп как можно ближе к тому, который ты привёл. Пусть этим преобразованием занимается платформа или фреймворк.

А если ни платформа, ни фреймворк этого делать не умеют, а нужно прямо сейчас?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: И еще раз о goto
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.04.13 13:45
Оценка:
Здравствуйте, IT, Вы писали:


IT>А если ни платформа, ни фреймворк этого делать не умеют, а нужно прямо сейчас?
Значит нужно Писать DSL с переводом в инлайн на OPT кодах
и солнце б утром не вставало, когда бы не было меня
Re[2]: И еще раз о goto
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.04.13 14:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я бы предложил такой вариант, который понятен.

Для начала твой вариант не верен. Вот исходный вариант, который переписывался:
def filterMax(res, func : RecoveryResult -> int) : array[RecoveryResult]
{
  if (res.Length == 0)
    res
  else
  {
    def max = res.Max(func);
    def bestResults = res.Filter(x => func(x) == max);
    bestResults.ToArray()
  }
}
def filterMin(res, func : RecoveryResult -> int) : array[RecoveryResult]
{
  if (res.Length == 0)
    res
  else
  {
    def min = res.Min(func);
    def bestResults = res.Filter(x => func(x) == min);
    bestResults.ToArray()
  }
}

def bestResults1 = filterMax(res.ToArray(), x => x.EndPos);
def bestResults2 = filterMin(bestResults1,  x => x.StartPos);
def bestResults3 = filterMin(bestResults2,  x => x.StackLevel);
def bestResults4 = filterMin(bestResults3,  x => x.StartState);
assert(bestResults4.Length == 1);


S>По факту происходит сравнение по композитному ключу, но понять это можно только путём крепкой медитации.

Я уже писал, что производительность важна. По этому варианты с замыканиями, созданием объектов и списками не катят принципиально.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: И еще раз о goto
От: fin_81  
Дата: 05.04.13 15:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:

S>>Я бы предложил такой вариант, который понятен.

VD>Для начала твой вариант не верен. Вот исходный вариант, который переписывался:
VD>

Так что там на счет правильности (эквивалентности) кода c goto?
Re[3]: И еще раз о goto
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.04.13 16:27
Оценка:
Здравствуйте, IT, Вы писали:
IT>А если ни платформа, ни фреймворк этого делать не умеют, а нужно прямо сейчас?
Я бы всё равно начал с такого кода. А потом уже профайлером смотрел, насколько там всё плохо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: И еще раз о goto
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.04.13 16:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Для начала твой вариант не верен. Вот исходный вариант, который переписывался:
прости, я немерле не умею. В чём ошибка-то?
Кстати, немерлёвый вариант тоже копец как непонятен.
VD>Я уже писал, что производительность важна. По этому варианты с замыканиями, созданием объектов и списками не катят принципиально.
Ну, тут идея-то в том, чтобы спрятать goto под капот, где ему и место. Т.е. описывать сравнение я предлагаю в терминах составного ключа, а генерировать код — как раз такой, как ты написал (с goto).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: И еще раз о goto
От: Философ Ад http://vk.com/id10256428
Дата: 05.04.13 17:12
Оценка: 2 (1) +1
Здравствуйте, fddima, Вы писали:

F>Здравствуйте, artelk, Вы писали:

A>>>или найдите компилятор который умеет инлайнить функции
A>>MethodImplOptions.AggressiveInlining
F> Спасибо, больше и человеческое!


здесь

надо только не забыть, что 4.5 ставится только на висту, а XP ещё больше трети машин
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: И еще раз о goto
От: fin_81  
Дата: 05.04.13 17:16
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Я бы предложил такой вариант, который понятен.

VD>Для начала твой вариант не верен. Вот исходный вариант, который переписывался:

Как я понимаю этот каскад фильтров ищет покрывающие-всех отрезки из множества. При этом, если окажется несколько, они должны быть одинаковы.

Вариант с goto, возможно, короче и понятнее. Но он не быстрый, так как излишне часто создает (new) эти промежуточные отрезки. Создание объекта на порядки тяжелее чем целочисленное сравнение. Почему создается отрезок (RecoveryResult), если проще и быстрее сохранить текущие целочисленные минимумы и максимумы отдельно?

В общем очень много вопросов к самой реализации алгоритма, который надо еще угадать по обфусцированному коду, оптимизацией назвать это чудо трудновато.

Сперва стоит написать что должен делать алгоритм, а после можно повоевать над реализациями этого алгоритма.

ps. Вспомнил тему из форума бд с зиг, в котором он(а) пытался(ась) напрячь остальных посетителей угадать структуру бд и оптимизировать этот запрос.
Re[5]: И еще раз о goto
От: fddima  
Дата: 05.04.13 18:18
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>надо только не забыть, что 4.5 ставится только на висту, а XP ещё больше трети машин
Это я в курсе. Просто на C# — с ручным! инлайнингом довелось наиграться, а этот ключик 4.5 фреймворка — пропустил.
Re[4]: И еще раз о goto
От: IT Россия linq2db.com
Дата: 05.04.13 19:00
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

IT>>А если ни платформа, ни фреймворк этого делать не умеют, а нужно прямо сейчас?
S>Я бы всё равно начал с такого кода. А потом уже профайлером смотрел, насколько там всё плохо.

Честно говоря, мне вообще не очень понятен масштаб трагедии, поэтому не могу сказать как бы сам поступил
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: И еще раз о goto
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.04.13 02:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>прости, я немерле не умею. В чём ошибка-то?

Немерл там особо не причем. Там проверка на минимум и на максимум. И с учетом приоритетов. Когда мы фильтруем списки последовательно, то этим достигается отслеживание приоритета. Ну, а функция фильтрации определяет какой выбор мы делаем.

S>Кстати, немерлёвый вариант тоже копец как непонятен.

А ты вчитайся. Лично я его написал за пару сикунд. Оно очевиден. А вот с реализацией на ифах я накосячил (тут этот косяк несколько раз повторили).

S>Ну, тут идея-то в том, чтобы спрятать goto под капот, где ему и место. Т.е. описывать сравнение я предлагаю в терминах составного ключа, а генерировать код — как раз такой, как ты написал (с goto).

Дык я же тебе говорю, что я за 5 минут написал вариант на списках и проверил его. Это и была оптимизация. И как это часто бывает, я в ней накосячил. Вольфхаунд поправил мою реализацию с использованием готу. Я переписал его код на ифах и понял, что получилось не сильно лучше (если не хуже). Вот и решил по обсуждать этот странный, на мой взгляд, феномен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: И еще раз о goto
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.04.13 12:23
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А ты вчитайся. Лично я его написал за пару сикунд. Оно очевиден. А вот с реализацией на ифах я накосячил (тут этот косяк несколько раз повторили).
Угу. А чего там не использовано решение уравнения Больцано-Вейерштрасса заодно? Многословное изложение, основная цель которого — запутать читателя. Я верю, что ты написал его за пару секунд. А вот читать его нужно минимум несколько минут, чтобы понять суть происходящего.

VD>Дык я же тебе говорю, что я за 5 минут написал вариант на списках и проверил его. Это и была оптимизация. И как это часто бывает, я в ней накосячил. Вольфхаунд поправил мою реализацию с использованием готу. Я переписал его код на ифах и понял, что получилось не сильно лучше (если не хуже). Вот и решил по обсуждать этот странный, на мой взгляд, феномен.
Хуже. Потому что у нас нет "тройного" if-оператора, а блок схема алгортма сравнения по композитному ключу использует по три выхода из каждого блока.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: И еще раз о goto
От: mrTwister Россия  
Дата: 07.04.13 15:58
Оценка: +1
Здравствуйте, fddima, Вы писали:

F>хотя это и будет сложно заметить в микроскоп — но это не значит, что это не важно.

Вообще-то значит.
лэт ми спик фром май харт
Re[3]: И еще раз о goto
От: vdimas Россия  
Дата: 09.04.13 11:58
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>И чем это лучше варианта с goto?

тем, что остальные безусловные операторы перехода, кроме goto, ограничены неким блоком кода.
Re[4]: И еще раз о goto
От: vdimas Россия  
Дата: 09.04.13 11:59
Оценка:
Здравствуйте, fddima, Вы писали:

F>На самом деле, тут уже мысль кто-то говорил — глупо отрицать существование goto, пока в процессоре существует jmp.

Ерунду этот кто-то говорил.
return, continue, break — это тоже операторы безусловного перехода.
Re: И еще раз о goto
От: B0FEE664  
Дата: 11.04.13 13:16
Оценка: :))
Здравствуйте, VladD2, Вы писали:

  Скрытый текст
VD>Нашелся прикльный примерчик где использование goto выглядит как минимум не хуже альтернативного варианта.

VD>Вопросов два:
VD>1. Какой вариант вам нравится больше?
VD>2. Можно предложить какой-то другой варинат который был бы лучше чем два предложенных?

VD>Производительность имеет значение, так что вариант на класса/лямбдах/дополнительных функциях/использующий лишние проверки не принимается (не приветствуется).

VD>Вариант с goto:
VD>
VD>void AddResult(int startPos, int endPos, int startState, int stackLevel, RecoveryStackFrame stackFrame, string text, int fail)
VD>{
VD>  _bestResultsCount++;

VD>  if (_bestResult == null)                 goto good;
VD>  if (endPos     > _bestResult.EndPos)     goto good;
VD>  if (endPos     < _bestResult.EndPos)     return;
VD>  if (startPos   < _bestResult.StartPos)   goto good;
VD>  if (startPos   > _bestResult.StartPos)   return;
VD>  if (stackLevel < _bestResult.StackLevel) goto good;
VD>  if (stackLevel > _bestResult.StackLevel) return;
VD>  if (startState < _bestResult.StartState) goto good;
VD>  return;
VD>good:
VD>  _bestResult = new RecoveryResult(startPos, endPos, startState, stackLevel, stackFrame, text, fail);
VD>

VD>}


VD>Вариант без goto:
VD>
VD>void AddResult(int startPos, int endPos, int startState, int stackLevel, RecoveryStackFrame stackFrame, string text, int fail)
VD>{
VD>  _bestResultsCount++;

VD>  if (this._bestResult != null)
VD>  {
VD>    if (endPos <= this._bestResult.EndPos)
VD>    {
VD>      if (endPos < this._bestResult.EndPos)
VD>        return;
VD>      if (startPos >= this._bestResult.StartPos)
VD>      {
VD>        if (startPos > this._bestResult.StartPos)
VD>          return;
VD>        if (stackLevel >= this._bestResult.StackLevel)
VD>        {
VD>          if (stackLevel > this._bestResult.StackLevel)
VD>            return;
VD>          if (startState >= this._bestResult.StartState)
VD>            return;
VD>        }
VD>      }
VD>    }
VD>  }

VD>  _bestResult = new RecoveryResult(startPos, endPos, startState, stackLevel, stackFrame, text, fail);
VD>}
VD>


А зачем столько if'ов? Вот так надо:

void AddResult(int startPos, int endPos, int startState, int stackLevel, RecoveryStackFrame stackFrame, string text, int fail)
{
  _bestResultsCount++;
    
  if (
         null   == _bestResult
       ||
         endPos >  _bestResult.EndPos
       ||
       (
         endPos == _bestResult.EndPos && (
                                             startPos <  _bestResult.StartPos
                                           ||
                                           (
                                             startPos == _bestResult.StartPos && (
                                                                                   stackLevel  <  _bestResult.StackLevel
                                                                                   ||
                                                                                   (stackLevel == _bestResult.StackLevel && startState < _bestResult.StartState)
                                                                                 )
                                           )
                                         )
       )
     )                                  
  {
    _bestResult = new RecoveryResult(startPos, endPos, startState, stackLevel, stackFrame, text, fail);
  }
}
И каждый день — без права на ошибку...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.