мы должны сделать функцию Process не виртуальной и переместить ее в заголовочный файл
Перемещать имплементацию функции Process в заголовочный файл вовсе не обязательно, класс DebugPrint не является темплейтом и имплементация его функций вполне может остаться в .cpp файле.
И кстати, если уж взялись писать про CRTP можно было бы рассказать насколько проще и удобней эту функциональность можно сделать в C++23.
Ну как говориться "ложечки нашлись, но осадочек остался". Хаффман в стольки легаси сидит, что будет еще долго использоваться "по дефлоту". Арифметическое постепенно внедряется, например в JPEG оно есть, если не путаю, но...
Вообще есть еще более эффективное арифметическое кодирование, но из-за того, что кто-то хотел очень много денег, оно гораздо менее распространено, чем могло бы...
Вопрос не в том, что кто-то что-то обязан сделать или нет. Вопрос в практичности. Если чувак_2 нашел какую-то багу в проекте чувака_1, то ему было-бы гораздо удобней, чтобы эту багу поправил чувак_1 ну или по крайней мере предоставить ему фикс для интеграции в базовый проект, чем потом при каждом апмерже проеврять, не поломалось ли из-за этого фикса что-то еще. Это конечно-же при условии довольно частых апмержей, что впрочем в нормальной практике случается гораздо чаще, чем полный отрыв форка от базового проекта.
В отличие от питона тут могут быть полезные классы чуть ли не вообще без методов. Например я предпочту использовать std::chrono::duration вместо int для хранения интервала времени.
И так во многом. Конечно не надо впадать в крайности. Но это справедливо в обоих отношениях, как не надо делать "лишних" классов (когда они реально лишние), так-же не надо и стремиться к тому чтобы пытаться обходиться без классов, там где они все-же будут полезны.
Совет №57 тоже не бесспорный.
С одной стороны в сообществе есть консенсус, что учить C++ лучше по хорошим книгам. С другой стороны, люди все-же разные. Есть такие, кто усваивает информацию лучше из книг, есть кто лучше из аудио, есть кто лучше из видео, а есть такие, кому проще самому во всем разобратся начав писать код.
Ну т.е. как совет для большинства вроде и ок, но как безусловно "вредыный совет" для всех - не ок.
К сожалени, из опыта попыток использования std::string_view, не очень оно и подходит. В большинстве случаев оказывается что либо чего-то не хватает (например конкатенации двух sv) без предварительной конвертации в std::string, либо в какой-то очередной API надо передать именно string. Единственное где sv сейчас применять удобно, это всякого рода парсинг, когда можно сделать remove_prefix() и/или remove_suffix() без реаллокации.
kobold по умолчанию использует количество потоков развное количеству физических ядер. Используйте параметр --threads чтобы поиграться с разными значениями.
Можно попробовать просто позадавать хитрые промпты для начала. А насчет дообучения, если для вас 4-8 "A100 GPU-80GB" - это "домашние условия", то почему нет...
Вообще в этих моделях цензура настроена только на английский по-моему. По крайней мере, когда с ними общяешься по-русски, то он и про женщин шутит и даже про негров (пробовал викуну). Но конечно кочество ответов похуже, чем на английском...
Разница только в UI. llama.cpp - это консоль, а koboldcpp - это (если я правильно понял, не пробовал пока) web интерфейс. Но, движок там от той-же llama.cpp. Ну и само собой модели все те-же.
Конечно я это понимаю. Просто наверно не совсем удачно выразился. Я имел в виду не текущий момент, а скорее долгосрочную политику США в плане "ненавязчивого" PR себя везде и всегда.
Перемещать имплементацию функции
Processв заголовочный файл вовсе не обязательно, классDebugPrintне является темплейтом и имплементация его функций вполне может остаться в .cpp файле.И кстати, если уж взялись писать про CRTP можно было бы рассказать насколько проще и удобней эту функциональность можно сделать в C++23.
Ну как говориться "ложечки нашлись, но осадочек остался". Хаффман в стольки легаси сидит, что будет еще долго использоваться "по дефлоту". Арифметическое постепенно внедряется, например в JPEG оно есть, если не путаю, но...
Вообще есть еще более эффективное арифметическое кодирование, но из-за того, что кто-то хотел очень много денег, оно гораздо менее распространено, чем могло бы...
Вопрос не в том, что кто-то что-то обязан сделать или нет. Вопрос в практичности. Если чувак_2 нашел какую-то багу в проекте чувака_1, то ему было-бы гораздо удобней, чтобы эту багу поправил чувак_1 ну или по крайней мере предоставить ему фикс для интеграции в базовый проект, чем потом при каждом апмерже проеврять, не поломалось ли из-за этого фикса что-то еще. Это конечно-же при условии довольно частых апмержей, что впрочем в нормальной практике случается гораздо чаще, чем полный отрыв форка от базового проекта.
Совет №56 весьма спорный в отношении C++.
В отличие от питона тут могут быть полезные классы чуть ли не вообще без методов. Например я предпочту использовать
std::chrono::durationвместоintдля хранения интервала времени.И так во многом. Конечно не надо впадать в крайности. Но это справедливо в обоих отношениях, как не надо делать "лишних" классов (когда они реально лишние), так-же не надо и стремиться к тому чтобы пытаться обходиться без классов, там где они все-же будут полезны.
Совет №57 тоже не бесспорный.
С одной стороны в сообществе есть консенсус, что учить C++ лучше по хорошим книгам. С другой стороны, люди все-же разные. Есть такие, кто усваивает информацию лучше из книг, есть кто лучше из аудио, есть кто лучше из видео, а есть такие, кому проще самому во всем разобратся начав писать код.
Ну т.е. как совет для большинства вроде и ок, но как безусловно "вредыный совет" для всех - не ок.
К сожалени, из опыта попыток использования
std::string_view, не очень оно и подходит. В большинстве случаев оказывается что либо чего-то не хватает (например конкатенации двух sv) без предварительной конвертации вstd::string, либо в какой-то очередной API надо передать именно string. Единственное где sv сейчас применять удобно, это всякого рода парсинг, когда можно сделатьremove_prefix()и/илиremove_suffix()без реаллокации.Начиная с C++17 есть
std::filesystem::path. Если этого не достаточно, то надо или искать подходящую библиотеку или писать самому.Трудно рекомендовать что-то конкретное, не зная конкретных требований.
Сдется мне, что кто-то накосячил. CGA был 4-х цветный, а не 16. Скорее всего там все-же EGA.
Ну фиг знает что там курят эти люди, но:
Откуда вы взяли этот бред? Из "настоящего" там максимум номер телефона и то нигде и никак не проверяется что он выдан именно на ваш паспорт.
Если речь про koboldcpp используйте параметр --threads. Память он есть по необходимости, только если попробовать модель побольше.
https://github.com/ggerganov/llama.cpp + https://github.com/ggerganov/whisper.cpp вам в помощь. И вообще, какое отношение имеют модели, к движкам на которых они могут крутиться? Это как-бы перпендикулярные вещи...
kobold по умолчанию использует количество потоков развное количеству физических ядер. Используйте параметр --threads чтобы поиграться с разными значениями.
В редми llama.cpp есть такая сравнительная табличка, правда не совсем понятно для какой именно модели:
Т.е. квантование не так сильно влияет, как уменьшению размера модели...
Я сам альпаку не пробовал, так что не уверен что не так. Но, для запуска на llma.cpp предлагают использовать следующий промпт:
Тут появилась еще новая модель: Koala. Кто-нибудь видел в формате для llama.cpp? А то обещают, что она получше предшественниц...
Можно попробовать просто позадавать хитрые промпты для начала. А насчет дообучения, если для вас 4-8 "A100 GPU-80GB" - это "домашние условия", то почему нет...
Вообще в этих моделях цензура настроена только на английский по-моему. По крайней мере, когда с ними общяешься по-русски, то он и про женщин шутит и даже про негров (пробовал викуну). Но конечно кочество ответов похуже, чем на английском...
Разница только в UI. llama.cpp - это консоль, а koboldcpp - это (если я правильно понял, не пробовал пока) web интерфейс. Но, движок там от той-же llama.cpp. Ну и само собой модели все те-же.
Конечно я это понимаю. Просто наверно не совсем удачно выразился. Я имел в виду не текущий момент, а скорее долгосрочную политику США в плане "ненавязчивого" PR себя везде и всегда.