Помню, что на TNT2 Pro, после выхода Корсаров, там у меня были дикие графические глюки с черными текстурами и т.п. Вылечилось после приобретения Radeon VE, т.к. он уже поддерживал DirectX 7.0.
Буквально на днях перешел со своей обычной 1080 на 4080 Super. Разрыв по теоритической макс. производительности (TFLOPS) между ними такой, что 4080 быстрее 1080 примерно в 54 раза. 1080 я купил в 2016, сразу когда она только стала доступна, за 52 тысячи рублей, а 4080 за 149.
Ну времена другие конечно, и прошло 8 лет, деньги видеокарты в России стоят другие, но про 1080 я бы сейчас уже просто забыл.
Проблема в том, что человек изначально не до конца понимал что это, откуда берется, и как этого избежать. И поэтому ему это привиделось там, где этого нет.
Это конечно относится и к С, в данном случае пример вышел и правда не очень показательный.
В С понятно хватает и своих проблем, но их хотя бы сильно меньше по кол-ву, при этом более-менее про них уже все известно за столько лет. С каждым новым стандартом С++ добавляется нечто к тому здоровенному кол-ву вещей, что уже есть.
У меня не хватает никаких ментальных сил все это помнить и учитывать, где я или компилятор С++ поставил в код UB или нет.
Rust конечно представляется неплохим вариантом, но лично я сейчас не могу смотреть на его синтаксис (код выглядит страшновато), ну и в целом пока хватает С.
По поводу алиасинга - в этом-то и смысл - искусственно выдуманная сложность С++ настолько зашкаливающая, что когда казалось бы опытный и квалифицированный программист на С++ находит то, чего не существует, и тратит много времени на то, чтобы убедиться что этого действительно нет - это как-то не очень хорошо, на мой взгляд Но это я привел один из примеров, разбирать тот же плюсовый код на шаблонах это вообще отдельная песня...
Насчет Си и dead end пока не соглашусь (Не буду исключать варианта, что потом в будущем приду к вашим же выводам). Потому как я видел и участвовал в довольно больших проектах на С, где подобных проблем (Гибкость и надежность) не было, с точно такой же длительной историей.
Честно говоря, пару лет назад я думал примерно в таком же ключе, что и вы.
Я окунулся в пару больших проектов на С++, до этого купил и прочитал много серьезных книг по С++ (Скотт Мейерс, Райнер Гримм, и т.п., а главное - книга Федора Пикуса) чтобы быть "в курсе современного С++" и ООП в целом, естественно была так же изучена книга "Банды четырех" про шаблоны проектирования. Общался в процессе работы с другими коллегами, С++-программистами, которые были намного опытнее меня. Но одним из первых звоночков было, как мне помнится, когда один из таких действительно хорошо разбирающихся в С++ коллег смотрел мой код на ревью, нашел алиасинг в одном из методов, а потом сам же после штудирования стандарта и бог весть там чего еще, сказал спустя четыре час, что "Походу я был неправ, алиасинга там нет ".
Но в целом, мои впечатления от этого опыта были сугубо негативные, в стиле известного мема "Пятачок, неси ружье".
Главное, что у меня на осознание этого заняло не так много времени, как бывает у многих, потратил всего около двух лет. Теперь только С и ассемблеры при необходимости, возможно, какой-нибудь Python в ограниченных объемах.
Зависит от. Есть компании, где платят нормальные деньги (меньше конечно, но не драматично и в целом в рынок вписывается) и на С и работу с МК. Но насчет квалификации, вы правы.
Хотелось бы конечно, чтобы квалифицированных программистов на С становилось все больше.
Глупость это думать, что С++ решит все проблемы, просто потому что это С++. ООП для многих вещей спорный кроме GUI, а уж ООП в виде С++ это далеко не самое приятное, что могло получиться (Это еще мягко говоря).
Смысл моего комментария был не в " рассуждать как все плохо" а в том, что на тему своих ПЛИС так же хотелось бы внимания. В плане микроконтроллеров все как раз в каком-то смысле у нас хорошо, многие их у нас уже проектируют и делают/делали на TSMC или где-то там еще. Осталось производство здесь наладить, и будет вообще отлично. Кстати, емнип, самый доступный по цене, К1986ВЕ92QI от Миландра, который в целом сильно похож на популярный STM32F103. Его можно найти в пределах 1к рублей в пластике, если задаться целью.
Микроконтроллеры это конечно хорошо, но было бы неплохо обратить внимание и на производство своих ПЛИС, где есть только зачатки у Миландра (Непонятно в каком сейчас состоянии) и клоны понятно чего от ВЗПП-С. Оба варианта для энтузиастов/хоббистов и т.п. сейчас не подходят, в виду цен и невозможности (либо возможности, но с большими усилиями) получения физическими лицами...
Ну вообще он был чуть поскромнее. Но не сильно. Тогда у меня был Pentium 4 Prescott 2.4 и Radeon 9600XT, на них работало нормально в разрешении 1280х1024.
Зря пропустили, еще не поздно наверстать) Единственный подобный прецедент на моей памяти, когда игра на несколько голов лучше своего прародителя-фильма.
Как еще один живой свидетель 2004 года, скажу, что наверное он был самый легендарный на релизы игр, который ознаменовал собой начало постепенного конца золотой эпохи видеоигр.
В этот год еще вышли The Chronicles of Riddick: Escape from Butcher Bay, и Thief: Deadly Shadows, в которых все увидели на практике те самые тени раньше Дума 3.
Хмм, 4 ядра в 2023 (На пороге 2024) выглядят странновато, хотя по всей видимости, это просто поступательное улучшение того что уже есть, и в целом как собирают SoC'и в Broadcom.
Впервые активное штатное охлаждение, интересно, поставляется вместе, или по отдельности. Будет ли открытый Vulkan-драйвер ? Хотелось бы так же разъем М.2 для NVME. Вопросов много.
Ну и вопрос цены конечно, если она перевалит за 20к, то будет конечно весьма неприятно, учитывая уже текущее наличие конкурентов на RK3588S.
А есть ли такая реальная необходимость использовать Юнити или Анрил ? Вполне возможно, что простая игра может обойтись простым движком, а то и вообще самописным. Не обязательно решать простые проблемы сложными средствами.
Я могу быть не прав, но ценность Юнити или Анрила скорее в том, что если вы будете хорошо знать что-то из них, то это потенциальный источник дохода при работе на "дядю", который их использует у себя. Конечно, глупо отрицать что у них есть куча ассетов, коммюнити, выгодные условия при издании в их сторах, лояльность издателей, и т.п., и т.д.
Мой месседж скорее больше о том, что в большинстве случаев скорее всего вы спокойно все издадите, но, как говорится - если есть вероятность что условно в 5% случаев внезапно Эпики/кто-то другой обалдеют и своими действиями развалят вам проект, то как пить дать, вам бы не захотелось быть среди этих 5%. Особенно если были взяты какие-то долговые обязательства.
Да. Но это работает и в обратную сторону - у вендора с закрытыми исходниками может быть не реализовано то, что нужно именно вам для конкретно вашего проекта. Могут быть критичные конкретно для вашей области применения данной технологии баги, которые не фиксятся годами, потому что "это надо двум землекопам со всей планеты земля, проще забить".
К тому же, в случае с некоторыми современными "игровыми" движками (Возьмем для примера Unreal) разработчики распыляют усилия, делая фичи для архитектурной визуализации, фильмов, и т.п. пытаясь засесть на все стулья, и угодить всем кому только можно, вместо того, чтобы сосредоточить усилия на том, чем этот движок был изначально - для производства игр.
Очень показательный пример о том, почему вообще никогда нельзя лочиться на вендора какой-либо технологии. И нет совершенно никакой гарантии, что те же Epic Games не выдадут в будущем что-то подобное.
Не из своего кода в проектах можно использовать только открытый код с пермиссивными лицензиями. Иначе рано или поздно, добрый незнакомый дядя решит, что вы и ваш бизнес слишком много кушат, пора делиться.
Такие пасхалки греют душу, особенно когда на них сам натыкаешься, не зная заранее. Как пример -
Помню, что на TNT2 Pro, после выхода Корсаров, там у меня были дикие графические глюки с черными текстурами и т.п. Вылечилось после приобретения Radeon VE, т.к. он уже поддерживал DirectX 7.0.
Да, что-то мы оба ошиблись, в 6.23 раза на Single Precision )
Буквально на днях перешел со своей обычной 1080 на 4080 Super. Разрыв по теоритической макс. производительности (TFLOPS) между ними такой, что 4080 быстрее 1080 примерно в 54 раза. 1080 я купил в 2016, сразу когда она только стала доступна, за 52 тысячи рублей, а 4080 за 149.
Ну времена другие конечно, и прошло 8 лет, деньги видеокарты в России стоят другие, но про 1080 я бы сейчас уже просто забыл.
Можно посоветовать поставить что-то из линейки PMU китайского производителя X-Powers, например AXP173.
Микросхемы очень дешевые (есть варианты в районе 60р штука), не какой-нибудь Texas Instruments.
Существуют.
Проблема в том, что человек изначально не до конца понимал что это, откуда берется, и как этого избежать. И поэтому ему это привиделось там, где этого нет.
Это конечно относится и к С, в данном случае пример вышел и правда не очень показательный.
В С понятно хватает и своих проблем, но их хотя бы сильно меньше по кол-ву, при этом более-менее про них уже все известно за столько лет. С каждым новым стандартом С++ добавляется нечто к тому здоровенному кол-ву вещей, что уже есть.
У меня не хватает никаких ментальных сил все это помнить и учитывать, где я или компилятор С++ поставил в код UB или нет.
Rust конечно представляется неплохим вариантом, но лично я сейчас не могу смотреть на его синтаксис (код выглядит страшновато), ну и в целом пока хватает С.
По поводу алиасинга - в этом-то и смысл - искусственно выдуманная сложность С++ настолько зашкаливающая, что когда казалось бы опытный и квалифицированный программист на С++ находит то, чего не существует, и тратит много времени на то, чтобы убедиться что этого действительно нет - это как-то не очень хорошо, на мой взгляд Но это я привел один из примеров, разбирать тот же плюсовый код на шаблонах это вообще отдельная песня...
Насчет Си и dead end пока не соглашусь (Не буду исключать варианта, что потом в будущем приду к вашим же выводам). Потому как я видел и участвовал в довольно больших проектах на С, где подобных проблем (Гибкость и надежность) не было, с точно такой же длительной историей.
Честно говоря, пару лет назад я думал примерно в таком же ключе, что и вы.
Я окунулся в пару больших проектов на С++, до этого купил и прочитал много серьезных книг по С++ (Скотт Мейерс, Райнер Гримм, и т.п., а главное - книга Федора Пикуса) чтобы быть "в курсе современного С++" и ООП в целом, естественно была так же изучена книга "Банды четырех" про шаблоны проектирования. Общался в процессе работы с другими коллегами, С++-программистами, которые были намного опытнее меня. Но одним из первых звоночков было, как мне помнится, когда один из таких действительно хорошо разбирающихся в С++ коллег смотрел мой код на ревью, нашел алиасинг в одном из методов, а потом сам же после штудирования стандарта и бог весть там чего еще, сказал спустя четыре час, что "Походу я был неправ, алиасинга там нет ".
Но в целом, мои впечатления от этого опыта были сугубо негативные, в стиле известного мема "Пятачок, неси ружье".
Главное, что у меня на осознание этого заняло не так много времени, как бывает у многих, потратил всего около двух лет. Теперь только С и ассемблеры при необходимости, возможно, какой-нибудь Python в ограниченных объемах.
The cake is a lie.
Если вы про обширное кол-во доступных библиотек, то для С большая часть того что требуется повседневно, так же существует.
Зависит от. Есть компании, где платят нормальные деньги (меньше конечно, но не драматично и в целом в рынок вписывается) и на С и работу с МК. Но насчет квалификации, вы правы.
Хотелось бы конечно, чтобы квалифицированных программистов на С становилось все больше.
Глупость это думать, что С++ решит все проблемы, просто потому что это С++. ООП для многих вещей спорный кроме GUI, а уж ООП в виде С++ это далеко не самое приятное, что могло получиться (Это еще мягко говоря).
Эта компания кстати говоря, недавно "исправилась" - https://github.com/NVIDIA/open-gpu-kernel-modules
Смысл моего комментария был не в " рассуждать как все плохо" а в том, что на тему своих ПЛИС так же хотелось бы внимания. В плане микроконтроллеров все как раз в каком-то смысле у нас хорошо, многие их у нас уже проектируют и делают/делали на TSMC или где-то там еще. Осталось производство здесь наладить, и будет вообще отлично. Кстати, емнип, самый доступный по цене, К1986ВЕ92QI от Миландра, который в целом сильно похож на популярный STM32F103. Его можно найти в пределах 1к рублей в пластике, если задаться целью.
Микроконтроллеры это конечно хорошо, но было бы неплохо обратить внимание и на производство своих ПЛИС, где есть только зачатки у Миландра (Непонятно в каком сейчас состоянии) и клоны понятно чего от ВЗПП-С. Оба варианта для энтузиастов/хоббистов и т.п. сейчас не подходят, в виду цен и невозможности (либо возможности, но с большими усилиями) получения физическими лицами...
Ну вообще он был чуть поскромнее. Но не сильно. Тогда у меня был Pentium 4 Prescott 2.4 и Radeon 9600XT, на них работало нормально в разрешении 1280х1024.
Зря пропустили, еще не поздно наверстать) Единственный подобный прецедент на моей памяти, когда игра на несколько голов лучше своего прародителя-фильма.
Как еще один живой свидетель 2004 года, скажу, что наверное он был самый легендарный на релизы игр, который ознаменовал собой начало постепенного конца золотой эпохи видеоигр.
В этот год еще вышли The Chronicles of Riddick: Escape from Butcher Bay, и Thief: Deadly Shadows, в которых все увидели на практике те самые тени раньше Дума 3.
Хмм, 4 ядра в 2023 (На пороге 2024) выглядят странновато, хотя по всей видимости, это просто поступательное улучшение того что уже есть, и в целом как собирают SoC'и в Broadcom.
Впервые активное штатное охлаждение, интересно, поставляется вместе, или по отдельности. Будет ли открытый Vulkan-драйвер ? Хотелось бы так же разъем М.2 для NVME. Вопросов много.
Ну и вопрос цены конечно, если она перевалит за 20к, то будет конечно весьма неприятно, учитывая уже текущее наличие конкурентов на RK3588S.
А есть ли такая реальная необходимость использовать Юнити или Анрил ? Вполне возможно, что простая игра может обойтись простым движком, а то и вообще самописным. Не обязательно решать простые проблемы сложными средствами.
Я могу быть не прав, но ценность Юнити или Анрила скорее в том, что если вы будете хорошо знать что-то из них, то это потенциальный источник дохода при работе на "дядю", который их использует у себя. Конечно, глупо отрицать что у них есть куча ассетов, коммюнити, выгодные условия при издании в их сторах, лояльность издателей, и т.п., и т.д.
Мой месседж скорее больше о том, что в большинстве случаев скорее всего вы спокойно все издадите, но, как говорится - если есть вероятность что условно в 5% случаев внезапно Эпики/кто-то другой обалдеют и своими действиями развалят вам проект, то как пить дать, вам бы не захотелось быть среди этих 5%. Особенно если были взяты какие-то долговые обязательства.
Да. Но это работает и в обратную сторону - у вендора с закрытыми исходниками может быть не реализовано то, что нужно именно вам для конкретно вашего проекта. Могут быть критичные конкретно для вашей области применения данной технологии баги, которые не фиксятся годами, потому что "это надо двум землекопам со всей планеты земля, проще забить".
К тому же, в случае с некоторыми современными "игровыми" движками (Возьмем для примера Unreal) разработчики распыляют усилия, делая фичи для архитектурной визуализации, фильмов, и т.п. пытаясь засесть на все стулья, и угодить всем кому только можно, вместо того, чтобы сосредоточить усилия на том, чем этот движок был изначально - для производства игр.
Очень показательный пример о том, почему вообще никогда нельзя лочиться на вендора какой-либо технологии. И нет совершенно никакой гарантии, что те же Epic Games не выдадут в будущем что-то подобное.
Не из своего кода в проектах можно использовать только открытый код с пермиссивными лицензиями. Иначе рано или поздно, добрый незнакомый дядя решит, что вы и ваш бизнес слишком много кушат, пора делиться.