levmkl, а как ты попал в нейронные сети? Знаешь есть анекдот как учитель 10 класса зашел во 2 й класс и 45 минут рассказывал детям про интегралы. Они такие молча кивали и писали. А потом в конце один спросил - а что это за буковка S вытянутая такая?...
Вобщем чтоб не вышло что щас зайдут такие себе учителя девопсы - типа подними кубер с терраформа а ты такой - ой всё )))
Есть мысль. Если появится успешный алгоритм который торгует, и он скорее всего будет продан
многим участникам рынка. При этом он внесет в торговлю свой собственный стиль, который тут-же
будет использован против него. Тоесть возникнет некая энергия противодействия. Как в природе
бывает и в генетике. Пустая ниша тут-же чем-то заполняется.
leremin, решил количество "жизней" в игре накинуть ? :) Эх ты. Мамкин ревес-инженер.
Смотри. Василий дело говорит. Константа может быть определена как в сегменте кода (text)
так и в данных. И способов задать ее - миллион. Она может быть получена кастингом из
целого числа. Из float. Кастингом из string. И вообще может быть расчетной. Тоесть как число Пи
например. Его можно вообще не знать но вычислить через Монте-Карло.
Поэтому - ищи в коде точку где константа первый раз используется. Там и будет ответ на твой вопрос.
Илья Лещенко, может тебе вообще не надо читать Алгоритмы? Я вот читаю ситуативно. Как только возникает вопрос.
Это не то чтение что ты лег на диван и за пару выходных загрузил себе в голову. Так можно Пелевина
читать. Но Алгоритмы ... их надо разбирать. И применять.- Ну тоесть я не вижу смысла их читать
по "приколу".
Илья Лещенко, ладно забей. Я все равно ничего не понял. :)
Чтение книжек и понимание алгоритмов это один скилл. Но написание кода
и использование ЭТИХ алгоритмов - это другой. И там еще - бездна
знаний которых у тебя нет. Зарегайся ради интереса на codewars
и попробуй порешать задачки.
Алгоритмы изучают разработчики не для эстетики а для применения.
Eugene-Usachev, был такой интересный проект Loom для Java. Вобщем была идея,
сохранив исходный код в виде классической мультизадачности на базе Thread, использовать
потоки на базе корутин или фиберов (я уж не помню точно). Сейчас он релизнулся или нет я не знаю.
Он как раз дает возможность запускать большое число потоков (2048) (которые в основном стоят в ожидании
какого-то события) но при этом не потребляют потоков ОС и не преключают контекст потока ОС каждые 20мс
как это делает линукс. Мне эта идея нравится. Она сохраняет структурное программирование
(вся бизнес логика в одном месте а не разбросана по всему коду как в асинхронщине).
В классическом (дефолтном) варианте даже 1000 потоков запускать - уже проблема. Т.к. они
ориентированы на интенсивные вычисления а не на ожидание событий notify или снятия локов.
Неправильные дизайны таблиц - это нормально. Идет эволюция. И аналитики на этапе проектирования
тоже могут всего не знать. Никто вообще не может дизайнить систему с нуля и до релиза. Всегда
идут пробы и ошибки.
Если будете делать нормализацию - сделайте ее в несколько фаз (мажорных релизов).
Например
Тоесть я как-бы говорю. Добавление дочерней таблицы - не деструктивно. Мы можем добавить
и старый софт будет совместим. Но попутно вы можете начать тестировать новый функционал
параллельно со старым. И это здорово. Потом когда все протестировано во второй фазе
вы убиваете поля из родительской таблицы.
Но это очень похоже на Blue-Green deployment только деплоймента нет а есть медленная эволюция
схемы.
Griboks, видимо у вас сработал эффект медленного поступления данных из источников. И имело смысл запускать 8 потоков. Да.
Файловая система вообще не обязана ничего писать до тех пор пока к ней не приходит
явный fsync. Где этот fsync стоит в вашем приложении - неизвестно. Но можно словить разные
эффекты от его применения. Слишком частые фиксации тоже вредны и это я ловил на запуске
записи логов в мультипоточке.
Владимир, я про такие проекты читал еще лет 10 назад в рунете. Я не спец в си-шарпе. Но мне кажется
что такие уже существуют. Для Java был Object Query Language (OQL) и он использовался кажется
в JVisualVm при анализе дампа памяти.
Владимир, я считаю что каждый программист хотя-бы раз в жизни должен написать свою DBMS.
Но это точно не формат вопроса в хабр. Это - блог длиной в несколько лет. И это репозитарий кода
в гитхабе. И для того чтобы разбираться в теме - тебе нужна своя грамматика SQL. Тоесть парсеры.
Нужно знать как работают оптимизаторы. Посмотреть для примера хотя-бы Apache Calcite.
Нужен выбор класса БД. Дисковая. Ин-мемори. Алгоритмы и структуры данных которые там
должны быть реализованы. И много-много обще-системных вопросов (мультипоточка и перформанс)
без которых этот софт не работает.
БД на хеш-таблицах или на коллекциях создает любой дурак но к сожалению дальше одного приложения
они не уходят. Кстати если вы делаете встраиваемую БД в C# то вам вобщем-то SQL не нужен.
Интеграция и ORM просто убивают идею SQL. Ведь идея идет гораздо дальше чем ООП и языки
разработки.
Я вам желаю удачи. Я тоже когда-то хотел писать свою DBMS (нишевую) для специальных кейсов.
Griboks, надо изучить вашу конфигурацию и вашу задачу. Я писал ETL процессы (I/O bounded задача) и понятное дело что на моем десктопе с 1 HDD не было смысла повышать степень параллелизма дисковых операций. Процесс в 1 поток работал обычно быстрее чем процесс в 2-3-4 потока.
Вобщем чтоб не вышло что щас зайдут такие себе учителя девопсы - типа подними кубер с терраформа а ты такой - ой всё )))