Лёша, я знаю я немного псих в этом плане, но не мог бы ты сменить слово Thread в заголовке на слово Threads (т.е. сменить единственное число на множественное)? Дело в том, что в контексте обсуждения множественное число кажется намного более осмысленным.
Так прозвучало, причём не только с моей точки зрения — думаю, за это тебе и понаставили минусов.
Забей короче, спорить не о чем, скриншот у тебя клёвый. Я тоже болел в 1990е окнами, но у меня всё же не до того было всё запущено :)
Вот понимаешь, я смотрю на твою картинку и думаю про себя, что есть 2 типа кодеров. Даже не типа кодеров, а типа кодерского мышления, так что каждый кодер будет знаком с обоими способами думать.
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Спасибо, я примерно так и думал, но опасался что-то упустить из вида.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Довольно прикольно, но настолько актуальна именно «честная» многопоточность на спектруме? Все мои ядра начиная с Down по сути двухпоточные, в том смысле, что ядро может исполнять код (запирающий) в как бы основном процессе, а практически вся риалтаймовая визуализация сделана у меня обычно вызовом из прерывания, т.е. неким независимым тредом. То есть у меня совершенно обычное дело показывать эффект (в прерывании) и распаковывать что-то используя остатки времени во фреймах.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.
Schafft, спасибо, что не обижаешься, и ещё я очень рад тому, как ты пишешь о визуальности и сюжетности. Как человек текста, я обыкновенно пытаюсь делать это иначе, но вот эти твои слова — «не хотелось делать классику — эффект, текст, картинка, эффект, текст, картинка… и т.д.» — просто как бальзам для меня.
И, собственно, ценность критики, причина по которой я настырно пишу свои многабуквы, она как раз в том и заключается, что мне интересно пытаться объяснить, как-то фиксировать вот это всё невыразимое и непонятное. Понятно, что раз образы и ощущения у всех разные, — угодить всем и каждому невозможно, даже в теории. Но если критика удачная, она должна как бы дополнять произведение, делать его более трёхмерным, предлагать некий новый соблазнительный способ о нём думать. Делать невыразимое и непонятное чуть более понятным и выраженным.
Я написал это, в общем, для Nuts_ , но тут, в дополнении к комментарию sq , оно как-то уместнее смотрится.
DenisGrachev, развлекаться, что бы там не писали советские газеты — это нормально. Это правильно.
Поэтому, демы лучше делать из какого-то хорошего, уютного, позитивного места — демы как дети, любят тепло и ласку. Понятно, что по мере того, как кол-во часов необходимых для изготовления демо увеличивается, оставаться в позитиве делается всё труднее и труднее. Это и есть самый трудный аспект нашего ремесла.
В любом случае, не нужно их сажать в одно место. Во-первых, это сразу сделает видно, смотрят ли авторы или прогуливают. Во-вторых, это слишком уж сильно упрощает задачу поиска авторов, если зал внезапно решить бить морду!
В рамочку и на стенку :)
Хотя ты и перебираешь с этим, на мой личный вкус!
Забей короче, спорить не о чем, скриншот у тебя клёвый. Я тоже болел в 1990е окнами, но у меня всё же не до того было всё запущено :)
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Здорово что ты поднял эти вопросы на самом деле, прямо захотелось почитать немного теории по этому поводу. Чтобы поменьше велосипедов было.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.
Очень надеемся на продолжение :)
Я написал это, в общем, для Nuts_ , но тут, в дополнении к комментарию sq , оно как-то уместнее смотрится.
Поэтому, демы лучше делать из какого-то хорошего, уютного, позитивного места — демы как дети, любят тепло и ласку. Понятно, что по мере того, как кол-во часов необходимых для изготовления демо увеличивается, оставаться в позитиве делается всё труднее и труднее. Это и есть самый трудный аспект нашего ремесла.
Тем важнее не забывать, зачем это всё.