Забавные новости 0й-Ti :)

Еще несомненным плюсом является, что всякие <type> в _GovnoCode<int>(ololo); похожи на летающие тарелки инопланетян

 

Одно дело спрятать всю структуру, а другое - определенные поля структуры. И совсем другое - разграничить доступ у производных классов к полям. Тот метод что ты описал - я кстати всегда только и использую в С - прячу всю реализацию в с файле, а наружу у меня "торчит" интерфейс типа:

Код (C):

1. #ifndef CLIST_H
2. #define CLIST_H
3.  
4. #include <Windows.h>
5.  
6. typedef INT (*CLIST_COMPARE_FN)(PVOID pv1, PVOID pv2);
7. typedef struct _IList IList;
8.  
9. typedef struct _IListVtbl {
10.    
11.     UINT (*AddRef)(IList* pThis);
12.     UINT (*Release)(IList* pThis);
13.  
14.     HRESULT (*Add)(IList* pThis, PVOID pvObj);
15.     HRESULT (*Remove)(IList* pThis, UINT uIndex);
16.     VOID (*Clear)(IList* pThis);
17.     UINT (*get_Count)(IList* pThis);
18.     HRESULT (*get_Item)(IList* pThis, UINT uIndex, PVOID* ppvRet);
19.     VOID (*Shuffle)(IList* pThis);
20.     VOID (*Sort)(IList* pThis, CLIST_COMPARE_FN pfn);
21.  
22. } IListVtbl;
23.  
24. struct _IList {
25.     IListVtbl *pVtbl;
26. };
27.  
28. HRESULT New_CList(IList **ppRet, BOOL bWeakRefs);
29.  
30. #endif

Код (Text):

1.  
2. #include "common.h"
3. #include "CList.h"
4. #include "CMemory.h"
5. #include "log.h"
6.  
7. typedef struct _CList {
8.     IListVtbl *pVtbl;
9.     UINT m_uRefCtr;
10.     IGenericObject** m_pList;
11.     UINT m_uCount;
12.     UINT m_uBufSize;
13.     BOOL m_bWeakRefs;
14. } CList;
15.  
16. UINT CList_AddRef(CList* pThis);
17. UINT CList_Release(CList* pThis);
18. HRESULT CList_Add(CList* pThis, PVOID pvObj);
19. HRESULT CList_Remove(CList* pThis, UINT uIndex);
20. VOID CList_Clear(CList* pThis);
21. UINT CList_get_Count(CList* pThis);
22. HRESULT CList_get_Item(CList* pThis, UINT uIndex, PVOID* ppvRet);
23. VOID CList_Shuffle(CList* pThis);
24. VOID CList_Sort(CList* pThis, CLIST_COMPARE_FN pfn);
25.  
26. static IListVtbl s_tVtbl = {
27.     (UINT (*)(IList*))CList_AddRef,
28.     (UINT (*)(IList*))CList_Release,
29.     (HRESULT (*)(IList*, PVOID))CList_Add,
30.     (HRESULT (*)(IList*, UINT))CList_Remove,
31.     (VOID (*)(IList*))CList_Clear,
32.     (UINT (*)(IList*))CList_get_Count,
33.     (HRESULT (*)(IList*, UINT, PVOID*))CList_get_Item,
34.     (VOID (*)(IList*))CList_Shuffle,
35.     (VOID (*)(IList*, CLIST_COMPARE_FN))CList_Sort
36. };
37.  
38. // New list of objects.
39. HRESULT New_CList(IList **ppRet, BOOL bWeakRefs) { ... }

--- Сообщение объединено, 13 ноя 2023 ---

Понятно

 

По сабжу: метапрограммирование - это хорошо, безусловно, но для меня Цэ - гуан, тк в стандарте языка нет RAII. Вот добавить в Цэ нормальный defer и стало бы терпимо, даже со слабой статической типизацией можно было бы смириться. Понятно, что в GCC есть attribute((cleanup)), но это далеко не тоже самое. В C23 вроде был пропозал для этого, но для меня поздновато, я уже испорчен другими языками программирования.

 

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

 

Согласен, но это лишь пример, что они умеют и для чего нужны, как демонстрация того, что сами по себе они не вносят никакого оверхеда)
Обычно шаблоны используют в более сложных случаях: например, когда из одного типа надо вывести другой тип. Или когда надо тип завернуть в обёртку. Или чем-то дополнить. Или классифицировать.
Т.е., шаблоны - это больше про работу с типами, нежели про подстановку любого типа вместо T.
Например, смотри, какое чудище можно соорудить на шаблонах: https://github.com/HoShiMin/Sig
Выглядит страшно, зато в компайлтайме запекается в очень быструю проверку.

 

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

 

Такое чувство, будто ты их просто не осилил а значит НИНУЖНО

 

На счёт шаблонов и сюрпризов. Ковыряя хреей, я заметил что поля(свойства) которые в структуре, т.е классе, завёрнуты в шаблоны, причём вроде не шибко сложные, не выравниваться. Всё конечно работает, но вот с некоторыми структурами, а именно Fvector4, уже инструкциями типа movaps и addps xmm*, memParam не поработаешь, исключение и непонятный вылет(из-за этого в XRayExtensions приходиться делать код, который работает с кривыми данными). В общем, что-то идёт не так, студия на которой хрей(ТЧ) собирался вроде VS2005, может у новых нет такой проблемы.

 

Скорей всего студия не выровняла поля, с которыми работает через movaps, на 16 байт. Попробуй векторам явно прописать alignas(16):

Код (C++):

1.  
2. class alignas(16) Fvector4
3. {
4.     ...
5. };
6.  

и пересобрать всё, где используются эти вектора.
Но подозреваю, что проблема в старых студиях...

Если alignas не работает (например, стандарт C++03), то вместо него юзай майкрософтовское расширение __declspec(align(16)):

Код (C++):

1.  
2. __declspec(align(16)) class Fvector4
3. {
4.     ...
5. };
6.  

--- Сообщение объединено, 14 ноя 2023 ---

А сам оригинальный ТЧ использует SSE для этих векторов?

 

Только скалярные инструкции, чтобы работали упакованные, надо ручками переделывать код в _vector3d.h и расширив структуру T x,y,z; до float x,y,z,_; или так float x,y,z,w. А так же использовать интринсики в методах класса.
В общем, тут приходиться отказаться от шаблонов, т.к. простая подмена Т, не работает. Хотя вариант шаблона класса для double можно сделать AVX с подменой аналогичной для SSE1 инструкции.
Хотя я частично это сделал, но так до реального применения дело не дошло. Хотя тесты сделал для своего райзена, для умножения матрицы мой код на ассме это делает за 15 тактов, атлон это делал за 50 тактов, а скалярными методами вроде что-то около 115 тактов, это атлон. В общем, в приложениях которые массировано используют 3д векторы, выгодно применить упакованные SSE/AVX векторы, очень неплохо они ускоряться на современных проц.
Кстати, там если поля вне шаблона, то всё выравнивается, а в шаблонах студия почему-то забывает совсем выронить структуру, даже 2 или 4.

 

А ты работаешь с оригинальным X-Ray? Может, есть вариант пересобрать весь движок из OpenXRay на 2022й студии и проверить там? Или ТЧ на нём не заработает? Просто в этом случае скорей всего компилятор правильно всё выровняет и ещё сверху сам что-нибудь векторизует.

 

HoShiMin, сейчас я не ковыряю хрей, возможно уже 2010сп1 всё исправлено, особенно если добавить нужные модификаторы или как их там.

Я тут глянул на ролик.

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

Код (ASM):

1.  
2. .for (esi=0: esi<1000000: esi++)
3. ...
4. .endfor

И код наглядный, и вывод очень простой

Код (ASM):

1.  printf("Param0 = %d, Param1 = %.6f\n", esi, ^param1)

Этот код на порядок более наглядный, в сравнении чтобы вывести форматированную строку данных в этом "простом" питухоне.
Всё таки питухон трешовый ЯП.

--- Сообщение объединено, 14 ноя 2023 ---

Вот ещё один пример манипуляции с питухонием.

Да я уже проводил тесты, 95% занято выполнением деления. Вообще не корректный тест.

 

На самом деле, ты смотришь не те видео. Никто не ускоряет питон, его производительности с головой хватает для задач, где его используют.
А где не хватает - берут готовые либы на компилируемых языках.
Питон используют для автоматизации, скриптинга и прототипирования - там важна не производительность, а скорость разработки и внесения изменений.
Например, ты пишешь нейронку. Готовить модель удобно на питоне, а обсчитываться она будет в сишной либе на CUDA.
Писать вообще всё на низкоуровневых языках - впустую тратить время: сэкономишь минуту, а на написание потратишь час.

Лучше посмотри, что на самом деле делают на питоне:




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

 

HoShiMin, на самом деле куча погромистов которые кодят на питохонии, а кодить на С++ и не собираются, если что-то тормозит, то вкарячат что-то типа как в видео, а зачем?, питухоний же быстрей С++, вот видео же.
Только питухонцы не в курсе, что это тесты-фокус, берём задачу, где оптимизированный код занят выполнением в цикле 95% делениями. А питухоний может 10% делениями в цикле занят, и в результате у С/С++/Ассм не самые лучшие сравнительные с питухонием результаты. Но это не главное, сам питухоний нелегче того же С++, синтаксис всратый, такое же чудовищное количество библиотек и разных конструкций.
В общем, блаблабла, по мне лучше, С++ и Lua лучший вариант. А нейросети можно и на ассемблере считать, какая блин разница. Только библиотеку подключи и настрой как надо. А если сделать ассм где в место туповатого макро языка, прикрутить что-то вроде Луа, только по проще, без не нужного. То и вообще, можно обойтись одним таким ассмом, ну для многих задач.

--- Сообщение объединено, 14 ноя 2023 ---

Глянул видео. Первое: это уже настроенные библиотеки, и их надо учить, не факт что если аналогичное сделав на С++, или вообще на ассме, то быстрей всё освоишь. То есть, проще всё сделать самому, чем разбираться этом хламе.
Второе: это уже предвычислено , чувак потратив сколько лет не знаю, уже всё настроил, короче, опять фокусы, только более сложные.
Лучше сразу делать на С++, чем потом как то запекать, да ещё на ассме, тут я кстати, вообще не понял. Я, вдоволь натрахавшись с питухонием, кое как довёл проект до чего-то работоспособного, должен всё удалить и переписать на С++. Или как запекать? А должен воспользоваться конвертором который код питухония перегонит в С++, либо в ассм? Ага, прямо в АТ@Т, чтобы я ещё стессировал по всратому устаревшему атИт синтаксису.

 

Ага, обычно так и делают.
На питоне экспериментируют, на чём-то нативном уже делают чистовик.
Потому что представь: у тебя есть данные, их надо визуализировать, а как это сделать на плюсах? Или писать рендер самому, или юзать готовые либы - а их надо собирать с десятком зависимостей, подключать, они с первого раза не соберутся, потом писать интерактив, парсить текстовые файлы, конфиги… в общем, делать кучу рутинной работы, которая на питоне делается по щелчку пальцев.
Надо график? Пожалуйста. Захотел из графика сделать гистограмму? Без проблем. Экспорт в CSV для экселя? В одну строчку. Парсинг XML или JSON? Как с добрым утром. Минимальное время от идеи до воплощения.
И всё это не требует ультраскорости.
На плюсах всё это писать будет многократно дольше, а полезного выхлопа ноль: будет у тебя CSV формироваться не секунду, а сто микросекунд - ну да, а пока всё это писал, на питоне бы уже проверил сто моделей.

Я всё веду к тому, что питон - не замена нативным языкам, а дополнение. У многих питоновских библиотек под капотом сишные и плюсовые либы, типа Cairo, Intel MKL или либ для CUDA.
Но чтобы не писать для них сложный нативный фронтенд, для них юзают дружелюбные питоновские биндинги.

--- Сообщение объединено, 15 ноя 2023 ---

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

 

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

А по поводу проще было написать все самому на Плюсах: я по молодости один раз попробовал написать JSON парсер, удовлетворяющий стандарту на Плюсах, так вот я закончил за часа 4-5 с парой перерывов на поплакать. Рекомендую попробовать сделать тоже самое, чтобы в будущем не было претенциозного желания вместо json.loads делать свой собственный парсер с преферансом и куртизанками.

 

В С++ есть строки, т.е. типы почти как в Луи или питухонии. Да и на ассме не шибко сложно работать со строками, а если бы в UASM добавили скриптовый макроязык, ну чтобы иметь более удобные методы обработки строк, ассоциативные таблицы, то можно легко написать макросы для работ со строками. А пока это можно сделать с ограничениями по символам !()<> , но касается компиляции своего кода.
Хотя не знаю, что есть такое в питухонии, чего нельзя сделать на ассме или тем более С++, строка она и в африке строка, на ассме и С++ несложно работать, это в чистом С это может быть слишком громоздко.

--- Сообщение объединено, 15 ноя 2023 ---

Занятно, но тут чел замутил нейросеть на FASM.
https://ru.anyquestion.info/a/neyro...ya-fasm-dlya-sozdaniya-intellektualnyh-sistem
И работает же. Правда стиль автора типичный бейсикообразный, мне такой не нравиться, я фанат структурного, модульного с элементами ООП способа программирования на ассме, такой код при необходимости легко перегоняться декомпилятором идушки в С и потом вручную в С++.

 

для реалтайма пишут до тупости гениальные коды, то бишь там не должно быть ничего лишнего. вот возьмём самую примитивную задачу - устаканить в одном шаблоне инт32 вс инт64. но при отимазах сразу же вылезает, что на одних железках инт64 влезает целиком в регистр, а на других этот инт нужно раскидывать по разным местам и получаем разные лаги. 2ой момент, при больших выч нагрузках у проца начинают вылезать режимы нестабильности из-за роста вихревых токов и во избежание таких траблемусов тоже нужно прописывать альт алгосы. все современные яп-ы писались на игровые железки и главной их целью является облегчение разработки. Однако, в реале все улучшения оказались местечковыми: тот же сборщик мусора хорош ровно до того момента, пока не начинаются большие данные и он тупо вылетает в аут; шаблоны в тех же плюсах очень хороши, но ровно до тех пор, пока не надо детализировать работу фунок и тогда получишь те же энн вариантов (что и в сишке).. на плюсах куча публики практически обфускацию кода делают в силу своей стилистики и это никак и ничего не улучшает == проекты становятся тупо тупиковыми... а аду, вообще, писали под железки из фэнтези вселенных

Молодец, конечно.. но мне не совсем понятно об аких патернах речь.. явно не об этих https://en.wikipedia.org/wiki/Local_binary_patterns