стоит ли запилить тему по с++

Была тут как-то тема с реальными измерениями и сравнениями.
Это была катастрофа :lol:.
пс. язык не главное. Главное - что может позволить инженеру его серое вещество, и в частности, какой язык оно может ему позволить.

 

да,

Спойлер: асм портянка

- просто класс
кстати, давай-ка вернёмся к раста драверу..
https://www.phoronix.com/news/LPC-2022-Rust-Linux
ни-4ё забавного не замечаешь?

 

Но в целом я вообще ни капли не удивлен твоим результатом))

 

UbIvItS, -C opt-level=3 забыл

 

4ё-то вы, ребята, совсем тему не читаете

 

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

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

--- Сообщение объединено, 5 мар 2023 ---

Катастрофа в чью пользу?

--- Сообщение объединено, 5 мар 2023 ---

А так, в принципе, можно не спорить: вот исчерпывающие бенчмарки: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html

 

короче, не смотрел ты те тесты - смотрим теперь сюда..

Спойлер: расхождение скорости си и раста на слабых машинах

https://www.phoronix.com/image-viewer.php?id=2022&image=rust_nvme_3_lrg

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

 

Так о чём это говорит? Что даже перед жабой у си нет преимуществ на быстрых машинках?

 

экий ты юморист, однако это говорит о том, что с раста драверами машина легче/быстрей проседает на пиковых нагрузках.

 

Ты же только что выше сказал про примерно равные результаты. Так равные или нет?

По тому графику давай посчитаем. Пусть раст показал 3.375, а си - на 0.0625 больше (3.4375). Посчитаем, сколько это в процентах: (3.375 * 100 / 3.4375) = 1.85%. Округлим даже до двух.
И ты хочешь сказать, что разница в два процента стоит того, чтобы отказываться от удобств современных языков?
Ты скажешь: конечно, смотря два процента от чего, а я отвечу, что не важно: если у тебя есть 100% чего угодно, то 2% от него - незначительно. Чуть двигаешься по скорости - взамен получаешь комфортный язык, сахар, систему сборки, более краткий и выразительный код, меньшее время на отладку и тестирование, меньшие сроки выхода фич в релиз. Да мы со всех сторон в плюсе!
И я сейчас не только про раст, а про любой язык, который можно взять на замену сям. Да хоть Go или жаба, если производительность не слишком критична!

 

Убивец просто не в курсе, что:

 

Странно что никто не нашёл ту тему. Там С код выполнялся в 20 раз быстрее.
Но я про другое. Ежу понятно, что там просто школьник скорее всего накосячил. В 20 раз, блин .
Я про то, что там пацаны взяли линейки и всё померяли. Чётко и ясно, с цифрами. И кстати, странно, что никто из опытных товарищей не поправил новичка, не помог ему и его коду.
А вы:
- У меня длиннее !
- Нет у меня !

 

А что за тема-то? Интересно взглянуть.

 

https://wasm.in/threads/uskorenie-algoritma.34138/

 

Спойлер: Спойлер

Мы сидели и вникали,
Разбирали, собирали,
Замеряли, вычисляли,
Днями, сутками, ночами.
Умножали и делили,
Выбирали или-или,
Но машина всё ж не едет.

Что за козни? Что за бредни?
Мы по новой за расчеты.
Может там у нас просчеты,
Может что-то упустили,
Не нашли, не уследили
Вдруг не то мы вычисляли
Днями, сутками, ночами.

Но машина вновь не едет.
Инженер наш главный бредит.
Снова мы на путь тернистый.
Должен быть расчет ведь истов.
Умножаем, вычисляем,
Алгоритмы составляем.
Только было всё напрасно,
Лишь потом нам стало ясно,

 

Код (C):

1.  
2. static int sum (const int* values, int count)
3. {
4.     int i, result;
5.     for (i=0, result=0; i<count; i++)
6.         result += values[i];
7.     return result;
8. }
9.  
10. int _tmain (int argc, TCHAR** argv)
11. {
12.     const int values[] = {1, 2, 3, 4, 5};
13.     return sum (values, 5);
14. }
15.  
16. .text:0000000140001000 ; int __cdecl main(int argc, const char **argv, const char **envp)
17. .text:0000000140001000 main            proc near               ; CODE XREF: __tmainCRTStartup+115↓p
18. .text:0000000140001000                 mov     eax, 0Fh
19. .text:0000000140001005                 retn
20. .text:0000000140001005
21. .text:0000000140001005 main            endp
22.  

Код (C):

1.  
2. static int sum (const int* values, int count)
3. {
4.     int i, result;
5.     for (i=0, result=0; i<count; i++)
6.         result += values[i];
7.     return result;
8. }
9.  
10. int _tmain (int argc, TCHAR** argv)
11. {
12.     const int values[] = {1, 2, 3, 4, 5};
13.     return sum ((int*)0x12345, 5);
14. }
15.  
16. .text:0000000140001000 ; int __cdecl main(int argc, const char **argv, const char **envp)
17. .text:0000000140001000 main            proc near               ; CODE XREF: __tmainCRTStartup+115↓p
18. .text:0000000140001000                 mov     eax, ds:12355h
19. .text:0000000140001007                 add     eax, ds:12351h
20. .text:000000014000100E                 add     eax, ds:1234Dh
21. .text:0000000140001015                 add     eax, ds:12349h
22. .text:000000014000101C                 add     eax, ds:12345h
23. .text:0000000140001023                 retn
24. .text:0000000140001023
25. .text:0000000140001023 main            endp
26.  

Код (C):

1.  
2. static int sum (const int* values, int count)
3. {
4.     int i, result;
5.     for (i=0, result=0; i<count; i++)
6.         result += values[i];
7.     return result;
8. }
9.  
10. static int* create_values (int count)
11. {
12.     int* values;
13.     int i;
14.     values = (int*)malloc (sizeof(int) * count);
15.     for (i=0; i<count; i++)
16.         values[i] = i + 1;
17.     return values;
18. }
19.  
20. int _tmain (int argc, TCHAR** argv)
21. {
22.     int* values;
23.     values = create_values (5);
24.     return sum (values, 5);
25. }
26.  
27. .text:0000000140001000 ; int __cdecl main(int argc, const char **argv, const char **envp)
28. .text:0000000140001000 main            proc near               ; CODE XREF: __tmainCRTStartup+115↓p
29. .text:0000000140001000                                         ; DATA XREF: .pdata:ExceptionDir↓o
30. .text:0000000140001000                 sub     rsp, 28h
31. .text:0000000140001004                 mov     ecx, 14h        ; Size
32. .text:0000000140001009                 call    cs:__imp_malloc
33. .text:0000000140001009
34. .text:000000014000100F                 mov     r11, rax
35. .text:0000000140001012                 mov     dword ptr [rax], 1
36. .text:0000000140001018                 mov     dword ptr [rax+4], 2
37. .text:000000014000101F                 mov     dword ptr [rax+8], 3
38. .text:0000000140001026                 mov     dword ptr [rax+0Ch], 4
39. .text:000000014000102D                 mov     dword ptr [rax+10h], 5
40. .text:0000000140001034                 mov     eax, [rax+10h]
41. .text:0000000140001037                 add     eax, [r11]
42. .text:000000014000103A                 add     eax, [r11+4]
43. .text:000000014000103E                 add     eax, [r11+8]
44. .text:0000000140001042                 add     eax, [r11+0Ch]
45. .text:0000000140001046                 add     rsp, 28h
46. .text:000000014000104A                 retn
47. .text:000000014000104A
48. .text:000000014000104A main            endp
49.  

Visual Studio 2008
1>------ Построение начато: проект: test, Конфигурация: Release x64 ------
1>Компиляция...
1>Оптимизирующий компилятор Microsoft (R) C/C++ версии 15.00.21022.08 для x64
1>(C) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
1>cl /O2 /Oi /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Gy /Fo"x64\Release\\" /Fd"x64\Release\vc90.pdb" /W3 /c /Zi /TC .\main.c

 

я б с тобой мб и мог бы согласиться в эдак - так конце 90ых / начале нулевых - тогда каждая новая жестянка в реале была шустрей старой да не требовалось неких синтетических тестов для пудрЁжки мозгов. а вот теперь прирост производительности новых жестянок (скажем помягче) носит крайне гибридный характер с явным уклоном в лпп. и тута стоит помнить вот такие МЕЛОЧИ..

1. у современных железок физ размер бита уже очень сильно близок к критическому, что делает его слишком нестабильным: современные цпу/гпу/озу бодро деградируют даже на номинальных частотах, а инфа на современных хдд/ссд может и пяти лет не жить (даже в пассивном режиме).
2. жестянки х64 и при самом оптимистичном раскладе особо дешеветь не будут..
2.1. сейчас мы на самом пороге массового закрытия датацентров, кои (надо помнить) закупают 80+% всего х64.
========
и-таки, да == 2% -это чудовищно много - это ж потеря скорости на одном потоке да не просто потоке, а на лёгком/ядерном потоке.. 10 таких потоков и примерно 20% тиков съедается за некие там удобства. едем дальше: с приближением к пиковым нагрузкам рост лагов становится нелинейным. и кто же такие удобства оплачивать будет??? реклама вязанок дров едва ли столь прибыльна

 

Просто напоминаю, что проценты так не умножаются. На 10 потоках будут те же 2% от их общей производительности.

А лпп - это что?

Предположим, что так и есть, железо действительно склонно деградировать со временем - но… и что? Как это связано с выбором языков?

 

Ты абсолютно прав при условие линейного роста лагов. но за их линейность надо всегда тяжело бороться

скорость деградации сильно уменьшается на быстрых кодах.

ложь, пиииии и провокация.