LINUX.ORG.RU

Производительность C++

 ,


7

13

Как насчёт производительности у C++ по сравнению с C? Мои предположения на текущий момент:

1) Код, не использующий возможности C++ (то есть по сути plain C), скомпилированный C++ компилятором будет иметь абсолютно ту же производительность, что и код на С.

2) Исключения и dynamic_cast медленные. Если нам важна производительность, лучше их не использовать.

3) Класс без виртуальных методов, должен быть по производительности эквивалентен сишной структуре и функциям, обрабатывающим её. Не считая копирования. Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).

4) Класс с виртуальными методами полностью аналогичен пункту 3, но при вызове виртуальных методов добавляется небольшой оверхед. Сишный эквивалент obj->vtable->func(obj, ...). Если сравнивать с plain C кодом, реализующим ООП в той же манере (каждая структура-объект имеет поле, указывающее на структуру, содержащую адреса функций работы с ней), то оверхеда по сравнению с plain C не должно быть.

5) При использовании атрибута класса final (если компилятор поддерживает соответствующий стандарт) даже при наличии виртуальных методов в нём, их вызов будет превращаться в прямые вызовы функций вместо обращения к vtable, если переменная имеет соответствующий тип, а не указатель/ссылка на его предка (который не final).

6) Шаблоны могут привести к разбуханию кода. Впрочем, #define-ы и inline-функции в C++ могут устроить то же самое. Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз. А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах? Будет ли реализация расшариваться между ними или у каждого своя?

7) Что насчёт inline-методов класса? (те, которые описываются прямо в момент определения самого класса, внутри блока class). Может ли их реализация расшариваться между модулями или в каждом будет своя копия (допустим, метод слишком длинный, чтобы инлайнится в момент вызова)?

Я не претендую на правоту, какие-то утверждения могут быть ложными. Хотел бы узнать, как обстоят дела на самом деле. А также какие подводные камни я ещё не знаю. Разумеется, речь идёт о последних версиях gcc/clang с включённой оптимизацией не ниже -O2.

★★★★★

Последнее исправление: KivApple (всего исправлений: 1)

Pascal юзайте и будет вам счастье.

anonymous
()

язабан

забаньте уже AnonCxx по ай-пи. данное существо не умеет в обсуждение. но пытается походить на царя.

anonymous
()
Ответ на: язабан от anonymous

забаньте уже AnonCxx по ай-пи. данное существо не умеет в обсуждение. но пытается походить на царя.

Уважаемый eao197 успокойтесь пожалуйста. Всеравно AnonCxx умнее вас.

anonymous
()

«C++ - довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется - это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве что только среди прыщавых сосок»

Классика.

anonymous
()
Ответ на: комментарий от anonymous

Классика.

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

anonymous
()
Ответ на: комментарий от anonymous

На самом деле брехня убогая. С++ действительно набор убогих кастылей поверх си, но дело не в этом.

Когда на крестах преодолевают трудности, которые создаёт «инстрмент» - решают те задачи для которых альтернативы нет. Бахать дерьмо не заморачиваясь можно точно так же как на жабке, пхп и прочих куллязычках.

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

В чём заключается подлог я уже описал - берётся топор и супер навороченный лазерный чпу-топор и сравнивается. Естественно топор создаёт меньше трудностей и можно сосредоточится на задаче - махать кайлом, а вот с чпу-топором в 95% случаев работа заключается в борьбе с «инструментом». Т.е. сравниваются не эквивалентные по возможностям вещи, что смысла не имеет.

AnonCxx
()
Ответ на: комментарий от AnonCxx

На самом деле брехня убогая.

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

Когда на крестах преодолевают трудности, которые создаёт «инстрмент» - решают те задачи для которых альтернативы нет.

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

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

Основной сутью той дискуссии было не обгадить цепепе, а призвать читающих постоянно чему-то учиться, не скатываясь в «быдло».

В чём заключается подлог я уже описал - берётся топор и супер навороченный лазерный чпу-топор и сравнивается.

Так а там в противовес цепепе ставился Лисп, как метаязык :-) В нём-то можно строчки в компайл-тайме делать без потуг и костылей :-) Хотя, как факт, залить в чпу-топор управляющую логику на Лиспе нельзя, ибо жирный :-) И всему голова оказывается Си :-)

anonymous
()
Ответ на: комментарий от anonymous

То утверждение было адресовано тем, кто зачем-то соизволил говорить о какой-то элитарности цепепе-программистов

Извините-с, что вторгаюсь в ваш диспут. Просто в это предложение вкралась досаднейшая ошибка. Я как академик, вынужден решительно заявить, что научная элита пишет на Обероне и Паскале.

Молодые люди, я бы вам посоветовал, так сказать, изучить труды почтеннейшего профессора компьютерных наук Никлауса Вирта.

anonymous
()
Ответ на: комментарий от anonymous

В Обероне индексация с нуля? Закапывайте, скатился Вирт.

anonymous
()
Ответ на: комментарий от tailgunner

Приозерск - это метка, которую узнают те, кому надо. Тебе не надо.

Это не тот, который на Балхаше?

//Психиатр

anonymous
()
Ответ на: комментарий от tailgunner

Да, но не особо долгое. Ребенком учился в 91-93 в Советах и Полтяке. В самый драматичный период полигона. А так я с Балхаша-9.

//Психиатр.

anonymous
()
Ответ на: комментарий от anonymous

Уважаемый eao197 успокойтесь пожалуйста.

Не судите по себе: я и спокоен, и комментариев из-под анонимусов не пишу.

Всеравно AnonCxx умнее вас.

Да запросто. Может он гений и умнее нас двоих вместе взятых. Что не отменяет факта, что он больной.

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Что и требовалось доказать.

anonymous
()
Ответ на: комментарий от tailgunner

Мы имели отношение к 8-й площадке, где Эльбрус тогда стоял. До сих пор где-то книжка по Эль-76 лежит.

//Психиатр

anonymous
()

Скажу что-нибудь по теме тогда уж.

Эквивалентный код на С будет в среднем немного быстрее С++, скомпилированного с поддержкой исключений, так как последние не совсем бесплатны в обоих случаях — меньше возможностей по оптимизации. Намерить это преимущество получится далеко не всегда, такое оно ускользающее.

Основное преимущество С++ перед С лежит в поддержке обобщенного программирования. Если более-менее юзабельную объектную модель еще можно построить над С, то поддержку обобщенного программирования — уже нет. В лучшем случае (а-ля ранняя Java) оно будет медленное, без инлайнинга-то. В худшем же случае будет написан свой препроцессор.

Это я не знаю, чем надо заниматься (какие там практические задачи), чтобы сейчас отстаивать тезис «С++ не нужен, есть С». В ядре нет обработки разнотипных данных, там развитое обобщенное программирование особо без надобности. В Эмаксе для этого есть Лисп. Поэтому соответствующие товарищи искренне не понимают, зачем нужен С++. Потому, что бытие определяет сознание.

Ну хорошо, ядра, встраиваемые системы. Все что-ли ядра тут на С пишут? Нет, все допиливают унаследованный прикладной софт. На технологиях 40-летней давности. Бгг.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Примеры можно, когда джава на бэкенде выходит дороже крестов?

При чем здесь бэкэнд?

Всё, что требует больших куч, в Java приходится выносить в off-heap. Например, базы данных хранят данные в DirectByteBuffer. Сериализация там довольно быстрая, но в случае С++ её бы не было вообще, там есть обобщенный value object. Машинное обучение сюда же.

На Java это пишут просто потому, что в С++ не умеют. В общем и целом, на больших кучах сборщик мусора делает выполнение программы столь непредсказуемым, что все заморочки С++ начинают казаться детским садом. Одно только детерминированное управление ресурсами может драматически уменьшить сложность программы на С++ по сравнению с эквивалентной программой на Java. Java сильна динамическим метапрограммированием, а вот поднимание тяжестей ей не особо дается. Тянет, но не чемпион. Тут чемпион — С++.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Это я не знаю, чем надо заниматься (какие там практические задачи), чтобы сейчас отстаивать тезис «С++ не нужен, есть С».

Ленивый уёбок пофилософствуй тут мне. Структурный метод написания программ — это есть отшлифованная и законченная парадигма. Эй не нужен ООП.

anonymous
()
Ответ на: комментарий от anonymous

Структурный метод написания программ — это есть отшлифованная и законченная парадигма.

Совершенно верно. Только не идеальная. Есть более эффективные парадигмы, но они же и более сложные, что закономерно — в общем случае не бывает простых описаний сложных проблем.

Я же говорю. Бытие определяет сознание. Для твоих задач вполне хватает структурного метода, а С++ — как чемодан без ручки. Это нормально. Пойми это и не мешай людям работать.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Все это так, но мой комментарий был про другое. Сейчас у многих разработчиков есть представление, что софт — это либо ядра и embedded, либо десктоп, либо Web с делением на фронт- и бэк-энд. Представление это неправильное, не упирается все на свете в разработку бэк-энда для Web-а. Ну и, собственно говоря, то, чем я занимаюсь, оно не про Web.

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Ну что, респект тебе, значит. Уже просто попавший туда и поработавший там человек далеко не ординарен. Особенно на 8-ке. Я про то, чем именно полигон занимался, узнал много позже. И какие люди со мною за руку здоровались в местной качалке))

anonymous
()
Ответ на: комментарий от anonymous

Можно полюбопытствовать, что понимается под динамическим метапрограммированием? Беглый гуглёж ничего не дал.

SeTSeR
()
Ответ на: комментарий от eao197

Все это так, но мой комментарий был про другое.

Я понимаю. Мой ответ получился немного не в контексте обсуждения. Java лишь на начальных этапах заметно дешевле С++. В устоявшемся режиме (когда неопределенное поведение перестало выходить из под контроля, подобраны библиотеки и налажены все сопутствующие разработке процессы) я бы эти языки рассматривал как примерно одинаковые. Два главных плюса С++ (RAII и GP) могут сделать разработку на С++ сильно дешевле там, где требуется детерминированное управление ресурсами. Java выходит сильно дешевле там, где большие и динамичные кодовые базы, и не нужен RAII.

anonymous
()
Ответ на: комментарий от SeTSeR

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

Правильнее было бы сказать run-time metaprogramming. Я соглашусь с претензией в случае чего)

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Два главных плюса С++ (RAII и GP) могут сделать разработку на С++ сильно дешевле там, где требуется детерминированное управление ресурсами.

Это если брать технологические аспекты. Но в разработке ПО, зачастую, гораздо большее значение имеют около технологические аспекты: наличие библиотек; уровень удобства, которые предоставляют IDE, системы сборки и управления зависимостями; рынок рабочей силы и наличие специалистов, имеющих в конкретную технологию; предпочтения людей, стоящих у руля разработки и т.д.

Для каких-то задач намного проще набрать Java-разработчиков, которые с помощью IDEA, Ant и Maven будут собирать приложение из кучи готовых библиотек, делать это достаточно быстро и с более-менее нормальным уровнем качества. При этом еще будет обеспечиваться довольно высокая взаимозаменяемость разработчиков (если не говорить про ключевые роли).

Вот по этим показаниям C++ сильно проигрывает Java, C# и не только. Маленькая команда с хорошим уровнем разработчиков, наличие заточенных под предметную область библиотек — и на C++ все идет нормально. Но если не так, то можно нажить себе приключений.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Маленькая команда с хорошим уровнем разработчиков, наличие заточенных под предметную область библиотек — и на C++ все идет нормально. Но если не так, то можно нажить себе приключений.

Можно и так сказать: «команда с хорошим уровнем разработчиков, наличие заточенных под предметную область библиотек — и на Си все идет нормально.» Разработчики с «хорошим уровнем» квалификации и являются самой большой проблемой. Если эту проблему решить и собрать команду квалифицированных разработчиков (а не экспертов по паттернам банды 4-х и прочей...), то они предпочтут скорее Си.

anonymous
()
Ответ на: комментарий от anonymous

Если эту проблему решить и собрать команду квалифицированных разработчиков (а не экспертов по паттернам банды 4-х и прочей...), то они предпочтут скорее Си.

Для каких задач?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Но если не так, то можно нажить себе приключений.

Совершенно верно.

anonymous
()
Ответ на: комментарий от eao197

Для каких задач?

Точно не для обработки данных. Сеть (HTTP, MQ) еще себя неплохо чувствует с С, а вот базы данных уже страдают.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Для каких задач?

Для любых задач, где нужна числодробильная мощь, управление памятью и периферией. Для любых задач обеспечения работы в реальном времени.

Команда квалифицированных специалистов, которая хорошо знает и Си и Си++ для решения поставленной задачи никогда не возьмёт Си++ хотя бы потому, что обеспечить требуемый уровень дисциплины команды, пишущей на Си, гораздо проще, чем это можно сделать с командой, пишущей на Си++, потому что в Си++ уж очень много тёмных мест, и там, где на Си решение задач будет более-менее однообразным, на Си++ можно по-разному валять горы разных костылей. Приход новых людей в команду потребует от них укладывать в головы зачем нужны такие костыли, а зачем - вот такие костыли, а здесь можно это, а здесь нужно это, а тут это нельзя. Короче говоря, при всей топорности, кажущейся громоздкости, сложности Си - гораздо более прямой язык, инструмент, который можно эффективно использовать в команде. И кстати, чем больше проект, тем лучше для него подойдёт именно Си. Появятся свои приёмы, свои правила, своя философия, которые при относительной простоте языка будут понятны всей команде.

anonymous
()
Ответ на: комментарий от anonymous

базы данных уже страдают.

Так страдают, что бурно развиваются, особенно в последние 2-3 года. Посмотри в список рассылки того же Postgres. Там небывалый подъём, много чего делается прямо сейчас, пока мы бабаболим. На Си делается. А страдают больше от использования Си++.

anonymous
()
Ответ на: комментарий от anonymous

Команда квалифицированных специалистов, которая хорошо знает и Си и Си++ для решения поставленной задачи никогда не возьмёт Си++

Всяких Chrome, V8 и прочих GCC с LLVM не существует O_o

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Команда квалифицированных специалистов, которая хорошо знает и Си и Си++ для решения поставленной задачи никогда не возьмёт Си++

Надо же, а мужики из GCC взяли и переехали с С на С++, во дураки.

anonymous
()
Ответ на: комментарий от tailgunner

Всяких Chrome

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

V8

Такая же песня, только во имя промоутинга JavaScript. При этом, сейчас делается WebAssembly.

и прочих GCC

Там от Си++ гулькин нос.

с LLVM не существует

Ну и что он в сравнении с GCC?

anonymous
()
Ответ на: комментарий от anonymous

Сеть (HTTP, MQ) еще себя неплохо чувствует с С, а вот базы данных уже страдают.

Смотря какой MQ и какой уровень MQ. Если работа с сетью внутри MQ еще нормально себя чувствует, то вот то что выше, подписки, распределение сообщений по ним... Вот там в код на C просто страшно заглядывать.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Посмотри в список рассылки того же Postgres. Там небывалый подъём, много чего делается прямо сейчас, пока мы бабаболим. На Си делается. А страдают больше от использования Си++.

Находи первый загугленный рейтинг:

http://db-engines.com/en/ranking

1.	1.	1.	Oracle	Relational DBMS	1449.25	-12.78	-17.11
2.	2.	2.	MySQL 	Relational DBMS	1370.13	-1.69	+91.78
3.	3.	3.	Microsoft SQL Server	Relational DBMS	1165.81	+22.99	+47.76
4.	4.	5.	MongoDB 	Document store	314.62	-5.60	+35.57
5.	5.	4.	PostgreSQL	Relational DBMS	306.60	-1.01	+25.70
6.	6.	6.	DB2	Relational DBMS	188.57	+2.61	-10.12
7.	7.	8.	Cassandra 	Wide column store	131.12	-3.38	+22.21
8.	8.	7.	Microsoft Access	Relational DBMS	126.22	-5.35	-20.27
9.	10.	9.	SQLite	Relational DBMS	106.78	-0.48	-1.19
10.	9.	10.	Redis 

Oracle - использует С++, MySQL - использует С++, Microsoft SQL Server - С++, MongoDB - С++. И только потом Postgre. Сдается мне ты хочешь выдать частный случае за общую картину ;)

anonymous
()
Ответ на: комментарий от anonymous

Там от Си++ гулькин нос.

Нет, там С++ во все поля. Правда они почему-то расширение файлов не поменяли, но внутри уже код, который на С уже ну никак не соберется.

anonymous
()
Ответ на: комментарий от anonymous

Oracle - использует С++
Microsoft SQL Server - С++

Мне вот интересно, ты сотрудник этих корпораций? Или тебя никогда туда не возьмут, потому что ты не сможешь писать для них на Си++?

MySQL - использует С++, , MongoDB - С++.

Что они в сравнении с Postgres?

Сдается мне ты хочешь выдать частный случае за общую картину ;)

:-)

anonymous
()
Ответ на: комментарий от anonymous

Нет, там С++ во все поля. Правда они почему-то расширение файлов не поменяли, но внутри уже код, который на С уже ну никак не соберется.

В какие ещё поля? Там примитивный C++03, который используется очень-очень сдержанно.

anonymous
()
Ответ на: комментарий от anonymous

Мне вот интересно, ты сотрудник этих корпораций? Или тебя никогда туда не возьмут, потому что ты не сможешь писать для них на Си++?

Отвечу на твое любопытство - я и сейчас имею отношение к разработке одной из СУБД за С++, причем за деньги, а не в виде хобби.

MySQL - использует С++, , MongoDB - С++.

Что они в сравнении с Postgres?

Они - рабочие проекты и решения по всему миру.

anonymous
()
Ответ на: комментарий от anonymous

Для любых задач, где нужна числодробильная мощь, управление памятью и периферией. Для любых задач обеспечения работы в реальном времени.

Ну тогда я позволю себе отредактировать ваше утверждение:

Если эту проблему решить и собрать команду квалифицированных разработчиков (а не экспертов по паттернам банды 4-х и прочей...) троллей, красноглазиков и ниасиляторов, то они предпочтут скорее Си.

Ну а по поводу вашей пространной сентенции, вы, видимо, излили какую-то свою персональную боль. И речь идет не столько о технической стороне, сколько об организационном бардаке. Который приводит проекты к коллапсу как на C, так и на C++, так и на Java, так и на Ruby, так и на JavaScript и список этот можно продолжать.

Уж не знаю, какой у вас опыт, а вот то, что доводилось видеть и делать мне, от использования C только проигрывало. Ибо там, где в C++ проблемы решаются с помощью RAII и типобезопасности за счет шаблонов (не говоря уже про исключения, которые, не везде можно использовать), в C пишут простыни тривиального кода с кучей мелких ошибок, да еще и усугубляют ситуацию копипастой и макросами.

Исключения разве что составляет совсем уж низкоуровневый код типа драйверов устройств.

Ну, а если вы готовы подтвердить свою точку зрения, то покажите пример-два кода, который на C лучше (по какому-нибудь набору параметров), чем на C++.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

В какие ещё поля?
Там примитивный C++03

Окай.

Который используется очень-очень сдержанно.

Он используется достаточно, чтоб однозначно считать, что это не код на С.

anonymous
()
Ответ на: комментарий от anonymous

Отвечу на твое любопытство - я и сейчас имею отношение к разработке одной из СУБД за С++, причем за деньги, а не в виде хобби.

А к этому проекту имеет отношение Стоунбрейкер? :-)

Они - рабочие проекты и решения по всему миру.

Которые уступают Postgres.

anonymous
()
Ответ на: комментарий от anonymous

Так страдают, что бурно развиваются, особенно в последние 2-3 года. Посмотри в список рассылки того же Postgres.

Только Постгрес. Который всё никак не может выбраться из аутсайдеров. Из того, что имеет какой-то шанс называться базой данных (а не хранилищем), всё делается на С++. Или на Java/С#, что странно, но факт.

В базах данных, которые современные, а не архаика для вращающихся дисков a-la PostgreSQL, очень важно обобщенное программирование. Язык Си тут можно впихнуть, но собственных костылей абстракций команда наделает эпических, и будет их потом тянуть как чемодан без ручки. Вручную. Как когда-то бурлаки на Волге.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Посмотри в список рассылки того же Postgres. Там небывалый подъём, много чего делается прямо сейчас, пока мы бабаболим. На Си делается.

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

Ну а из совсем недавнего: https://clickhouse.yandex/ В компании, которая не может пожаловаться на недостаток квалифицированных кадров, сделала свою специализированную СУБД на C++.

И, сдается мне, один из местных анонимов имеет к ней отношение :)

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Это софт, который можно ваять как попало

Царь, залогинься.

LLVM не существует

Ну и что он в сравнении с GCC?

Ты не поймешь.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Который всё никак не может выбраться из аутсайдеров.

Давай пруфы, подтверждающие аутсайдинг Postgres.

Из того, что имеет какой-то шанс называться базой данных (а не хранилищем), всё делается на С++.

Ты про MySQL, который на C++? Или просто не знаешь, какую целостность данных Postgres обеспечивает?

В базах данных, которые современные, а не архаика для вращающихся дисков a-la PostgreSQL

Огласи-ка список, если не трудно.

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

В этом Си виноват будет? Чем спасёт от «эпических абстракций» Си++?

anonymous
()
Ответ на: комментарий от eao197

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

Какая разница из какой древности растут ноги, если проект успешно развивается командой грамотных сишников?

Ну а из совсем недавнего: https://clickhouse.yandex/ В компании, которая не может пожаловаться на недостаток квалифицированных кадров, сделала свою специализированную СУБД на C++.

Ну вот когда эта СУБД обслужит столько же, сколько обслужил Postgres, тогда и будем посмотреть.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.