Смотрел раньше, ютьюб чрез VLC, на скорости 3.5 (видео открывалось по щелчку колёсиком), очень экономит время в обучающих и информационных видео. РуТьюб на телевизоре вообще не даёт изменять скорость, несколько месяцев назад просил в техподдержке, ответили отказом - разработчикам сообщать не будут и это не ошибка. (телек LG если что - в нашей стране распространённая марка). Пару раз приложение обновлялось за это время. VK - аналогично, хотя я был готов топить за любу платформу, предоставляющую подобную фичу.
Итого, видео, практически не смотрю, кроме 2 информационных каналов, и те только на компьютере. Те кто прокачал такой же скил меня поймут - смотреть "пьяюную жвачку", просто невыносимо! Добавьте скорости!!!
P. S. Пусть, даже это будет только в премиум подписке, но тогда уж до 4x.
Delphi, это так же FreePascal и Lazarus, вплне себе кроссплатформенные, поэтому имеет место, так же, размазывание контента, часть из которого вообще не учитывается.
Сложность измеряется от количества элементов, остальные метрики, могут быть только модификаторами. Выводя сложность от стороны, вы утверждаете что можете сделать за n^2 (цитирую: "N - Сторона матрицы") , где это соотвествует площади, то есть количеству элементов, а значит за 1 проход. Решение - в студию!
Что бы исключить из продолжения, смерть - не обязательна. Этот механизм и так работает у человека: у женщин яйцеклетки в ограниченном количестве, потенция у мужчин целенаправленно угнетается.
Когда я исследовал генетические алгоритмы, то всё было намного прозаичней. Генетический алгоритм, это широкий случайный поиск максимума, при этом встерчаются локальные максимумы, и если поиск на них не застревает, то у него есть шансы найти настоящий. Если же - нет, то амёбы так и будут плескаться в грязной луже.
Что при этом получалось: в популяции очень быстро нарастали особи с достаточно хорошим геномом, но при этом всего лишь локально хорошим, при этом они распространяли свои гены на всю популяцию. Особи, обладающие подавляющим количеством их генов, в целом, были очень плохи, но процентное содержание было настолько высоким, что скрещивание двух таких плохишей, удаляло гены, которые и отличали их от родителей. В итоге, вся популяция заполнялась клонами и никаких шансов выпрыгнуть из локального минимума - не было. Что бы повысить качество решения, пришлось с этим активно бороться: вводить особей с полностью рандомным геномом, но они не успевали мутировать, их потомки очень быстро оболванивались, далее, были запрещены близкородственные связи, это дало существенный толчёк.
Пользователи могут задать свои лимиты и отслеживать, насколько их устройство эффективно заряжается.
Не нашёл, где можно установить лимиты, я бы хотел ограничить потолок зарядки 80 процентами.
Меню настроек, это вообще сборная солянка, которое следовало бы назвать меню приложения, а не настроек.
График скачет, и не понятно, почему (похож на затухающий сигнал). То есть, показывает он бред или действительно что-то полезное, мне - не понятно.
Зачем мне знать скорость в процентах, мне тоже не понятно, тем более, что я всегда заряжаю только дома и только от одной зарядки. И это всё равно погода на Марсе, достаточно знать режим:10Вт, 40Вт, 60Вт. Более того, если уж речь о зараде в процентах, то судя по нелинейной скорости разряда батареи моего смартфона, подозреваю, что показывает смартфон мне напряжение, в процентах, из рабочего диапазона. А я бы хотел, знать количество энергии, как в аккумуляторе, так и при сокрости зарядки, что бы не заряжать аккумулятор, когда он начинает сосать по чайной ложке в час, тратя своё время, и не удивляться, что 20 процнетов аккума превратились в 1%, прямо на глазах. Ну и тогда бы я сам понимал, насколько быстро заряжается смартфон, так же как автомобилист понимает, по скорости движения, всё норм или нет. Такое впечатление, что все производители электроники и ПО сговорились, и такие: ну по тахометру скорость считайте, там много факторов. мы же не знаем, какая у вас передача и как сильно накачаны колёса, а обороты и в Африке обороты..
Попробуйте поискать японский бренд Kyocera, он вроде бы, тоже - загибается, но совсем недавно ещё выпускал телефоны, поэтому, они должны быть относительно современными.
pgTune - не открывается. Настройки Постгресса, сделали, размещён в системе виртуализации, как и MsSQL. Разница во времени выполнения запроса, по сравнению с MsSQL, на таблице с миллионом записей в 100 раз (2с vs 0.02с). План запроса - нормальный, индексы используется (запрос, элементраный, оптимизировать - нечего). Каким образом протестировать Постгресс, что бы можно было сказать, что он работает достаточно производительно на выделенных ресурсах или, что ресурсов не достаточно?
Разрешение лучше, ибо по 2к на каждый глаз в сумме даёт 4к и больше, что гораздо лучше впариваемых везде 1080 по вертикали.
"Руки" не нужны, прекрасно цепляются станадртыне органы управления.
Стол не нужен, я программирую лёжа в кровати с ноутом или беспроводной клавиатурой - очень удобно для тела, но не для шеи, возможность комфортно глядеь в потолок полностью разгрузить шею, и при этом иметь возможность быстро сменить положение на полусидячее или любое другое, мгновенно перенеся экран в удобное положение, это очень хорошая фишка.
Возможно, появятся массирующие проставки, давление - никуда не денется, зато появится омолаживающий и терапевтический эффект, дарю идею!
Воздействие на глаза, меня тоже очень беспокоит, пожалуй самый весомый пункт, будем ждать статистику.
На самом деле, фамильные деревья создаются не потому что хочется что-то узнать, а по той же причине, по какой разрешено иметь одну жену или мужа: наследование и переход имущества и прав. То есть это финасово-политический roadmap, при этом генетическое родство, по сути не имеет никакого значения, если доказано право. Наоборот, генетическое дерево, это попытка хакнуть эту систему, типа "незаконно рождённый сын из рода, происходящего от самого бога и людские законы ему - не указ". Вы же, делая дерево "родства" никак не поможете определить кто на что может претендовать.
А вариант: нагуляла, папа отрёкся, а настоящий отец не известен?
Женщины также имеют возможность отречься от своего ребёнка, в отличии о мужчин, не знаю, может ли при этом остаться только папа у ребёнка. В общем, я к тому, что фамильная связь и генетическая, это два разных дерева. И всяких нюансов может быть масса: хоть партогенез и не находит подтверждения у человека, зато химеризм и инцест - да.
>Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения.
Именно. Микроконтроллеры, где допустимы разные упрощения, это своеобразная ниша, для внедрения новой архитектуры, это мелковато.
>Только у мультиклеточной архитектурыпрограммный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде.
Только клетка, это не ядро, заявление из разряда: все регистры процессора доступны в полном объёме и в любой момент, для вычислений без обращения к памяти, а то что их надо постоянно сохранять и восстанавливать, для использования.. То же и с клетками: что толку, что они МОГУТ быть использованы, если в этот момент, они не доступны ни для какого кода, пока весь параграф полностью не будет выполнен? Если у вас ядро состоит из 16 клеток и на на этом ядре выполняется код, который требует всего 3 клетки, от этого ни жарко не холодно, потому что код, исполняемый на соседнем ядре и никакой другой тоже, не может использовать оставшиеся 13 клеток, более того, если конкретной процедуре нужно 256 клеток для исполнения, то он будет довольствовать лишь 16тью, а остальные ядра будут простаивать. Группировка клеток по ядрам, (по четыре клетки :-) ), хоронит саму суть Мультиклеточной архитектуры
Программа может использовать любое количество из 256 клеток, если это количество не более четырёх, ну - отлично!
Да, конечно, я не правильно использовал понятие потоков, подразумевалось, исполнение одновременно нескольких программ, у каждой хотя бы 1 поток, что недальновидно было сокращено до "многопоточности".
У мультирограммности, нет задачи полностью утилизировать ресурсы, а стоит задача именно одновременной работы нескольких программ. Если такой возможности нет, то вы вынуженны будете пользоваться своеобразными коммбайнами, где в текстовом редакторе, будет и проигрыватель и часы и браузер интернета, но при этом программист будет специалистом только по текстовым редкторам, а графического редактра, там не будет и в помине, поэтому, переодически, вам придётся этот комбайн закрывать и открывать графический редактор. Поэтому путь, когда программы узкоспециализированы, но при этом вынуждены работать независимо, это был естественный эволюционный, однако он порождает проблемы с распределением ресурсов.
Пример, с 4мя функциями, это то, как мультирограммность влияет на исполнение кода, а в современном качестве, к этому ещё добавляются всякие малые ядра и динамическое изменение частоты процессора. Но если вкратце, то имея в своём распоряжении 4 ядра, некую функцию, отрабатывающую, в среднем, за одно время и массив данных, то простейший алгоритм параллельной обработки, ничем не будет отличаться от развёртки цикла, мы просто запускаем по функции на ядро и ждём, когда они все отработают, после начинаем следующую итерацию, такой себе синхронный подход. Очевидно, что при мутипрограммности, время исполнения функции на одном ядре, перестаёт быть адекватно прогнозируемой величиной и мы вынуждены построить сложный планировщик процессов, а к нему внутрипрограммную обвязку из семафоров, приоритетов и т.п. И тут, мы вспоминаем, что есть такая вещь, как исполнение по готовности, причём, количество обслуживающих это действо клеток может меняться динамически. Тогда, возникает идея: выделит по 1 клетке на программу, и пусть уже не ОС, а сам процессор, по готовности, отдаёт оставшиеся клетки программам, при этом, если какие-то программы находятся в ожидании, а другой нужно много ресурсов, то именно она и получит их все.
Именно на это я и пытаюсь обратить внимание, что утилизация процессора одной программой, это хорошо, но компьютер общего назначения, это прежде всего мультипрограммный агрегат, а с этой точки зрения, мультиклеточная архитектура не несёт никаких плюсов, более того, клетки придётся объединить в ядра, а это значит, что отдельную программу уже не получиться выполнить на всех клетках процессора, то есть, если он имеет 256 клеток, но в ядрах по 4 штуки, придётся довольствоваться лишь 4мя при использовании механизма "по готовности", а всё остальное будет работать так же, как и в обычных процессорах с классическими ядрами, то есть, выгоды никакой не будет.
Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.
Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(
всегда на север, все страны всегда рисуются ориентированными на север,
Нет, в Австралии, не так.
Ваши аргументы похожи на спор о религии, но вы же понимаете, что карта была "вещью в себе" лишь в древности, и, может, в правилах было не только "на север", а и за случайно брошенный взгляд - ослепляли.
Если же говорить о картах, как о утилитарных вещах, то важны не они сами, а область их применения: плывёте по морю, из ориентиров только компас, не нужен маршрут, а только направление и от ветра зависит всё? Отлично, зафиксированная на север карта - ваш выбор, и вот, вы уже соотносите только курс с вертром и, фактически, пофиг на карту.
Идёте по сложной городской застройке, а экран смартфона - вытянутая дощечка? Вот вы и расположили свой путь, так что бы он максимально влезал в экран, что бы видеть все переходы и выделить ориентиры, которые бы, помогли не потеряться среди одинковых зданий, и вообще - можно ли там пройти или где срезать. Едете в метро (внезапно, ветки весьма сильно виляют, а не такие прямые как на карте) и хотите понять, в какую сторону вам выходить: располжите карту по ходу двжиения, и ваша задача - упростится.
Раньше, смотрел видео с Ютьюба, через VLC на 3x+ скорости, сейчас заменил lua на указанный вами, но ничего не изменилось: как затыкается каждую секунду, так и осталось.
Так что, приходится. как последнему тормозу, смотреть на 2x. Да и сам lua от февраля, когда статью-то готовили?
Автор гонит какую-то дичь. Во первых, в 1С8, у реквизитов есть ограничение типа, которое позволяет конкретизировать тип: Дата или ДатаВремя, поэтому любые запросы к базе данных будут типизироваться правильно.
Во вторых, автор вообще не понимает что такое типы, время в языке 1С дискретно поэтому 23.59.59, это всё равно что индекс 9 у массива из 10 элементов, у него нет никакого состояния конца 9го элемента или начала следующего, это конретный индекс.
В третьих, у ссылок, например, на документы, есть уникальный идентификатор, который можно считать ключём и если в массив по индексу 9 поместить пачку документов, то всегда можно их перебрать в порядке возрастания этого ключа, то есть выстроить в определённую последовательность и даже, это можно сделать с разными типами документов в перемешку (UIUD он такой). Но при этом доступ к этим документам, как было по индексу 9, так и остётся, очвидно, что как бы мы не перебирали элементы внутри пачки, на индекс 9 и его связь с пачкой это никак не влияет. Как показывает практика, порядок документов - важен и выборка пачки документов каждый раз в разном порядке, может сильно влиять на вычисления, поэтому в 1С дали возмоность с таким упорядочиванием работать, обозначив позицию в последовательности как момент времени, а ГраницаПериода всего лишь новый тип данных, который хранит одновремено два значения (Дата+UUID). Фактически, вместо примитивного типа, дали объект и методы работы с ним, но применимость у этого объекта весьма узкая, хоть и сильно упрощает многие моменты. Да в 1С много объектных фишек на уровне языка запросов, подобного SQL, но всё довольно примитивно. С введением, в новой платфоре, возможности работать с UUID в запросах, нет никаких сложностей полностью отказаться от момента времени и границы и сортировать "вручную" и резать последовательности по UUID, получая в точности тот же результат, но работая при этом раздельно со Ссылкой и с Датой. без всяких "непонятных" сущностей.
Статья типичного гумманитария, который познаёт цифровой мир через бесконеч-вечное и настолько преисполнился в своей мудрости, что готов изложить центральные концепции машины времени и вести нас в прекрасное будущее, которое наступит 1 января 4000 года .
В обращении они напоминают, что в 30-е и 40-е годы россиянам уже приходилось
Приходилось, это потому что - коммунисты, а свободные личности, спокойно до этого, себе работали по 8 дней и 1 день нихрена не делали. Тут, даже вводить ничего не надо, надо только - отменить, всё что навводили!
Нарушение целостности и целесообразность, это разные вещи. У вас есть таблица с 10 миллионами пользователей и табличка с данными привелеггий 8 вип персон. Связь 1 к одному. Но мы же чисто технически можем добавить в первую таблицу почти 10 миллионов нулов, построить индекс, что бы не идти фулсканом по 10 миллионам записям при проверке на вип персону, да, и будет - круто!
Ну, собственно говоря, причины появления camelCase не потому что это более удачная вещь, по сравнению со snake_case, чем PascalCase. Причины, в общем-то, лежат на поверхности: PascalCase решили немного кастрировать, для языков, где очень много слов начинающихся одинаково (например: get/set), в этом случае, строчные буквы переносят акцент на следующее слово, маскируя "однообразную" часть.
Смотрел раньше, ютьюб чрез VLC, на скорости 3.5 (видео открывалось по щелчку колёсиком), очень экономит время в обучающих и информационных видео. РуТьюб на телевизоре вообще не даёт изменять скорость, несколько месяцев назад просил в техподдержке, ответили отказом - разработчикам сообщать не будут и это не ошибка. (телек LG если что - в нашей стране распространённая марка). Пару раз приложение обновлялось за это время. VK - аналогично, хотя я был готов топить за любу платформу, предоставляющую подобную фичу.
Итого, видео, практически не смотрю, кроме 2 информационных каналов, и те только на компьютере. Те кто прокачал такой же скил меня поймут - смотреть "пьяюную жвачку", просто невыносимо! Добавьте скорости!!!
P. S. Пусть, даже это будет только в премиум подписке, но тогда уж до 4x.
Delphi, это так же FreePascal и Lazarus, вплне себе кроссплатформенные, поэтому имеет место, так же, размазывание контента, часть из которого вообще не учитывается.
Сложность измеряется от количества элементов, остальные метрики, могут быть только модификаторами. Выводя сложность от стороны, вы утверждаете что можете сделать за n^2 (цитирую: "N - Сторона матрицы") , где это соотвествует площади, то есть количеству элементов, а значит за 1 проход. Решение - в студию!
Что бы исключить из продолжения, смерть - не обязательна. Этот механизм и так работает у человека: у женщин яйцеклетки в ограниченном количестве, потенция у мужчин целенаправленно угнетается.
Когда я исследовал генетические алгоритмы, то всё было намного прозаичней. Генетический алгоритм, это широкий случайный поиск максимума, при этом встерчаются локальные максимумы, и если поиск на них не застревает, то у него есть шансы найти настоящий. Если же - нет, то амёбы так и будут плескаться в грязной луже.
Что при этом получалось: в популяции очень быстро нарастали особи с достаточно хорошим геномом, но при этом всего лишь локально хорошим, при этом они распространяли свои гены на всю популяцию. Особи, обладающие подавляющим количеством их генов, в целом, были очень плохи, но процентное содержание было настолько высоким, что скрещивание двух таких плохишей, удаляло гены, которые и отличали их от родителей. В итоге, вся популяция заполнялась клонами и никаких шансов выпрыгнуть из локального минимума - не было. Что бы повысить качество решения, пришлось с этим активно бороться: вводить особей с полностью рандомным геномом, но они не успевали мутировать, их потомки очень быстро оболванивались, далее, были запрещены близкородственные связи, это дало существенный толчёк.
Не нашёл, где можно установить лимиты, я бы хотел ограничить потолок зарядки 80 процентами.
Меню настроек, это вообще сборная солянка, которое следовало бы назвать меню приложения, а не настроек.
График скачет, и не понятно, почему (похож на затухающий сигнал). То есть, показывает он бред или действительно что-то полезное, мне - не понятно.
Зачем мне знать скорость в процентах, мне тоже не понятно, тем более, что я всегда заряжаю только дома и только от одной зарядки. И это всё равно погода на Марсе, достаточно знать режим:10Вт, 40Вт, 60Вт. Более того, если уж речь о зараде в процентах, то судя по нелинейной скорости разряда батареи моего смартфона, подозреваю, что показывает смартфон мне напряжение, в процентах, из рабочего диапазона. А я бы хотел, знать количество энергии, как в аккумуляторе, так и при сокрости зарядки, что бы не заряжать аккумулятор, когда он начинает сосать по чайной ложке в час, тратя своё время, и не удивляться, что 20 процнетов аккума превратились в 1%, прямо на глазах. Ну и тогда бы я сам понимал, насколько быстро заряжается смартфон, так же как автомобилист понимает, по скорости движения, всё норм или нет. Такое впечатление, что все производители электроники и ПО сговорились, и такие: ну по тахометру скорость считайте, там много факторов. мы же не знаем, какая у вас передача и как сильно накачаны колёса, а обороты и в Африке обороты..
Попробуйте поискать японский бренд Kyocera, он вроде бы, тоже - загибается, но совсем недавно ещё выпускал телефоны, поэтому, они должны быть относительно современными.
pgTune - не открывается. Настройки Постгресса, сделали, размещён в системе виртуализации, как и MsSQL. Разница во времени выполнения запроса, по сравнению с MsSQL, на таблице с миллионом записей в 100 раз (2с vs 0.02с). План запроса - нормальный, индексы используется (запрос, элементраный, оптимизировать - нечего). Каким образом протестировать Постгресс, что бы можно было сказать, что он работает достаточно производительно на выделенных ресурсах или, что ресурсов не достаточно?
Разрешение лучше, ибо по 2к на каждый глаз в сумме даёт 4к и больше, что гораздо лучше впариваемых везде 1080 по вертикали.
"Руки" не нужны, прекрасно цепляются станадртыне органы управления.
Стол не нужен, я программирую лёжа в кровати с ноутом или беспроводной клавиатурой - очень удобно для тела, но не для шеи, возможность комфортно глядеь в потолок полностью разгрузить шею, и при этом иметь возможность быстро сменить положение на полусидячее или любое другое, мгновенно перенеся экран в удобное положение, это очень хорошая фишка.
Возможно, появятся массирующие проставки, давление - никуда не денется, зато появится омолаживающий и терапевтический эффект, дарю идею!
Воздействие на глаза, меня тоже очень беспокоит, пожалуй самый весомый пункт, будем ждать статистику.
На самом деле, фамильные деревья создаются не потому что хочется что-то узнать, а по той же причине, по какой разрешено иметь одну жену или мужа: наследование и переход имущества и прав. То есть это финасово-политический roadmap, при этом генетическое родство, по сути не имеет никакого значения, если доказано право. Наоборот, генетическое дерево, это попытка хакнуть эту систему, типа "незаконно рождённый сын из рода, происходящего от самого бога и людские законы ему - не указ". Вы же, делая дерево "родства" никак не поможете определить кто на что может претендовать.
Кровное родство
Усыновление/удочерение
А вариант: нагуляла, папа отрёкся, а настоящий отец не известен?
Женщины также имеют возможность отречься от своего ребёнка, в отличии о мужчин, не знаю, может ли при этом остаться только папа у ребёнка. В общем, я к тому, что фамильная связь и генетическая, это два разных дерева. И всяких нюансов может быть масса: хоть партогенез и не находит подтверждения у человека, зато химеризм и инцест - да.
> Все это было реализовано в процессоре R1
Да, я тоже, надеюсь, что динамическая реконфигурация - спасёт "отца русской демократии"!
>Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения.
Именно. Микроконтроллеры, где допустимы разные упрощения, это своеобразная ниша, для внедрения новой архитектуры, это мелковато.
>Только у мультиклеточной архитектуры программный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде.
Только клетка, это не ядро, заявление из разряда: все регистры процессора доступны в полном объёме и в любой момент, для вычислений без обращения к памяти, а то что их надо постоянно сохранять и восстанавливать, для использования.. То же и с клетками: что толку, что они МОГУТ быть использованы, если в этот момент, они не доступны ни для какого кода, пока весь параграф полностью не будет выполнен? Если у вас ядро состоит из 16 клеток и на на этом ядре выполняется код, который требует всего 3 клетки, от этого ни жарко не холодно, потому что код, исполняемый на соседнем ядре и никакой другой тоже, не может использовать оставшиеся 13 клеток, более того, если конкретной процедуре нужно 256 клеток для исполнения, то он будет довольствовать лишь 16тью, а остальные ядра будут простаивать. Группировка клеток по ядрам, (по четыре клетки :-) ), хоронит саму суть Мультиклеточной архитектуры
Программа может использовать любое количество из 256 клеток, если это количество не более четырёх, ну - отлично!
Да, конечно, я не правильно использовал понятие потоков, подразумевалось, исполнение одновременно нескольких программ, у каждой хотя бы 1 поток, что недальновидно было сокращено до "многопоточности".
У мультирограммности, нет задачи полностью утилизировать ресурсы, а стоит задача именно одновременной работы нескольких программ. Если такой возможности нет, то вы вынуженны будете пользоваться своеобразными коммбайнами, где в текстовом редакторе, будет и проигрыватель и часы и браузер интернета, но при этом программист будет специалистом только по текстовым редкторам, а графического редактра, там не будет и в помине, поэтому, переодически, вам придётся этот комбайн закрывать и открывать графический редактор. Поэтому путь, когда программы узкоспециализированы, но при этом вынуждены работать независимо, это был естественный эволюционный, однако он порождает проблемы с распределением ресурсов.
Пример, с 4мя функциями, это то, как мультирограммность влияет на исполнение кода, а в современном качестве, к этому ещё добавляются всякие малые ядра и динамическое изменение частоты процессора. Но если вкратце, то имея в своём распоряжении 4 ядра, некую функцию, отрабатывающую, в среднем, за одно время и массив данных, то простейший алгоритм параллельной обработки, ничем не будет отличаться от развёртки цикла, мы просто запускаем по функции на ядро и ждём, когда они все отработают, после начинаем следующую итерацию, такой себе синхронный подход. Очевидно, что при мутипрограммности, время исполнения функции на одном ядре, перестаёт быть адекватно прогнозируемой величиной и мы вынуждены построить сложный планировщик процессов, а к нему внутрипрограммную обвязку из семафоров, приоритетов и т.п. И тут, мы вспоминаем, что есть такая вещь, как исполнение по готовности, причём, количество обслуживающих это действо клеток может меняться динамически. Тогда, возникает идея: выделит по 1 клетке на программу, и пусть уже не ОС, а сам процессор, по готовности, отдаёт оставшиеся клетки программам, при этом, если какие-то программы находятся в ожидании, а другой нужно много ресурсов, то именно она и получит их все.
Именно на это я и пытаюсь обратить внимание, что утилизация процессора одной программой, это хорошо, но компьютер общего назначения, это прежде всего мультипрограммный агрегат, а с этой точки зрения, мультиклеточная архитектура не несёт никаких плюсов, более того, клетки придётся объединить в ядра, а это значит, что отдельную программу уже не получиться выполнить на всех клетках процессора, то есть, если он имеет 256 клеток, но в ядрах по 4 штуки, придётся довольствоваться лишь 4мя при использовании механизма "по готовности", а всё остальное будет работать так же, как и в обычных процессорах с классическими ядрами, то есть, выгоды никакой не будет.
Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.
Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(
Нет, в Австралии, не так.
Ваши аргументы похожи на спор о религии, но вы же понимаете, что карта была "вещью в себе" лишь в древности, и, может, в правилах было не только "на север", а и за случайно брошенный взгляд - ослепляли.
Если же говорить о картах, как о утилитарных вещах, то важны не они сами, а область их применения: плывёте по морю, из ориентиров только компас, не нужен маршрут, а только направление и от ветра зависит всё? Отлично, зафиксированная на север карта - ваш выбор, и вот, вы уже соотносите только курс с вертром и, фактически, пофиг на карту.
Идёте по сложной городской застройке, а экран смартфона - вытянутая дощечка? Вот вы и расположили свой путь, так что бы он максимально влезал в экран, что бы видеть все переходы и выделить ориентиры, которые бы, помогли не потеряться среди одинковых зданий, и вообще - можно ли там пройти или где срезать. Едете в метро (внезапно, ветки весьма сильно виляют, а не такие прямые как на карте) и хотите понять, в какую сторону вам выходить: располжите карту по ходу двжиения, и ваша задача - упростится.
С чем вы вообще спорите?
Раньше, смотрел видео с Ютьюба, через VLC на 3x+ скорости, сейчас заменил lua на указанный вами, но ничего не изменилось: как затыкается каждую секунду, так и осталось.
Так что, приходится. как последнему тормозу, смотреть на 2x. Да и сам lua от февраля, когда статью-то готовили?
Автор гонит какую-то дичь. Во первых, в 1С8, у реквизитов есть ограничение типа, которое позволяет конкретизировать тип: Дата или ДатаВремя, поэтому любые запросы к базе данных будут типизироваться правильно.
Во вторых, автор вообще не понимает что такое типы, время в языке 1С дискретно поэтому 23.59.59, это всё равно что индекс 9 у массива из 10 элементов, у него нет никакого состояния конца 9го элемента или начала следующего, это конретный индекс.
В третьих, у ссылок, например, на документы, есть уникальный идентификатор, который можно считать ключём и если в массив по индексу 9 поместить пачку документов, то всегда можно их перебрать в порядке возрастания этого ключа, то есть выстроить в определённую последовательность и даже, это можно сделать с разными типами документов в перемешку (UIUD он такой). Но при этом доступ к этим документам, как было по индексу 9, так и остётся, очвидно, что как бы мы не перебирали элементы внутри пачки, на индекс 9 и его связь с пачкой это никак не влияет. Как показывает практика, порядок документов - важен и выборка пачки документов каждый раз в разном порядке, может сильно влиять на вычисления, поэтому в 1С дали возмоность с таким упорядочиванием работать, обозначив позицию в последовательности как момент времени, а ГраницаПериода всего лишь новый тип данных, который хранит одновремено два значения (Дата+UUID). Фактически, вместо примитивного типа, дали объект и методы работы с ним, но применимость у этого объекта весьма узкая, хоть и сильно упрощает многие моменты. Да в 1С много объектных фишек на уровне языка запросов, подобного SQL, но всё довольно примитивно. С введением, в новой платфоре, возможности работать с UUID в запросах, нет никаких сложностей полностью отказаться от момента времени и границы и сортировать "вручную" и резать последовательности по UUID, получая в точности тот же результат, но работая при этом раздельно со Ссылкой и с Датой. без всяких "непонятных" сущностей.
Статья типичного гумманитария, который познаёт цифровой мир через бесконеч-вечное и настолько преисполнился в своей мудрости, что готов изложить центральные концепции машины времени и вести нас в прекрасное будущее, которое наступит 1 января 4000 года .
Приходилось, это потому что - коммунисты, а свободные личности, спокойно до этого, себе работали по 8 дней и 1 день нихрена не делали. Тут, даже вводить ничего не надо, надо только - отменить, всё что навводили!
Нарушение целостности и целесообразность, это разные вещи. У вас есть таблица с 10 миллионами пользователей и табличка с данными привелеггий 8 вип персон. Связь 1 к одному. Но мы же чисто технически можем добавить в первую таблицу почти 10 миллионов нулов, построить индекс, что бы не идти фулсканом по 10 миллионам записям при проверке на вип персону, да, и будет - круто!
Ну, собственно говоря, причины появления camelCase не потому что это более удачная вещь, по сравнению со snake_case, чем PascalCase. Причины, в общем-то, лежат на поверхности: PascalCase решили немного кастрировать, для языков, где очень много слов начинающихся одинаково (например: get/set), в этом случае, строчные буквы переносят акцент на следующее слово, маскируя "однообразную" часть.