Во многих случаях торможение происходит не из-за нехватки вычислительных ресурсов, а оперативной памяти. Диск ведь медленнее на порядки, чем оперативная память и тем более кеш. Мне удавалось существенно ускорять работу компьютеров дома, добавляя туда RAM до 4-8 Гб.
А память ныне уходит во многом на: а) драйвера б) стандартизованные библиотеки в) использование языков с динамическим выделением памяти г) графику
Да и имеет ли смысл при очень дешёвой оперативной памяти её экономить во всех случаях? И, кстати, постоянное использование низкоуровневых механизмов управления памятью в стиле Си - не лучший вариант с точки зрения надёжности очень больших программ.
В нынешние времена даже наш завлаб, заставший ещё 32Кб ОЗУ и Фортран-77 нередко говорит о том, что не нужно в нынешние времена заниматься излишней оптимизацией программ.
>> правильная организация Просто насколько в нынешних условиях реален перевод всего и вся на низкоуровневые языки вроде Си?
Да, програмистская среда деградировала. Об оптимизации никто не думают. И поэтому, несмотря на огромную всевозрастающую производительность и память, компы продолжают тормозить.
А что кажется языков - да, будь моя воля, я бы все писал на Си (кроме того, что требует Ассемблера).
>> А что кажется языков - да, будь моя воля, я бы все писал на Си 1) Windows, Linux и Office и так уже написаны на C/C++. И даже в этом случае программы могут разбухать за счёт универсальности, компонентного подхода, в том числе огромных библиотек. 2) А что ты думаешь насчёт характерных для этого языка переполнений буфера и выхода за границы массивов? Чем больше программа, тем сложнее всё контролировать программисту.
>> Об оптимизации никто не думают. В науке это не так: хотя во многих ситуациях о ней действительно не думают, но в критических ситуациях могут уделять самое пристальное внимание.
Да, кстати, про си правильно говорят насчёт переполнений буфера. Был бы это вопрос только сбоев в работе, это было бы полбеды, но подобные ошибки, как правило, образуют очень серьёзную уязвимость, вплоть до возможности выполнить произвольный код на уязвимой машине. То есть там, где малограмотный ява-программист в принципе лишён возможность создать подобную уязвимость, малограмотный программист на си её сделает и даже не заметит ничего подозрительного. А ведь подобные ошибки постоянно находят и в серьёзных программах.
Нет, нельзя. Это уже будет не си. Концепция си - "portable assembler", язык высокого уровня, операции которого максимально простым и очевидным образом преобразуются в машинный код. А перепроверки системой действий программы, такие, как контроль обращений к памяти, сильно выпадают из этой концепции и заметно увеличивают как размер исполняемого кода, так и время выполнения, не говоря уже о том, что такие проверки поломают работоспособность огромной части легитимног си-кода, так как в си довольно часто принято сознательно выходить за такие рамки с целью оптимизации.
Для понимания: с точки зрения си выражения
a[b] *(a + b) b[a]
эквивалентны. То есть переменная-массив синтаксически эквивалентна указателю на начало массива. Как в этом случае делать проверку на границы массива?
Вообще говоря, есть интеллектуальные пакеты, созданные для поиска подобных ошибок. Кажется, именно таким пакетом недавно обнаружили знаменитый баг heartbleed. Но малограмотные программисты этими пакетами тоже не пользуются.
Ещё как может. Это один из самых распространённых векторов атаки. Один из его вариантов выглядит так: программа выделяет буфер в локальных переменных функции (т.е. в стеке) и заполняет его данными, полученными от пользователя, не проверяя их размер. Злоумышленник шлёт очень большой объем данных, состоящий, грубо говоря, на 10 процентов из повторений злоумышленного машинного кода, промежутки между которыми заполнены операции NOP, которая не делает ничего. Такое переполнение перезаписывает адрес возврата из функции (псевдо-)случайным значением, и существует довольно заметная вероятность, что, когда функция выполнится до конца и выполнит команду RET, вместо возвращения к вызвавшей функции управление передастся одной из копий злоумышленного кода.
А это не переполнение стека. Стек в архитектурах x86 растёт вниз, к младшим адресам, и переполнение стека - это наползание его адресов на другие участки памяти. В данном же случае переполняется одна из переменных, находящихся в стеке, и переполняется "вверх". Вот здесь рассмотрен простой вариант этой атаки:
А память ныне уходит во многом на:
а) драйвера
б) стандартизованные библиотеки
в) использование языков с динамическим выделением памяти
г) графику
Да и имеет ли смысл при очень дешёвой оперативной памяти её экономить во всех случаях? И, кстати, постоянное использование низкоуровневых механизмов управления памятью в стиле Си - не лучший вариант с точки зрения надёжности очень больших программ.
Reply
Reply
>> правильная организация
Просто насколько в нынешних условиях реален перевод всего и вся на низкоуровневые языки вроде Си?
Reply
Об оптимизации никто не думают.
И поэтому, несмотря на огромную всевозрастающую производительность и память, компы продолжают тормозить.
А что кажется языков - да, будь моя воля, я бы все писал на Си (кроме того, что требует Ассемблера).
Reply
1) Windows, Linux и Office и так уже написаны на C/C++. И даже в этом случае программы могут разбухать за счёт универсальности, компонентного подхода, в том числе огромных библиотек.
2) А что ты думаешь насчёт характерных для этого языка переполнений буфера и выхода за границы массивов? Чем больше программа, тем сложнее всё контролировать программисту.
>> Об оптимизации никто не думают.
В науке это не так: хотя во многих ситуациях о ней действительно не думают, но в критических ситуациях могут уделять самое пристальное внимание.
Reply
Reply
Reply
Для понимания: с точки зрения си выражения
a[b]
*(a + b)
b[a]
эквивалентны. То есть переменная-массив синтаксически эквивалентна указателю на начало массива. Как в этом случае делать проверку на границы массива?
Вообще говоря, есть интеллектуальные пакеты, созданные для поиска подобных ошибок. Кажется, именно таким пакетом недавно обнаружили знаменитый баг heartbleed. Но малограмотные программисты этими пакетами тоже не пользуются.
Reply
Так что вылезание за память может быть использовано вирусами и троянами?
Reply
Reply
Reply
http://www.cse.scu.edu/~tschwarz/coen152_05/Lectures/BufferOverflow.html
Reply
Leave a comment