Войти
ФлеймФорумПрограммирование

Rust vs C++17 (3 стр)

Страницы: 1 2 3
#30
13:48, 14 ноя. 2018

Zefick
> А ты предлагаешь затягивать выполнение работы, потому что боишься оказаться
> ненужным после того, как она будет завершена?

Ясно же что это языки однодневки для выполнения одной задачи в одной компании.


#31
13:49, 14 ноя. 2018

gamedevfor
> Ясно же что это языки однодневки для выполнения одной задачи в одной компании.
  Может быть как-то аргументируешь свою точку зрения хотя бы?

#32
13:54, 14 ноя. 2018

youtube
> O_o. Почему там так сделано?!
Потому что это потребует указателей и аналога reinterpret_cast, которые в Go доступны только через unsafe. Видимо авторы Go так сильно не любят unsafe, что даже не используют его в стандартной библиотеке для оптимизации. С unsafe порядок байт не гарантируется, хотя в библиотеке можно было бы его проверять и использовать быстрый путь при совпадении указанного порядка байт и порядка байт платформы.

Adler
> можно собирать С++ и Rust для браузера используя emscripten/WebAssembly
Я знаю, я например свой синтезатор через Emscripten под браузер собираю.
Go тоже вроде можно под Web компилить. Но у emscripten средств для работы с DOM, а в основном клиент это и должен делать, чтобы визуализировать данные. Не через OpenGL ES же всё рисовать. Поэтому:
Zefick
> Лучше уж TypeScript.

#33
13:56, 14 ноя. 2018

Zefick
Rust - Mozilla.
Go  - Google.

#34
19:24, 14 ноя. 2018

Каца мне, будет раст топтаться где-то на уровне D ещё очень долго.

#35
20:40, 14 ноя. 2018

Ghost2
> раст топтаться где-то на уровне D ещё очень долго.
Изображение

#36
0:53, 17 ноя. 2018

gammaker
https://about.sourcegraph.com/go/gophercon-2018-5-mistakes-c-c-de… ke-writing-go

#37
22:25, 17 ноя. 2018

*Lain*
В общем-то мне всё это уже знакомо, таких ошибок не совершал.
Кстати, с escape analysis'ом пришлось пободаться. Я много раз читал хедер размером 5 байт из файла, передавая туда слайс на статический массив, а профайлер мне показал, что в этом месте каждый раз при этом аллоцировался блок памяти размером 16 байт в куче - видимо 5 в менеджере памяти округляется вверх до 16. Оказалось, что из-за того, что я передаю слайс в метод Read интерфейса io.Reader, компилятор не знает, что внутри, и предполагает худшее - что метод может сохранять ссылку на слайс где-то у себя, что по всей логике чтение из файла делать никак не должно. Я долго думал, как это обойти, но потом придумал. Я просто сделал этот массив из 5 байт приватным полем объекта и передавал слайс на них. Объект создавался единственный раз и и так был уже в куче, поэтому таким образом я избавился от аллокаций. Проделал это в нескольких местах, а также заменил тормозной binary.Write / binary.Read на их unsafe аналог с кастом слайса интов к слайсу байт и таким образом уменьшил число аллокаций в тесте с 27000 до 100 - в 270 раз! И размер аллоцированной памяти также уменьшился в сотни раз.
Правда производительность по замерам времени выросла всего на 10%, зато, я думаю, программа будет работать стабильнее после того, как я уменьшил нагрузку на сборщик мусора. Собрал из под винды под Linux ARM и запустил на целевом железе - очень дешёвом и с дохлым процессором 800 MHz с одним ядром. Даже на пиковых нагрузках, которые я пытался симулировать, всё работает идеально.
Go рулит, я доволен, кто бы что про него ни говорил. Я думаю, на шарпе и C/C++ у меня ушло бы в разы больше времени, а первый я бы ещё и замучался разворачивать на устройстве, под которое нет даже дистрибутивов Linux'а с менеджером пакетов или хотя бы компилятором. А Go бинарник работает не только под линуксом, но и даже в Android: если в папку /data/ его закинуть, можно запустить из консоли и будет работать!

#38
3:20, 18 ноя. 2018

gammaker
> а профайлер мне показал, что в этом месте каждый раз при этом аллоцировался
> блок памяти размером 16 байт в куче - видимо 5 в менеджере памяти округляется
> вверх до 16
Может быть округляется до кратного 4-м? Чтобы все участки памяти были выровнены. Итого 8 байт, а оставшиеся 8 байт - это служебная информация по отрицательному смещению.

#39
14:01, 18 ноя. 2018

MrShoor, 16 - типичное выравнивание при оптимизации на скорость

#40
14:55, 18 ноя. 2018

clc
> 16 - типичное выравнивание при оптимизации на скорость

он не в курсе, он пишет крутую графику :)

#41
15:22, 18 ноя. 2018

Вообще-то дело совсем не в оптимизации, а в банальном выравнивании.

#42
(Правка: 18:41) 18:35, 3 дек. 2018

gammaker
> Go рулит, я доволен, кто бы что про него ни говорил. Я думаю, на шарпе и C/C++
> у меня ушло бы в разы больше времени, а первый я бы ещё и замучался
> разворачивать на устройстве, под которое нет даже дистрибутивов Linux'а с
> менеджером пакетов или хотя бы компилятором. А Go бинарник работает не только
> под линуксом, но и даже в Android: если в папку /data/ его закинуть, можно
> запустить из консоли и будет работать!
именно поэтому я его выбрал для игрового сервера. много всего работает из коробки, а горутины с шедуллером в IO это просто сказка.
ну и самый главный "+" это отсутствие еботни с компиляцией. скачиваешь инсталлер с офф сайта, прописываешь GOPATH, хуяк и все собралось под виндой.
пару кликов и собралось под маком. после плюсов это просто волшебство.
но есть и жирный минус - библиотеки. много всякого полусырого говна типа физ движков, которые не работают или обросли мхом.
или например клиент для монги, который неофициальный и не поддерживает транзакций.

Страницы: 1 2 3
ФлеймФорумПрограммирование