Здравствуйте, Andir, Вы писали:
A>P.S. И ещё вопросик: а как в GHC заставить выдавать осмысленный стек вызовов, а не просто "Prelude index out of range."?
Там нет стека в нормальном понимании этого слова. Т.е. последовательности вызванных функций ты получить не сможешь.
Re[2]: [Haskell] Основные тормоза в ленивых вычислениях
Здравствуйте, Quintanar, Вы писали:
A>>P.S. И ещё вопросик: а как в GHC заставить выдавать осмысленный стек вызовов, а не просто "Prelude index out of range."? Q>Там нет стека в нормальном понимании этого слова. Т.е. последовательности вызванных функций ты получить не сможешь.
А хотя бы место в исходнике и/или имя функции где произошла ошибка?
Andir,
A>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
A>P.S. И ещё вопросик: а как в GHC заставить выдавать осмысленный стек вызовов, а не просто "Prelude index out of range."?
Здравствуйте, Andir, Вы писали:
A>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
Ленивые вычисления медленнее неленивых. Если есть тормоза, связанные именно с ленивостью, то делай неленивые. Профайлинг поможет определить место, где это нужно. Из своего опыта могу сказать, что стоит сначала посмотреть на логику в этом месте, у меня переход к strictness помог лишь однажды и то не сильно. Большей частью проблемы были алгоритмические, причем значительно больше
Здравствуйте, Andir, Вы писали:
A>Привет RSDN!
A>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
A>P.S. И ещё вопросик: а как в GHC заставить выдавать осмысленный стек вызовов, а не просто "Prelude index out of range."?
A>С Уважением, Andir!
если скомпилить программу с профайлингом то стек вызовов при ошибке выдаётся если стоит -xc RTS опция здесь
Re[2]: [Haskell] Основные тормоза в ленивых вычислениях
От:
Аноним
Дата:
25.02.07 20:22
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Andir, Вы писали:
A>>Привет RSDN!
A>>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
A>>P.S. И ещё вопросик: а как в GHC заставить выдавать осмысленный стек вызовов, а не просто "Prelude index out of range."?
A>>С Уважением, Andir!
А>если скомпилить программу с профайлингом то стек вызовов при ошибке выдаётся если стоит -xc RTS опция А>здесь
правда не всегда получается то что хочется, можно ещё пользоваться Hat'ом но он много чего не понимает, хотя я давно уже его пробывал, может уже доделали
Re[4]: [Haskell] Основные тормоза в ленивых вычислениях
Здравствуйте, lomeo, Вы писали:
A>>А хотя бы место в исходнике и/или имя функции где произошла ошибка? L>Так это есть.
Где? Я правда всего два типа ошибок времени выполнения пока словил, аля Index out of range и Stack Overflow, но в обоих случаях кроме загадочной надписи ничего не выводится Жутко неудобно угадывать, где ошибка. Только собственно print-debugging и помогает
Здравствуйте, Andir, Вы писали:
A>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
Попробую ещё уточнить вопрос
Собственно в чём дело. Пишу программку на Хаскеле, запускаю. Вижу результат и время работы. Время работы скажем достаточно большое, и интуитивно ясно, что где-то на вычислениях проседает производительность.
Так вот прежде чем брать профайлер в руки, хотелось бы хоть как-то на глаз оценить в каких местах может происходить такое проседание производительности. То есть какие-нибудь Code Practics для предварительного выявления возможных проблем связанных с ленивостью вычислений.
Пример: Ясно что например не стоит оставлять ленивость, когда вычисления ёмкие по памяти, объединяются в список для последующей свёртки в результат. (Хотя вот написал это и меня стали обуревать сомнения, явно не хватает ещё знаний).
Здравствуйте, Andir, Вы писали:
A>Где? Я правда всего два типа ошибок времени выполнения пока словил, аля Index out of range и Stack Overflow, но в обоих случаях кроме загадочной надписи ничего не выводится Жутко неудобно угадывать, где ошибка. Только собственно print-debugging и помогает
Да, я стормозил что то. Извиняюсь за дезинформацию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: [Haskell] Основные тормоза в ленивых вычислениях
Здравствуйте, Andir, Вы писали:
A>>Собственно subj, на что в первую очередь обращать внимание при оптимизации?
Однозначно на профайлер! -auto-all -prof при компиляции, а потом +RTS -p -RTS при запуске.
A>Так вот прежде чем брать профайлер в руки, хотелось бы хоть как-то на глаз оценить в каких местах может происходить такое проседание производительности. То есть какие-нибудь Code Practics для предварительного выявления возможных проблем связанных с ленивостью вычислений.
Эти code practics нужны не для выявления (сравни с обычными языками), а для написания. Не используй конкатенацию строк в Яве, скорее всего тебе нужен StringBuffer, не используй (!!) в Haskell, скорее всего тебе нужен массив или смена (взгляда на) алгоритма.
A>Пример: Ясно что например не стоит оставлять ленивость, когда вычисления ёмкие по памяти, объединяются в список для последующей свёртки в результат. (Хотя вот написал это и меня стали обуревать сомнения, явно не хватает ещё знаний).
Зависит от. foldl с оптимизацией свернётся в хвостовую рекурсию и список над которым он работает (если он создаётся в процессе свёртки) не будет создаваться реально, потому что к тому времени, как нам потребуется хвост, нужды в голове уже не будет.