Я понял, что вы хотите обсуждать свои абстрактные аналогии вместо обыденной физической реальности.
Давайте тогда прекратим переливать из пустого в порожнее, если до вас никак не дойдет, что какой бы гениальной диссертацией не была, у нее всегда будут ограничения и допущения и самое главное из них, это реализация в железе, которой обязательно требуется синхронизация доступа в том или ином виде.
И очень хорошо, так как я вам пишу про другое. "Если конкурентность перекладывается полностью на VM", то в языке действительно не нужна синхронизация, вот только это означает, что синхронизация отдается на откуп ВМ или ОС, но она никуда не девается, просто проблема синхронизации будет решаться на другом уровне.
Ваша аналогия про "отправку сообщения в вакуум" очень правильная в части упрощения понимая требований к синхронизации процессов при разработке программы на Эрланге. Она помогает программисту абстрагироваться от этой проблемы и сосредоточиться на прикладном алгоритме.
Но ведь в реальности эти сообщения отправляются не в космос или вакуум, а в какие-то структуры данных, только о них заботится не прикладной программист, а среда выполнения (виртуальная машина), которая в свою очередь крутится на реальном железе (на нескольких процессорах и/или потоках). А раз их несколько, то синхронизация требуется почти в любом случае, просто она реализуется не в прикладном приложении, а на уровень или два выше.
И вы опять пишите какие-то аналогии (ведь речь шла об асинхронности для пациентов).
В Эрланге нет синхронизации, но подумайте, каким образом реализуются очереди сообщений между приложениями? Это просто другой уровень абстракции, когда синхронизацию доступа убрали из языка, но она никуда не делась, а просто переместилась на уровень ОС.
Это точно такой же способ упрощения разработки программ, как и асинхронное программирование. Но ни синхронизация, ни управление ресурсами от этого никуда не деваются, просто в случае Эрланга синхронизация отдается на откуп ОС, а в при асинхронном программировании, формируется стейт машина внутри программы.
Аналогии всегда лживы. Если вы пишите про асинхронность, как про антоним синхронности, то забудьте про программирование, так как в нем всегда есть и ресурсы и контекст.
В вашем примере "Асинхронное параллельное выполнение: —››—, врачей много" требуется синхронизация доступа при многопоточном выполнении (ведь врачей много), тогда как отсутствие межпоточной синхронизации, это одна из самых важных особенность асинхронного программирования.
Асинхронное выполнение (в программировании), это именно про сокращение ресурсов и уменьшение трудоемкости при написании кода (программисту легче и понятней писать алгоритм, а стейт машину за него сделает компилятор автоматически).
преобразует это в конечный автомат (state machine)
Это может не только Rust. "Среда выполнения" - это и есть либо конечный автомат, либо нити, легкие потоки и пр. Конкретная реализация асинхронного выполнения зависит от языка и реализации системных библиотек.
Один обработчик не блокирует другой обработчик. Вместе они могут использовать один системный поток
Если несколько обработчиков используют один системный поток, тогда они друг друга именно блокируют (ведь выполняться может только один из них). Но переключаться между обработчиками в рамках одного системного потока можно очень быстро без переключения контекста.
Параллелизм и асинхронность, это теплое и мягкое и никак не связаны между собой.
Асинхронность, это вообще не про скорость, а про прерывание выполнения текущей задачи в конкретном месте, пока не будут доступны данные для обработки и увеличение скорости, это всего лишь следствие из-за более грамотного переключении контекста процессора между множеством задач из-за конкурентого доступа к более медленному ресурсу (у одной асинхронной задачи увеличения скорости не будет).
Мне кажется, что вы немного запутались и ничего ни в кого не превращается.
Асинхронность, это ручное переключение между внутренними потоками среды выполнения (задачами, нитями т.д.), тогда как параллелизм, это принудительное переключение между потоками ядра ОС (похоже на кооперативную и вытесняющая многозадачность).
И асинхронность не зависит от количества параллельных процессов, так как такие таски обычно выполняются в рамках одного потока ОС, чтобы экономить на переключении контекста и не требовалось использовать элементы межпотоковой синхронизации (хотя кажется С# ловил баги из-за await при переключении между своими внутренними потоками).
Асинхронность, это скорее всего, когда к одной или нескольким кофе машинам создается виртуальная очередь, но люди в ней не стоят, а продолжают заниматься своими делами и подходят за кофе только тогда, когда им приходит уведомление, что наступила их очередь.
Я уже отвечал, что все равно на статью по ссылке, т.к. взял верхнюю в поисковой выдаче. Мой комментарий к статье заключался в заданном вопросе, а не в мнении насчет первой попавшейся статьи.
Да пофигу на статью по ссылке. Я взял верхнюю в поисковой выдаче. Но если вам эта инструкция не понравилась, воспользуйтесь любой другой из того же результата поиска.
Ведь вопрос не в конкретной инструкции, а в том, зачем нужно создавать новый проект (со всеми возможными косяками и детскими болезнями), вместо того, чтобы настроить оригинальный XRay? И на этот вопрос, вы почему-то ответить не захотели.
Я понял, что вы хотите обсуждать свои абстрактные аналогии вместо обыденной физической реальности.
Давайте тогда прекратим переливать из пустого в порожнее, если до вас никак не дойдет, что какой бы гениальной диссертацией не была, у нее всегда будут ограничения и допущения и самое главное из них, это реализация в железе, которой обязательно требуется синхронизация доступа в том или ином виде.
И очень хорошо, так как я вам пишу про другое. "Если конкурентность перекладывается полностью на VM", то в языке действительно не нужна синхронизация, вот только это означает, что синхронизация отдается на откуп ВМ или ОС, но она никуда не девается, просто проблема синхронизации будет решаться на другом уровне.
Ваша аналогия про "отправку сообщения в вакуум" очень правильная в части упрощения понимая требований к синхронизации процессов при разработке программы на Эрланге. Она помогает программисту абстрагироваться от этой проблемы и сосредоточиться на прикладном алгоритме.
Но ведь в реальности эти сообщения отправляются не в космос или вакуум, а в какие-то структуры данных, только о них заботится не прикладной программист, а среда выполнения (виртуальная машина), которая в свою очередь крутится на реальном железе (на нескольких процессорах и/или потоках). А раз их несколько, то синхронизация требуется почти в любом случае, просто она реализуется не в прикладном приложении, а на уровень или два выше.
Гарантия доставки сообщения тут не причем.
Очереди сообщений у виртуальных машин. Вы же не думаете, что программа на Эрланг и в самом деле отправляет их в вакуум?
И вы опять пишите какие-то аналогии (ведь речь шла об асинхронности для пациентов).
В Эрланге нет синхронизации, но подумайте, каким образом реализуются очереди сообщений между приложениями? Это просто другой уровень абстракции, когда синхронизацию доступа убрали из языка, но она никуда не делась, а просто переместилась на уровень ОС.
Это точно такой же способ упрощения разработки программ, как и асинхронное программирование. Но ни синхронизация, ни управление ресурсами от этого никуда не деваются, просто в случае Эрланга синхронизация отдается на откуп ОС, а в при асинхронном программировании, формируется стейт машина внутри программы.
Аналогии всегда лживы. Если вы пишите про асинхронность, как про антоним синхронности, то забудьте про программирование, так как в нем всегда есть и ресурсы и контекст.
В вашем примере "Асинхронное параллельное выполнение: —››—, врачей много" требуется синхронизация доступа при многопоточном выполнении (ведь врачей много), тогда как отсутствие межпоточной синхронизации, это одна из самых важных особенность асинхронного программирования.
Асинхронное выполнение (в программировании), это именно про сокращение ресурсов и уменьшение трудоемкости при написании кода (программисту легче и понятней писать алгоритм, а стейт машину за него сделает компилятор автоматически).
Это может не только Rust. "Среда выполнения" - это и есть либо конечный автомат, либо нити, легкие потоки и пр. Конкретная реализация асинхронного выполнения зависит от языка и реализации системных библиотек.
Если несколько обработчиков используют один системный поток, тогда они друг друга именно блокируют (ведь выполняться может только один из них). Но переключаться между обработчиками в рамках одного системного потока можно очень быстро без переключения контекста.
Параллелизм и асинхронность, это теплое и мягкое и никак не связаны между собой.
Асинхронность, это вообще не про скорость, а про прерывание выполнения текущей задачи в конкретном месте, пока не будут доступны данные для обработки и увеличение скорости, это всего лишь следствие из-за более грамотного переключении контекста процессора между множеством задач из-за конкурентого доступа к более медленному ресурсу (у одной асинхронной задачи увеличения скорости не будет).
Мне кажется, что вы немного запутались и ничего ни в кого не превращается.
Асинхронность, это ручное переключение между внутренними потоками среды выполнения (задачами, нитями т.д.), тогда как параллелизм, это принудительное переключение между потоками ядра ОС (похоже на кооперативную и вытесняющая многозадачность).
И асинхронность не зависит от количества параллельных процессов, так как такие таски обычно выполняются в рамках одного потока ОС, чтобы экономить на переключении контекста и не требовалось использовать элементы межпотоковой синхронизации (хотя кажется С# ловил баги из-за await при переключении между своими внутренними потоками).
Это конкуренция, а не асинхронность.
Асинхронность, это скорее всего, когда к одной или нескольким кофе машинам создается виртуальная очередь, но люди в ней не стоят, а продолжают заниматься своими делами и подходят за кофе только тогда, когда им приходит уведомление, что наступила их очередь.
Мне вот такой больше понравился. Больше функционал (два настраиваемых таймера) и по габаритам значительно удобнее, чем кубическая форма
Вот только следует начинать с определения самого термина "интеллект"
Это вы про генеративные модели, что ли? Так это к интеллекту не имеет никакого отношения, так как у них детерминированный алгоритм выполнения.
А они вообще в принципе могу тренироваться на что-то новое, что отсутствует в датасете?
Понятно, чукча не читатель, а писатель.
Я уже отвечал, что все равно на статью по ссылке, т.к. взял верхнюю в поисковой выдаче. Мой комментарий к статье заключался в заданном вопросе, а не в мнении насчет первой попавшейся статьи.
Но ведь это же не помешало вам высказать собственное мнение вместо автора статьи на заданный ему вопрос?
Да пофигу на статью по ссылке. Я взял верхнюю в поисковой выдаче. Но если вам эта инструкция не понравилась, воспользуйтесь любой другой из того же результата поиска.
Ведь вопрос не в конкретной инструкции, а в том, зачем нужно создавать новый проект (со всеми возможными косяками и детскими болезнями), вместо того, чтобы настроить оригинальный XRay? И на этот вопрос, вы почему-то ответить не захотели.