GotAI.NET

Форум: Проблемы искусственного интеллекта

 

Регистрация | Вход

 Все темы | Новая тема Стр.8 (9)<< < Пред. | След. > >>   Поиск:  
 Автор Тема: На: Здесь еще бывают программисты?
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 11 фев 22 17:28
Цитата:
Автор: Эгг
Мне не нужно решаться, консоль - это самый правильный i/o для AI задач.
Это потому что вы другие не пробовали! ))))

Уже несколько месяцев пишу веб-GUI для управления докерами на моем хостинге... В основе лежит тоже консольная строка с тысячами комбинаций применений на основе команды "docker ...". Например если мне надо выключить/выключить/перегрузить докер, я раньше запускал команду вывода списка включенных докеров, искал среди них мой, запоминал(выделением и копированием в буфер) его ID, потом писал команду перезагрузки с этим ID, а потом выводил списки еще раз чтобы убедиться что ничего другое не сломалось... Сейчас передо мной аккуратный список из моих докеров с кнопками в каждой строке. Нажал кнопку "перегрузить" - все вышеперечисленное "проходит под капотом", а я лишь отслеживаю как индикаторы в строках меняются. Причем в приятных CSS стилях с яркой анимацией(типа "медленно угасающего цветного шлейфа с легким дрожанием") чтобы успеть отследить явное (и возможно критичное) изменение (не раздражает, но глаз сразу ЗАМЕЧАЕТ что поменялось, на сколько и в какую сторону). Если надо, могу вывести графики изменений параметров, просмотреть небольшую историю изменений, пролистать журнал событий, поменять "подписки" на важные события (например если докер чаще 5 раз в час перегружался после ошибки - мне на почту/телегу собщение отправится)
...в результате, довольно тяжелый/"напряжный" пласт работ "девопса" свел к удобному, простому и понятному "пульту".

Сильно подозреваю что и вашу работу можно к подобному свести! Но одно из двух - либо "никто заморачиваться не хочет", либо это "священная традиция" из серии "если работает - не трогай" (как в анекдоте про "сын у папы программиста про Солнце спросил...")

Цитата:
Автор: Эгг
Все Nvidia'евские звуковые карты поддерживают CUDA, конфигураций рабочих может быть много, я тружусь на MS VS (где cpu'шные библиотеки на обычном C++17), а совместимость гарантируется как раз кудовским стандартом языка. На gpu можно считать любую математику, но лучше использовать такую, которая хорошо параллелится. Если нужно обрабатывать последовательные вычисления, то часто использует деревья в качестве шлюза, они и в ту и в другую стороную хорошо обрабатываются.
Спасибо большое!!!
А другие языки (кроме С++) CUDA поддерживает? Возможно трансляторы/транслитераторы в С++ с других языков. Например с GO, или паскаль?
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 11 фев 22 18:46
Изменено: 13 фев 22 12:24
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 11 фев 22 20:06
Цитата:
Автор: Эгг
На самом деле языки программирования начинаются и заканчиваются только одним языком. Если мы говорим о программировании, а не "имитации" его. Всё прочее либо для хардверных лабухов, либо для лабухов, занимающихся разной репрезентацией.

Спорно! (ИМХО, вы слишком "категоричны" - тенденции в IT быстро меняются, как и "стандарты") Почти весь корпоративный сектор сейчас построен на Java (банки, страховые, медицина, образование). БОльшая часть всего сектора ML насколько я знаю, все еще опирается на Питон. Не хилую часть сектора по администрированю линукс-серверов сейчас перевели вообще на go - не знаю сейчас ни одного современного проекта, не разворачиваемого на докерах. Новой тенденцией в последние 10 лет является переход на "автономные" и легко "размножаемые" (в облаках) микросервисы. А Нода просто напрашивается для создания малююююсеньких микросервисов с простой задачей.

По скоростям (многие делали замеры/сравнения) JS тоже не сильно уступает C++. В пределах 10%. Это не так критично в эпоху облаков и "переизбытка" ядер в домашних машинах и даже в телефонах... В моем телефоне 8 ядер, но сильно подозреваю что если я не в 3Д-играх, телефон использует хорошо если 2 ядра. Разбивка ЛЮБОЙ программы на "микросервисы" позволяет задействовать больше ядер, а значит сделать ее ЯВНО быстрее. Причем не нужно сидеть и заниматься "правильной состыковкой потоков"(через семафоры/мютексы), как делается в С++. И разработку каждого микросервиса можно отдать отдельной команде программистов, которые будут следить за ее надежностью.

...я всего 5 лет назад сменил язык разработки на JS (с Java). И сделал это не потому что заставили(раздражали ограничения). Сделал довольно большой анализ и рынков, и тенденций, и применений... Если искать работу, то PHP в разы популярнее чем C++! И всем плевать на то что PHP был написан на Си/С++. Всем важно чтобы струдник знал язык "более высокого уровня".

Понятно что (почти) все построено на С++, а С++ построен на асемблере... Но это не значит что есть смысл всем тыкать в "важность С++".

Интересная аналогия - где-то слышал что больше 30% веса человека занимают микроорганизмы и "автономные клетки". Они выполняют ВАЖНЕЙШИЕ задачи в оранизме - от переваривания пищи до работы в роли лейкоцитов и кровеносных телец. Но как часто мы в жизни об этом вобщее вспоминаем??? И умаляет этот факт ли для нас ценность врачей-специалистов по этой части организма?
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 11 фев 22 20:34

[Ответ][Цитата]
Сергей Гаврилов
Сообщений: 197
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 8:27
Цитата:
Автор: Tester64

По скоростям (многие делали замеры/сравнения) JS тоже не сильно уступает C++. В пределах 10%. Это не так критично в эпоху облаков и "переизбытка" ядер в домашних машинах и даже в телефонах...

Нет, 10% это не верная инфа, в среднем 50-100% оверхеда, на "чистых алгоритмах" 1 в 1, на "грязных", может быть и 200-500% но это уже зависит от самого алгоритма и использования встроенных средств(типов, данных, коллекций и тп.)

Но 50 -100% над Си, это на самом деле — очень круто, как для интерпретатора, разрабы очень постарались, по сравнению с питоном, где без использования специальных ухищрений(numpy масивов и тп.), на родных структурах данных оверхед будут в разы больший(500-10000%).
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 9:24
Изменено: 13 фев 22 12:24
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
+1
Добавлено: 12 фев 22 17:48
Цитата:
Автор: Сергей Гаврилов


Нет, 10% это не верная инфа, в среднем 50-100% оверхеда, на "чистых алгоритмах" 1 в 1, на "грязных", может быть и 200-500% но это уже зависит от самого алгоритма и использования встроенных средств(типов, данных, коллекций и тп.)

Зависит от задачи конечно, но обычно далеко не 50-100%!
Я КУЧУ тестов встречал.
Например это: https://habr.com/ru/post/151117/

Цитата:
----
Получаем результат:
JS result = 127.99999736028109
JS time = 127
Native result = 127.999997
Native time = 103

Разница минимальна. Увеличим количество итераций по осям в 8 раз. Получим следующие результаты:

JS result = 127.99999995875444
JS time = 6952
Native result = 128.000000
Native time = 6658
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 18:19
Цитата:
Автор: Эгг

Даже использование std вместо собственных объектов и процедур может снизить performance в разы, какая нахер жаваскрпт, чего смеяться. Есть такой класс задач, называется real-time, там вообще всё иначе, чем в вашем программировании юзверских морд и сценариев. Просто поверьте.
Поверю на слово...

Просто не сталкивался с подобным чтобы однозначно утверждать обратное!
Где-то читал (кажется на хабре) что мозг обрабатывает увиденное за 13 мсек.
Реалтайм - почти недостижим. Проще сделать НАДстройку над любым интерфейсом с некой "интерпритацией увиденного".

Например когда-то на форуме ЭтоЯ "первой темой для обсуждения" пытался обсудить тему "синестезии". Это редкое нейро-заболевание (чуть-ли не один на миллион) у кого мозг (по ошибке или в силу более глубокой индексации=связи нейронов) может увязывать к одной информации больше чувств - цвет и запах, цифру и цвет, ноту и цвет... Есть шикарная картинка - "найди цифру 2 среди 5". На одной картинке все одноцветные, а на другой одну "отличную" цифру покрасили красным на фоне черного. Результат находится не за 1-2 сек, а за миллисекунды.

...когда я обратил внимание про это заболевание (сериал "Библиотекри"), то активно задумался над переосмыслением интерфейсов в направлении "усиления и ускорения восприятия предварительной интерпретацией". Сейчас активно использую это в своей работе... (клиенты довольны)

Например, график всегда воспринимается "понятнее" чем столбик/таблица цифр.

Причем время, потраченное на "предварительную интерпретацию" обычно окупается...
В крайнем случае можно "выкинуть" пару промежуточных "кадров", если скорость не справляется. А если надо следить за быстро меняющимися цифрами - проще запустить "бегущий график" с цифрами.

Для текстовых логов тоже полезно ключевые слова цветом выделять. Иногда полезно многомерные отчеты по логам делать - бежит уже 1000я строка с блоком "addqod_00499", а рядом куча цифр - выведи в отдельный отчет "сейчас бежит блок addqod_00499, выведено уже по этому блоку 1000 строк, на этот блок уже потрачено 3.41 секунды, общее время работы 12.3 сек".
...и это лишь "стандартные патерны", которыя я использую к частым логам, "напряжным" для зрения. А есть еще и не стандартные - я их когда-то для андроид-разработки использовал - там вообще пришлось отдельный вьювер логов писать для огромного массива быстро бегущих логов(тогда еще на делфи).
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 18:33
Изменено: 13 фев 22 12:25
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 19:13
Цитата:
Автор: Эгг

При рейте 80 кадров и разрешении 4К так примерно и получается - около 10 мсек обработки на кадр. А вот для highspeed, где речь идет о 2КГц (1289х720, например) в такие требования уже не уложиться. Потеря промежуточных кадров - это не решение ))), а объективная реальность, помогает только буферизация и задержка по отношению к текущему времени. Если пара секунд есть, то очень хорошо, с такими условиями уже и кальман работает и другая оптимизация, но иногда и пары секунд нельзя.
Мы точно все еще о консоли говорим???? ))) 4К? 80 кадров???

Я о том что во время ОТЛАДКИ надо следить за консолью между "модификациями кода" в поиске ошибок или "не правильных результатов". В браузере есть своя консоль, в которую выводятся "события на реакцию пользователя(или на входящие данные)". Бежит себе "лента сообщений"... Если например запустить "реактор" на движение мышки - получим десятки сложных сообщений в секунду в "ленту консоли". Читать такое можно, но сложно. Ищу "смыслое ядро" в сообщениях и подсвечиваю нужное, вывожу в альтернативные/параллельные консоли, иногда в графики/отчеты. Не важное "отсеиваю" фильтрами.

Если это линукс-консоль, то чаще всего ее использую (еще и) для запуска программ "сложно-составными командами" для 2-10 раз это еще приемлимо, но для отладки/разработки, где это замеряется тысячами запусков, приходится укорять этот процесс (на порядки).

Если я правильно понял, вы РАБОТАЕТЕ в основном в консоли. Для меня "классическая" консоль - это серо-черное полотно с кучей букв и цифр... Как в таком можно ДОЛГО(постоянно) работать???
Не скучно? Не нудно? Мозги не плавятся от переизбытка лишних данных?
...Именно такую "консоль" я и пытаюсь максимально "адаптировать под задачу" и вынести в удобные UI.
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 19:18
Изменено: 13 фев 22 12:25
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 20:49
Изменено: 12 фев 22 20:50
Цитата:
Автор: Эгг
зачем мне что-то, кроме консоли для отладки.

Похоже мы на разных языках говорим! )) ИМХО, консоль - это жуткий примитив, который почти не развивается уже 50 лет. ИМХО, есть куча куда более удобных методик для отладки. Но вас все устраивает и вы не хотите ничего менять... Возможно я не достаточно хорошо знаю вашу специфику работы, но по моему опыту (автоматизатора), ВСЕГДА есть куда совершенствовать...

Например недавно узнал что у линуксового терминала в отличии от ДОСовского не 256 цветов, а больше 500... Уже хочу их получить то-же в винде, но пока не понял как это сделать. bash.exe в составе GIT вроде дает (почти) полноценную линукс-консоль и позволяет запускать все цвета из SH-файлов, но из Ноды их пока вызвать не получается.
https://i.stack.imgur.com/xjBuI.png
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 21:02
Изменено: 13 фев 22 12:25
[Ответ][Цитата]
Tester64
Сообщений: 1910
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 21:13
Цитата:
Автор: Эгг

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

Возможно для ВАШЕГО вида работ этого и хватает, а там где надо удерживать в голове сотни разных нюансов, приходится хоть как-то мозги "разгружать"... И иногда приходится проделывать ОГРОМНУЮ работу чтобы хоть на 5% снизить нагрузку на глаза и мозги и лучше сконцентрироваться на важных вещах в коде.

Иногда хочется освоить еще и такие виды цветов в консоли:
https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
(увы в ДОСе не работают, а в линуксе не выходит из Ноды генерировать - пока не понял почему - возможно где-то идет "прослойка" срезающая не стандартные спец-символы)
[Ответ][Цитата]
Вольфрамовый клaпaн
Сообщений: 13070
На: Здесь еще бывают программисты?
Добавлено: 12 фев 22 21:16
Изменено: 13 фев 22 12:25
[Ответ][Цитата]
 Стр.8 (9)1  ...  4  5  6  7  [8]  9<< < Пред. | След. > >>