The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Доступен язык программирования Rust 1.15, opennews (??), 04-Фев-17, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


29. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Аноним (-), 04-Фев-17, 19:49 
И что же там так тормозит-то? Вот эта проверка — https://github.com/llvm-mirror/libcxx/blob/master/include/ve... , что там быстрее сделать можно было-то?

Там тормоза начинаются только в небесплатных вещах вроде RTTI и виртуальных вызовов, которые и на си так же работать будут.

Ответить | Правка | Наверх | Cообщить модератору

31. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от Comdiv (ok), 04-Фев-17, 20:19 
> И что же там так тормозит-то? Вот эта проверка — https://github.com/llvm-mirror/libcxx/blob/master/include/ve...
> , что там быстрее сделать можно было-то?

Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык? Серьёзно? Просто сделайте простейший тест и посмотрите.

> Там тормоза начинаются только в небесплатных вещах вроде RTTI и виртуальных вызовов,
> которые и на си так же работать будут.

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


Ответить | Правка | Наверх | Cообщить модератору

35. "Доступен язык программирования Rust 1.15"  +/
Сообщение от anonymous (??), 04-Фев-17, 22:06 
> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?

Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?

Ответить | Правка | Наверх | Cообщить модератору

37. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от Comdiv (ok), 04-Фев-17, 22:21 
>> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?
> Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok), 05-Фев-17, 16:22 
"Магия" стандартной бибилиотеки, а тем более элементов языка вроде dynamic_cast отлично оптимизируется для соответствующих случаев. Может вы, конечно, пользуетесь каким-то печальным компилятором или оптимизации не включаете...

Как пример - оптимизация memmove в gcc - вполне себе библиотечные функции напрочь выносятся с заменой на оптимизированный машинный код.

Ответить | Правка | Наверх | Cообщить модератору

56. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Comdiv (ok), 05-Фев-17, 17:08 
dynamic cast не оптимизируется для тех случаев, в которых это нужно. Он либо вообще будет убран, поскольку тип заранее известен, но тогда он и не нужен, либо будет медленным, так как нужно учитывать множественное наследование. Не рассуждайте вообще, проверяйте. Я проверял, используя оптимизацию -O3 -flto https://github.com/ComdivByZero/test-ext-oop-insert-sort-eff...

> Как пример - оптимизация memmove в gcc - вполне себе библиотечные функции
> напрочь выносятся с заменой на оптимизированный машинный код.

Нет. Gcc давно трактует эту функцию как встроенную, то есть, поддерживаемую на уровне языка, а не библиотеки. Проведите эксперимент, объявите свою функцию memmove с другими параметрами, и посмотрите, что выдаст компилятор.

Ответить | Правка | Наверх | Cообщить модератору

60. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok), 05-Фев-17, 18:32 
Так и я ж о том, что трактует, как встроенную, хотф формально - это часть библиотеки. А что до наследования - компилятор знает всё дерево наследования, в том числе - было ли там множественное. Так что теоретически - никаких проблем. А на практике - dynamic_cast - это фича для крайних случаев и в общем случае не рекомендованная к применению. Соответственно, профита от его оптимизации - 0 целых 0 десятых.
Ответить | Правка | Наверх | Cообщить модератору

61. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Comdiv (ok), 05-Фев-17, 19:07 
Но приведённый метод .at() он не тракует как встроенный. Ведь речь шла именно о неэффективности С++ абстракций по сравнению с Си. Поэтому мне и странно было слышать аргумент об эффективности абстракций Си для доказательства эффективности абстракци С++, хотя я сразу написал, что С++ достигает высокой производительности, когда на нём пишут на Си-подмножестве.

> на практике - dynamic_cast это фича для крайних случаев... профита от его оптимизации - 0

Зависит от задач. Я частенько использую его аналоги в других языках(сам С++ использую мало). Если в задаче есть необходимость в хранилище _разнородных_ элементов, то dynamic_cast - это гарантия целостности памяти, из-за невозможности приведения от обобщенного типа, которым оперирует хранилище к расширенному, которым оперирует пользователь хранилища.

Ответить | Правка | Наверх | Cообщить модератору

68. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok), 06-Фев-17, 16:55 
В других языках есть свои best practices. Для плюсов оптимизация dynamic_cast не принциипальна.

Что до at() - надо посмотреть. По идее компилятор там ничего чудить не должен, рядовой же метод. Может, что-то с исключениями связанное.

Ответить | Правка | Наверх | Cообщить модератору

70. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Comdiv (ok), 06-Фев-17, 23:45 
> Для плюсов оптимизация dynamic_cast не принциипальна.

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

> Что до at() - надо посмотреть. По идее компилятор там ничего чудить
> не должен, рядовой же метод. Может, что-то с исключениями связанное.

Рядовой, но не встроенный как memcpy. Учёт специфики встроенных функций позволяет оптимизировать сильней, чем просто компилируемый метод, а сделать очень хорошую оптимизацию для общего случая сложная задача.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру