Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Курилка, Вы писали:
К>>то, что нужно будет цифры переводить туда-сюда (сначала число в строку, потом каждую цифру в числовое представление)- это понятней чем то, что цифра — это разряд в 10-чной системе? Д>Нужно еще понять, как этот разряд извлечь из двоичного числа. Я например наблюдал одного старшекурсника (ныне он уже аспирант), который до этого допереть не смог
А я про то же. Что ж теперь в строку все переводить?
К>>Мсьё любитель изысканных извращений? Д>конечно!
К>>Я понимаю, что стандартные библиотеки вещь очень необходимая, полезная и т.п., но стоит ли пытаться забивать гвозди видеомагнитофоном? Д>Шуруп вбитый молотком держится крепче, чем гвозь вкрученный отверткой
Давайте еще поговорим о контрольном выстреле в задницу!
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Iscaaro — Fold Your Hands And Pray";
Здравствуйте, Дарней, Вы писали:
Т>>А число, оно не двоичное, оно просто число. Д>"просто числа" бывают у математиков. А у нас "просто чисел" не бывает.
У нас все "просто числа", только ограниченный набор. А двоичное представление, оно роли не играет — число остается числом, хоть ты его в 9ричной запиши.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Iscaaro — Fold Your Hands And Pray";
Здравствуйте, VladD2, Вы писали:
VD>>>Хреново читал. В Интеловских статьях по оптимизации очень часто говорится о том, что нужно понимать как работает кэш и т.п. A>>Нормально я читал.
VD>Раз такое говоришь значит плохо. Вот буквально недавно публиковали интеловскую статью
. Можешь сам считать сколько там о кэше и т.п. говорится.
Да я и не спорю. Но при чем тут это? Ты мне пытаешься пропихнуть факт, что я оспорил важность знания о том, как работает кэш. Но я такого не говорил. Почитай текст предыдущих постов повнимательнее...
A>>Строка считывается в кэш полностью и при последующем доступе, если не вышли за предел строки, данные берутся из кэша. VD>Все намного сложнее.
Ну, раз уж сказал, то давай поподробнее тогда.
A>> Аппаратный предзагрузчик срабатывает после нескольких промахов (вроде бы двух) кэша и распознает он линейные последовательности чтения/записи (т.е. похеру в каком направлении идти из A в B, или из B в A). Единственное, что он не делает предзагрузку из другой страницы. VD>Бред какой-то. А что бывают сфтварьные "перезагрузчики кэша"? И как после первого промаха можно работать не подгрузив данные из памяти?
Не ПЕРЕ, а ПРЕД. Да, в природе встречаются и такие — prefetchtX. Речь идет о спекулятивном предзагрузчике, а не о загрузчике.
Бред, бред... Иди почитай на досуге. Это вам не си на полтона выше.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Iscaaro — Fold Your Hands And Pray";
Здравствуйте, Gaperton, Вы писали:
GZ>>Кто делал подобные исследования? G>Carnegie-Mellon SEI. В рамках работ по PSP/TSP и софтверным метрикам. Также, любая компания, которая применяет софтверные метрики, как например, CQG или Ericsson, имеют возможность регулярно убеждаться в правильности статистики Carnegie-Mellon.
Thanks. Спасибо за информацию.
GZ>>Что значит очень хорошее тестирование? G>Это означает, что каждый класс покрыт unit-тестами, и все они выполняются. И что первая стадия интеграционного тестирования прошла успешно, продукт достаточно стабилен, чтобы отдать его на бета-тестирование.
бета-тестирование — это тоже тестирование. Под термином "хорошее тестирование" я понял предрелизный вариант. Потому и спросил.
GZ>>С уважением, Gleb. GZ>>PS: в цифры "после очень хорошего тестирования, с плотным покрытием юнит тестами" не верю G>Можешь проверить сам по своим проектам.
На некоторых проектах, у меня покрытие юнит тестами доведено до маразма. В них должно быть и меньше. Но интересно будет начать вести статистику и проверять.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Gaperton, Вы писали:
G>>По данным исследований, наиболее стабильные метрики построены на строках кода.
Д>Например, вот эти? :lol: Д>http://www.sei.cmu.edu/pacc/icse98/papers/p2.html Д>
Д>Traditional metrics, such as Lines of Code (LOC), is no longer valid or useful. Metrics based on interfaces, member functions and their complexity should be used.
G>>Ерунда. Так обычно говорят люди, которые вообще не меряют код ни строками, ни чем другим. Признайся, ты хоть раз считал плотность дефектов для своих проектов?
Д>И правда — не считал. Масштабы фирмы не те, к сожалению.
В принципе, ты можешь посчитать. В целом, для этого тебе нужна только база данных по дефектам. А строки кода уж как-нибудь можно посчитать
G>>>>Часть из ник приводят к крешу. G>>http://www.rsdn.ru/Forum/Message.aspx?mid=984393&only=1
Д>Я все-таки не понял — значит, JavaScript тоже может приводить к GPF? Правда. в твоем посте про это почему-то ничего не написано.
Нет, JavaScript не может приводить к GPF и к повреждению памяти, о чем, кстати, написано. Напоминаю тебе, что к крэшу также могут привести:
1) ошибки приведения типов
2) неинициализированные переменные (null)
3) разнообразные деления на ноль и прочие непойманные исключительные ситуации.
А вообще, читая последний вопрос, закрадывается подозрение, что ты устраиваешь мне экзамен, пытаясь подловить на ерунде . Присматриваешься, сталбыть, к моему диплому, на предмет его отобрать. Так вот — только через мой труп .
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Gaperton, Вы писали:
G>>По данным исследований, наиболее стабильные метрики построены на строках кода.
Д>Например, вот эти? :lol: Д>http://www.sei.cmu.edu/pacc/icse98/papers/p2.html Д>
Д>Traditional metrics, such as Lines of Code (LOC), is no longer valid or useful. Metrics based on interfaces, member functions and their complexity should be used.
Ламерство, не смотря на то, что взято с правильного сайта. Утверждения в статье не подкреплены статистикой, + статья не содержит библиографических ссылок. Да и автор ее не работает в Carnegie-Mellon. Метрики Complexity (например Cyclomatic Complexity) ведут себя неустойчиво и слабопресказуемо, что видно на примерах, кстати, я встречал один пример на этом же сайте.
Что касательно метрик, основанных на LOC — я видел много статистики посроенной на этих метриках, как индивидуальной, так и групповой, и все данные показывают строгую, близкую к 100% корелляцию между строками кода, временем разработки, и количеством дефектов. А значит, подходит в качестве основы для планирования. Мне от метрики сложности ничего больше не надо — единственная мера адекватности метрики для меня это приведенные корелляции.
Для других метрик сложности, вроде Cyclomatic Complexity, корелляция значительно хуже, она слишком слаба для того, чтобы применять их для прогнозов.
Здравствуйте, ansi, Вы писали:
A>Ну дык я его и использовал (правда в паскале он называется str). Только в нем те же самые действия производятся — div/mod 10 и добавляется 0x30. А потом я этот 0x30 вычитаю Может ты задачу не понял... Вот:
Эту задачу можно решить куда болие цинично...
private static uint numerolgy1(uint a, uint radix)
{
while (a >= radix)
a = (a / radix) + (a % radix);
return a;
}
или еще болие цинично
private static uint numerolgy2(uint a, uint radix)
{
if (a / radix >= radix)
a = numerolgy2(a, radix * radix);
a = (a / radix) + (a % radix);
if (a >= radix)
return (a / radix) + (a % radix);
else
return a;
}
... << RSDN@Home 1.1.4 beta 4 rev. 368>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ansi, Вы писали:
A>Да я и не спорю. Но при чем тут это? Ты мне пытаешься пропихнуть факт, что я оспорил важность знания о том, как работает кэш. Но я такого не говорил. Почитай текст предыдущих постов повнимательнее...
Я тебе пытаюсь объяснить, что твои знания о том, что a[i++] медленее (быстрее) чем a[i--] ничего не стоят. Чтобы действительно обосновать подобное подобное заявление нужно учитывать намго больше факторов. И в итоге ты с большей вероятностью ошибешся в своем предсказании нежели угадашь.
A>Ну, раз уж сказал, то давай поподробнее тогда.
Ну, например, ты учел то, что у P4 конвеер на дцать команд который пересбрасывается при из-за казалось бы безобидных действий? В общем, такие штуки нужно или оставлять на усмотрение оптимизирующего компилятора, или делать тесты на конкретном железе и конкретном компиляторе. А занятие предсказанием результатов лучше оставить тем кто разрабатывает эти компилятор. Они просто обязаны разобраться во всем досканально и учесть все особенности процессора.
Ну, а у себя в программах нужно заниматься несколько другой оптимизацией — оптимизацпией алгоритмической. И то если оно вообще нужно.
A>Не ПЕРЕ, а ПРЕД. Да, в природе встречаются и такие — prefetchtX. Речь идет о спекулятивном предзагрузчике, а не о загрузчике. A>Бред, бред... Иди почитай на досуге. Это вам не си на полтона выше.
Нет никакого "предзагрузчика". Это всего лишь оптимизация в процессорах. Кто же тебя пофмет что ты под "аппаратный предзагрузчиком" понимашь механизм префетчинга.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
A>>Ну дык я его и использовал (правда в паскале он называется str). Только в нем те же самые действия производятся — div/mod 10 и добавляется 0x30. А потом я этот 0x30 вычитаю Может ты задачу не понял... Вот: WH>Эту задачу можно решить куда болие цинично...
Разумеется
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Awakening — The Wind Dances";
Здравствуйте, VladD2, Вы писали:
VD>Я тебе пытаюсь объяснить, что твои знания о том, что a[i++] медленее (быстрее) чем a[i--] ничего не стоят. Чтобы действительно обосновать подобное подобное заявление нужно учитывать намго больше факторов.
Да не так уж и много. Все, что надо учтено. Остальное — как карта на руку ляжет. На данном примере это тяжело проверить из-за мизерности выгоды/убытка. Вообще, это чисто искусственный и незначительный пример. Если есть желание поспорить, то лучше уж поглумись над перемножением матриц.
VD>И в итоге ты с большей вероятностью ошибешся в своем предсказании нежели угадашь.
Не факт. С каких это пор вероятность ошибиться больше?
50% x 50%. Обосновать?
VD>Ну, например, ты учел то, что у P4 конвеер на дцать команд который пересбрасывается при из-за казалось бы безобидных действий? В общем, такие штуки нужно или оставлять на усмотрение оптимизирующего компилятора, или делать тесты на конкретном железе и конкретном компиляторе. А занятие предсказанием результатов лучше оставить тем кто разрабатывает эти компилятор. Они просто обязаны разобраться во всем досканально и учесть все особенности процессора.
Ну какие такие безобидные действия? На сколько я помню, конвейер сбрасывается из-за неправильно предсказанного jcc/jmp/call/ret. А так — реплей.
Ты уж очень идеализируешь компиляторы и их разработчиков. То, что они что-то обязаны не значит, что они могут это сделать, или сделали. Я вот записал тот цикл двумя способами и получил два разных ассемблерных кода. Что по этому поводу скажет компилятор? Он обязан откомпилировать конкретную программу, а подгонки под тот же кэш уже будешь сам делать. Компилятор ту не особый советчик.
VD>Ну, а у себя в программах нужно заниматься несколько другой оптимизацией — оптимизацпией алгоритмической. И то если оно вообще нужно.
Это первое, что надо. Мне так кажется, что вы просто привыкли "думать о высоком". О делегатах там, синглтонах, фабриках и т.п. А на землю спуститься никак?
VD>Нет никакого "предзагрузчика". Это всего лишь оптимизация в процессорах. Кто же тебя пофмет что ты под "аппаратный предзагрузчиком" понимашь механизм префетчинга.
Есть предзагрузчик. Кэш тоже оптимизация. Я говорю по-русски. Если ты отвык от родного языка, то посмотри перевод слова prefetch.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Celtic Awakening — Breton Children's Song";
Здравствуйте, ansi, Вы писали:
A>Да я и не спорю. Но при чем тут это? Ты мне пытаешься пропихнуть факт, что я оспорил важность знания о том, как работает кэш. Но я такого не говорил. Почитай текст предыдущих постов повнимательнее...
тебе просто пытаются объяснить, что ты гоняешься за мышами, в то время как слоны топочут вокруг тебя своими ногами
Здравствуйте, Gaperton, Вы писали:
G>В принципе, ты можешь посчитать. В целом, для этого тебе нужна только база данных по дефектам. А строки кода уж как-нибудь можно посчитать
ты уж дай тогда точные ссылки. А то мало ли какое еще ламерство там у них завалялось
G>Нет, JavaScript не может приводить к GPF и к повреждению памяти, о чем, кстати, написано. Напоминаю тебе, что к крэшу также могут привести: G>1) ошибки приведения типов G>2) неинициализированные переменные (null) G>3) разнообразные деления на ноль и прочие непойманные исключительные ситуации.
Такие ошибки могут убить один сеанс пользователя, но не весь сервер. И это есть очень, очень большая разница.
G>А вообще, читая последний вопрос, закрадывается подозрение, что ты устраиваешь мне экзамен, пытаясь подловить на ерунде . Присматриваешься, сталбыть, к моему диплому, на предмет его отобрать. Так вот — только через мой труп .
Да не покушаюсь я на твой диплом Мне вообще пофиг — есть он или нет. Главное, чтобы голова работала.
Здравствуйте, Gaperton, Вы писали:
G>Ламерство, не смотря на то, что взято с правильного сайта. Утверждения в статье не подкреплены статистикой, + статья не содержит библиографических ссылок. Да и автор ее не работает в Carnegie-Mellon. Метрики Complexity (например Cyclomatic Complexity) ведут себя неустойчиво и слабопресказуемо, что видно на примерах, кстати, я встречал один пример на этом же сайте.
G>Что касательно метрик, основанных на LOC — я видел много статистики посроенной на этих метриках, как индивидуальной, так и групповой, и все данные показывают строгую, близкую к 100% корелляцию между строками кода, временем разработки, и количеством дефектов. А значит, подходит в качестве основы для планирования. Мне от метрики сложности ничего больше не надо — единственная мера адекватности метрики для меня это приведенные корелляции.
Мне вот одно интересно. А какое-то ранжирование дефектов по степени серьезности там используется при расчетах?
Здравствуйте, Дарней, Вы писали:
A>>Да я и не спорю. Но при чем тут это? Ты мне пытаешься пропихнуть факт, что я оспорил важность знания о том, как работает кэш. Но я такого не говорил. Почитай текст предыдущих постов повнимательнее... Д>тебе просто пытаются объяснить, что ты гоняешься за мышами, в то время как слоны топочут вокруг тебя своими ногами
Да я и не гоняюсь. Я просто привел пример и сказал сразу, что толку от этого нет сейчас. Раньше был. А как реальный пример я привел перемножение матриц.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Mohicans — A New Day";
Здравствуйте, Дарней, Вы писали:
A>>Мне почему-то не сильно сэкономило. Д>а у тебя есть возможность сравнивать оба варианта?
Есть, но не было. Тут в общем-то и не сравнишь толком, слишком уж пример маленький Хотя чего сравнивать? С делением все-равно лучше.
A>>Здесь нет задачи перевода число <-> строка. Есть задача просуммировать цифры числа. Д>Выливаем из чайника воду и сводим задачу к предыдущей
Ну да
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Mohicans — A New Day";
классно было бы если б мона было самому выбирать что изучать в ВУЗ'е...
а насчёт пригретости MS — при нашем качестве образования ничо из этого не выйдет...
просто у нас был курс Visual C++....писали простенькие лабораторки...тока после того как все сдали у 80 % осталась неприязнь к С++ (а всё по вине неграмотного и нетактичного препода + отсутствия у нас хоть каких-нить знаний по этой теме)....Так что преподавание ещё может иметь и обратный эффект.....
А ваще отстутсвие достойной конкуренции MS мя пугает...это могит привести к застою и/или беспределу....
В конце концов не всем же под .NET прогать....
Здравствуйте, FirstStep, Вы писали:
FS>Я ваще за самоопределение что кому изучать. FS>классно было бы если б мона было самому выбирать что изучать в ВУЗ'е...
Кстати, давно об этом думал. Есть у нас специализации "системное программирование" и "матмоделирование". Так мне и оттуда курсы интересны и оттуда... Проучился 3-й курс на системщика, а на 4-м перешел на модельера... Мечешься, блин, туда-сюда... Вот дали бы возможность как в штатах выбирать себе спецкурсы
FS>просто у нас был курс Visual C++....писали простенькие лабораторки...тока после того как все сдали у 80 % осталась неприязнь к С++ (а всё по вине неграмотного и нетактичного препода + отсутствия у нас хоть каких-нить знаний по этой теме)....Так что преподавание ещё может иметь и обратный эффект.....
Согласен.
FS>А ваще отстутсвие достойной конкуренции MS мя пугает...это могит привести к застою и/или беспределу.... FS>В конце концов не всем же под .NET прогать....
Я вообще на простом си пишу
