Да, помнится что после Voodoo1 все массово на Savage переходили. На радиаторах видюх даже вентиляторов не было, а на Pentium MMX уже ставили. А у AMD Duron уже башни были и DDR1. nVidia (тогда так писалась) еще делала чипсеты на материнки для AMD и Intel - nForce, что бы заработать.
Это MOE-модель, там через черточку указано число активных параметров A3B на каждый токен. А 27B - плотная модель. Для запуска 3.6-35b достаточна карта с 6Gb VRAM и 32Gb ОЗУ, нужные эксперты будут подгружаться в видеопамять в процессе генерации.
Не думали постепенно смотреть в сторону GraalVM? Генеративный Shenandoah в разработке и можно будет использовать в community edition. Еще из плюсов - интеграция с C и изоляты, со сборкой мусора и без. А в версии 25.1 добавили динамическую подгрузку и компиляцию классов (байткода) в режиме Native Image.
Да, это хорошая тема, но надо или через таймеры задержки включать, или термозащиту делать на симмистор, если Ардуино вдруг зависнет перед включением реле, если оно ими управляет напрямую.
Для того, что бы точно через 0, быстродействие реле должно быть на порядок выше 50 Герц. А с компенсацией механики - это уже оверинжениринг. Проще симмистор на большой радиатор посадить или к бочке с водой прикрутить.
Удобно иметь оборудование под рукой, поменял полки, линки еще что-то. Плюс, тянуть полосу через сотни КМ недешево и чревато обрывом линка. А внутри/между соседними ДЦ скорость может быть почти неограниченная и выдерживать SLA 99.99.
Вы точно также можете кастить экран, как видеопоток в mp4 или ts беря его из обрезанного фрейм-буфера как картинку. Кто-то даже X11 писал на js в браузере для случаев простых приложений, типа часов. Разрабы телеков специально все заворачивают на свои сервисы, если получится - Ок. Но как вы уже заметили, у всех свои нюансы, и универсальное решение сделать не просто.
Проприетарный (закрытый) софт всегда борьба меча и щита. Возможно, проще сразу hdmi донгл с андроидом взять от 1.5т.р. и кастить mkv в плеер без перекодировки, особенно, если все лежит на NAS.
Да, тут вся соль в многопоточности. Как локально кэшировать выделяемые объекты и как затем возвращать свободные - в глобальный пул. Лучше, чем это делают jemalloc и tcmalloc.
Зачем вшивать opengl32.dll в бинарник? Просто положите его рядом. Если, вдруг кому-то надо решить проблемы совместимости, он либо положит свой opengl32.dll, либо навесит hook на загрузку dll и пропатчит реализацию нужных функций.
При том, что если dll уже загружена, то страницы просто шарятся между процессами, через виртуальный адрес. Для чистоты эксперимента, можно было не считать те dll, что уже загружены Windows. Т.к. новой памяти они не потребляют.
GLM для удержания контекста имеет плотную формулу голов. Отсюда - большое потребление памяти необходимое для K-V кеша, и второе - это большое падение скорости при увеличении контекста (даже после 30-60К). Поэтому в гибридном (локальном) референсе почти не применима.
Проблема у всех аналогичных систем, что "жрут" в простое не мало ЭЭ. Видеодрайвер в режиме вычислений не дает уводить систему в сон хотя бы на ночь. В итоге КПД использования остается невысоким (при активной работе в пару часов). А летом – еще плюс и кондиционер, если лето жаркое. В общем, сон системе очень бы не помешал, и этот вопрос часто остается за кадром.
Было бы интересно сравнение с виртуальными потоками, которые даже с synchronized умеют работать и давно в основной ветке LTS. А так, осталась недосказанность в тесте.
Подход интересный, но на десктопе, наверное, уже проще Panama FFM использовать (Java 17+). Там можно передавать java-функции, как ссылки для upcall из нативного кода через MethodHandle. Классический пример с qsort с компаратором реализованный на java.
Байт-код почти явский, ахаха. Выделить виртуальную память и jit`атнуть туда код, вполне нормальный зрелый подход. Тем более, что MSVC уже давно поддерживает Clang, как альтернативный компилятор. Стало достаточно просто писать универсальный код, просто меняя названия функций (mmap на virtualalloc) в имплементации.
Да, помнится что после Voodoo1 все массово на Savage переходили. На радиаторах видюх даже вентиляторов не было, а на Pentium MMX уже ставили. А у AMD Duron уже башни были и DDR1. nVidia (тогда так писалась) еще делала чипсеты на материнки для AMD и Intel - nForce, что бы заработать.
Нужны большие бабки на сами чипы, ДЦ и исследования, пока только две экономики тянут.
Это MOE-модель, там через черточку указано число активных параметров A3B на каждый токен. А 27B - плотная модель. Для запуска 3.6-35b достаточна карта с 6Gb VRAM и 32Gb ОЗУ, нужные эксперты будут подгружаться в видеопамять в процессе генерации.
Не думали постепенно смотреть в сторону GraalVM?
Генеративный Shenandoah в разработке и можно будет использовать в community edition. Еще из плюсов - интеграция с C и изоляты, со сборкой мусора и без. А в версии 25.1 добавили динамическую подгрузку и компиляцию классов (байткода) в режиме Native Image.
Период синусоиды в пиком в 310V - 20мс, время реакции реле 10-15мс, какие 1 или -1V.
Да, это хорошая тема, но надо или через таймеры задержки включать, или термозащиту делать на симмистор, если Ардуино вдруг зависнет перед включением реле, если оно ими управляет напрямую.
Время включения реле - 10мс + 5мс на время дребезга контактов, вы просто не щелкните его контактами в момент 0.
Для того, что бы точно через 0, быстродействие реле должно быть на порядок выше 50 Герц. А с компенсацией механики - это уже оверинжениринг. Проще симмистор на большой радиатор посадить или к бочке с водой прикрутить.
Удобно иметь оборудование под рукой, поменял полки, линки еще что-то. Плюс, тянуть полосу через сотни КМ недешево и чревато обрывом линка. А внутри/между соседними ДЦ скорость может быть почти неограниченная и выдерживать SLA 99.99.
Вы точно также можете кастить экран, как видеопоток в mp4 или ts беря его из обрезанного фрейм-буфера как картинку. Кто-то даже X11 писал на js в браузере для случаев простых приложений, типа часов.
Разрабы телеков специально все заворачивают на свои сервисы, если получится - Ок. Но как вы уже заметили, у всех свои нюансы, и универсальное решение сделать не просто.
Проприетарный (закрытый) софт всегда борьба меча и щита. Возможно, проще сразу hdmi донгл с андроидом взять от 1.5т.р. и кастить mkv в плеер без перекодировки, особенно, если все лежит на NAS.
Еще бы Debian на нем запустить с usb wi-fi и X11.
Да, тут вся соль в многопоточности. Как локально кэшировать выделяемые объекты и как затем возвращать свободные - в глобальный пул. Лучше, чем это делают jemalloc и tcmalloc.
Зачем вшивать opengl32.dll в бинарник? Просто положите его рядом.
Если, вдруг кому-то надо решить проблемы совместимости, он либо положит свой opengl32.dll, либо навесит hook на загрузку dll и пропатчит реализацию нужных функций.
При том, что если dll уже загружена, то страницы просто шарятся между процессами, через виртуальный адрес. Для чистоты эксперимента, можно было не считать те dll, что уже загружены Windows. Т.к. новой памяти они не потребляют.
GLM для удержания контекста имеет плотную формулу голов. Отсюда - большое потребление памяти необходимое для K-V кеша, и второе - это большое падение скорости при увеличении контекста (даже после 30-60К). Поэтому в гибридном (локальном) референсе почти не применима.
Проблема у всех аналогичных систем, что "жрут" в простое не мало ЭЭ. Видеодрайвер в режиме вычислений не дает уводить систему в сон хотя бы на ночь. В итоге КПД использования остается невысоким (при активной работе в пару часов). А летом – еще плюс и кондиционер, если лето жаркое. В общем, сон системе очень бы не помешал, и этот вопрос часто остается за кадром.
Было бы интересно сравнение с виртуальными потоками, которые даже с synchronized умеют работать и давно в основной ветке LTS. А так, осталась недосказанность в тесте.
Подход интересный, но на десктопе, наверное, уже проще Panama FFM использовать (Java 17+). Там можно передавать java-функции, как ссылки для upcall из нативного кода через MethodHandle. Классический пример с qsort с компаратором реализованный на java.
Байт-код почти явский, ахаха. Выделить виртуальную память и jit`атнуть туда код, вполне нормальный зрелый подход. Тем более, что MSVC уже давно поддерживает Clang, как альтернативный компилятор. Стало достаточно просто писать универсальный код, просто меняя названия функций (mmap на virtualalloc) в имплементации.