OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 15 Июль, 2024 06:12

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 48 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 27 Декабрь, 2020 23:25 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2451
Откуда: Россия, Томск
Sergej Durmanov писал(а):
Александр Ильин писал(а):
Будете сравнивать, обязательно проверьте язык Julia.
не компетентен в julia, был бы готовый пример на этом яп, можно было бы сравнить с реализацие на ао.
Я вам дал пример, что дальше?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Март, 2024 05:29 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Александр Ильин писал(а):
Что-то я не понял. Я один бенчмарк реализовал, и на этом всё закончилось?
Даже замеры Активного Оберона не будут обнародованы?

Только что прогнал Вашу программу на Julia и программу выше на A2. Результаты удручающие:

Julia:
1024: 2,1 с
2048: 8,6 с

Active Oberon:
1024: 33 с
2048: 4 мин. 30 с

Дальше проверять не стал — слишком долго ждать. Кто сколько ядер загружал, я не знаю, но у меня их всего два.

Наверняка, если разобраться, выяснится, что Julia использует под капотом LAPACK на Фортране.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Март, 2024 08:41 

Зарегистрирован: Пятница, 11 Январь, 2019 21:33
Сообщения: 88
А не хотите попробовать cm3 Modula-3 ?

Есть LLVM13 ( на Debian точно).

Есть утилита m3swig.

Да, и готовый пример подключения откомпиллированного кода на Fortran


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Март, 2024 10:57 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1567
olenellus писал(а):
Александр Ильин писал(а):
Что-то я не понял. Я один бенчмарк реализовал, и на этом всё закончилось?
Даже замеры Активного Оберона не будут обнародованы?

Только что прогнал Вашу программу на Julia и программу выше на A2. Результаты удручающие:

Julia:
1024: 2,1 с
2048: 8,6 с

Active Oberon:
1024: 33 с
2048: 4 мин. 30 с

Дальше проверять не стал — слишком долго ждать. Кто сколько ядер загружал, я не знаю, но у меня их всего два.

Наверняка, если разобраться, выяснится, что Julia использует под капотом LAPACK на Фортране.


Она в теории может и на GPU считать. Всё же Julia и создана для такой работы, было бы удивительно, если бы низкобюджетный Оберон её бы обогнал на этом. Возможно, что на других видах задач Оберон будет быстрее за счёт прямой компиляции в маш.код и статической типизации. В задачах типа отрисовки пользовательских интерфейсов Ява выглядит бледно: написанная на яве IDEA гораздо медленнее по ощущениям, чем VSCode, в котором Электрон, в котором сразу генерируется машкод. И это несмотря на то, что в Яве тоже есть JIT, т.е. по способу ускорения выполнения кода они с Julia похожи друг на друга. А Javascript также динамически типизирован. Правда, в движке v8 тоже есть JIT и код дальше ускоряется, что усложняет картину.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Июнь, 2024 22:46 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Новые замеры.

Численное интегрирование 360 секунд эволюции системы уравнений химической кинетики (взаимодействие цепочек РНК), состоящей из 19 уравнений. Правые части квадратичны по переменным. Решение проводится явным методом Рунге-Кутты 45 с адаптивным шагом (производится согласованный расчёт методом 4го и 5го порядка, и из их разницы получается оценка на ошибку). Особая сложность состоит в том, что в одном из режимов (with heating) происходит кратковременная (меньше 10 секунд) смена температуры, переводящая систему в сильно жёсткий режим.

Алгоритмы либо одинаковы (обероновские версии с моей собственной реализацией РК45), либо являются почти дословным переводом обероновских версий с использованием специализированных библиотек для численного интегрирования. Все параметры, включая ограничения по абсолютной и относительной ошибкам, одинаковы для всех реализаций. Простая питоновская реализация использует метод RK45 из scipy.integrate в цикле. Рализация через solve_ivp использует у себя внутри тот же самый метод RK45, но уже без моего цикла. Реализации в Джулии DP5 и Tsit5 — это, как я понял, просто два разных варианта метода РК45 (разные выборы коэффициентов для промежуточных шагов). При этом при переходе в режим жёсткой системы Джулия ругается и предлагает использовать неявные методы. Реализация через AutoTsit5(Rosenbrock23()) как раз это и делает: она использует неявный метод РК45 до тех пор, пока не зафиксирует высокую степень жёсткости системы, после чего переключается на метод Розенброка (один из неявных методов Рунге-Кутты), и наоборот.

ББ и A2 работали с полным GUIем. Всё запускалось на Arch Linux 64x на одном ядре процессора (там, где это от меня зависело, но у меня их в любом случае только два на этой машине). При компиляции Офронт+ом не были выключены ни проверки (вывозил за диапазон и т. п.) ни сборщик мусора, дальнейшее компилирование в машинный код проводились при помощи gcc с флагом оптимизации -Os.

Вот результаты замеров:
Код:
360 s with heating:
Ofront+                     00m31.743s
BlackBox                    01m01.397s
A2                          02m52.718s
Python                      62m00.986s
Julia,DP5                   00m50.533s
Julia,Tsit5                 00m49.785s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.106s

360 s without heating:
Ofront+                     00m01.366s
BlackBox                    00m02.923s
A2                          00m06.431s
Python                      02m28.379s
Python,solve_ivp            02m27.186s
Julia,DP5                   00m17.944s
Julia,Tsit5                 00m16.917s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.098s

Что можно сказать? Офронт — чемпион. ББ неожиданно (для меня) держится неплохо, всего вдвое уступая по скорости. A2 заметно тормознее и уступает Офронту в 5–6 раз. Джулия на том же алгоритме ведёт себя на уровне ББ на сложной задаче, очень сильно теряя в производительности на простой (скорость хуже, чем у A2). На более оптимальном алгоритме Джулия показывает лучший результат в случае жёсткой системы, тогда как результат посредственный в простом случае. Более того, видно, что переключение на неявную схему позволяет легко преодолеть этот жёсткий участок, а основное время выполнения при этом набирается на простом участке (времена выполнения почти одинаковы без и с нагреванием). Про Питон помолчим. Грешно смеяться над больными языками.

Ещё замечу, что за время подготовки этих тестов A2 однажды намертво подвесила мою систему при перетаскивании мыши. ББ демонстрировал тормозючесть при промотке больших документов вверх (например, в отчёте по языку КП), а некоторые порты (окошки) изредка (пару раз было) переставали отвечать и закрашивались толстой полупрозрачной штриховокой.

Всем этим тестам я обязан настойчивым просьбам начальства переписать свои программы с Оберона на что-нибудь другое.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Июнь, 2024 19:35 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 302
Откуда: Russia
А где реализацию тестов посмотреть? Если Вы в АО использовали математические массивы, но как обычные - с поэлементным доступом, то производительности нет стоит ждать - там не прямой доступ, а через процедуры. В таком случае, нужно использовать обычные массивы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Июнь, 2024 21:47 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Это нельзя считать корректными тестами. Просто хотел поделиться однократными наблюдениями. Но если действительно интересно, могу прикрепить архив с исходными текстами (файлы слишком большие, чтобы вываливать их содержимое в текст сообщения). В АО я матмассивы не использовал. Реализация является копией реализации на Обероне-2 с обычными открытыми массивами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 05:45 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1236
olenellus писал(а):
ББ неожиданно (для меня) держится неплохо, всего вдвое уступая по скорости.

спасибо современным камням: для них реально не нужно особо стараться, чтобы получить более-менее быстрый код.

если не использовать real'ы — то ящик в среднем (по больнице ;-) проигрывает сишечке процентов на двадцать всего. при том, что CP2 не умеет даже в простейший CSE.

p.s.: кстати, у меня есть ещё такое подозрение, что можно чуть-чуть ускорить обращение к массивам, если инвертировать сторожей. потому что предсказатель на x86 по-умолчанию считает, что branch is not taken. из недостаков — трап покажет куда-то в космос вместо правильного места (потому что все трапы придётся собрать где-нибудь в конце процедуры).

с другой стороны — если мы обрабатываем массив в цикле, то предсказатель быстро прогреется. а для редких вызовов особого значения оно не имеет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 14:47 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Как видно, не всем это помогает в одинаковой степени. Но раз так, то надо бы указать тип процессора. Вот что выплёвывает /proc/cpuinfo:
Код:
processor   : 0
vendor_id   : GenuineIntel
cpu family   : 6
model      : 23
model name   : Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
stepping   : 10
microcode   : 0xa0c
cpu MHz      : 1071.622
cache size   : 3072 KB
physical id   : 0
siblings   : 2
core id      : 0
cpu cores   : 2
apicid      : 0
initial apicid   : 0
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow flexpriority vpid dtherm ida vnmi
vmx flags   : vnmi flexpriority tsc_offset vtpr vapic
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips   : 4789.32
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family   : 6
model      : 23
model name   : Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
stepping   : 10
microcode   : 0xa0c
cpu MHz      : 1063.850
cache size   : 3072 KB
physical id   : 0
siblings   : 2
core id      : 1
cpu cores   : 2
apicid      : 1
initial apicid   : 1
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow flexpriority vpid dtherm ida vnmi
vmx flags   : vnmi flexpriority tsc_offset vtpr vapic
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips   : 4789.32
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 15:02 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Кстати, реализация на Julia не была вполне эквивалентной остальным реализациям. На участках с постоянной температурой в остальных реализациях вычисление кинетических констант не проводилось на каждом цикле, тогда как на Джулии именно это и происходило (16 величин с плавающей запятой через линейные комбинации, деления и взятие экспоненты). Все мои наивные попытки предотвратить это путём заведения глобальных переменных или передачи массива предвычисленных величин через параметр только ухудшали производительность. Вот теперь наконец разобрался, как это делать менее наивно и более эффективно. Привожу результаты замеров с новой реализацией для Джулии: Отмена. Программа что-то не то считает. Значит, логика нарушена. Буду разбираться.

Нет, не разобрался. Получается только ухудшить, но никак — улучшить.


Последний раз редактировалось olenellus Четверг, 27 Июнь, 2024 15:45, всего редактировалось 5 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 15:03 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1236
с FPU всегда будет всё плохо: там куча load/store, которые довольно тормозные. те же load/store с обычными регистрами быстрее. предполагается, что современные компиляторы используют SSE-регистры, и общение с памятью оптимайзят. ящику, впрочем, никакой SSE без векторизатора не поможет. оптимизирующий компилятор на SSA мог бы — но это много возни ради довольно мизерного профита.

а вот почему Fox так отстал — непонятно. он — в теории — получше CP2 должен быть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 20:05 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 302
Откуда: Russia
olenellus писал(а):
могу прикрепить архив с исходными текстами
Да, интересно


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Июнь, 2024 21:59 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Пожалуйста! Инструкция внутри.


Вложения:
sources.tar.gz [18.35 КБ]
Скачиваний: 63
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Июнь, 2024 06:43 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 302
Откуда: Russia
Я мельком глянул файлы RK.Mod для АО и КП - и они делают немного разное. В КП просто копируются указатели, а в АО создается копия данных. Кроме того, в обоих файлах в GenerateK есть строки NEW(y0,L); y0 := Copy(ds.state), но в Copy снова создается массив в куче и затем присваивается y0.
В конце этой процедуры для КП строка ds.state := y0;, а для АО ds.state := Copy(y0).
Не знаю, насколько это влияет на производительность в целом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Июнь, 2024 06:59 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 302
Откуда: Russia
D MutualLigationContT.Md разные типы. Я пока не могу запустить тесты, так как нет компа под рукой. Но в коде АО используется SIGNED64, а в КП - INTEGER (32 бит).
Так же есть различия в передаче параметров - для одного языка стоит VAR, для другого - нет. Не существенно, но код разный.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Июнь, 2024 21:14 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Справедливые замечания. Специально для прояснения этого вопроса заменил в файлах для блэкбокса INTEGER на LONGINT повсеместно, где это возможно (оставил INTEGER только в параметрах вывода). Заменил тип переменной DynamicalSystem с указателя на запись на просто запись, как это реализовано в АО, везде в связанных процедурах, соответственно, переменная передаётся с флагом VAR, а создание записи через NEW удалено. Само это отличие было порождено тем, что Fox на меня выругался и не дал использовать указатель на запись при переносе программы с Оберона-2. И последнее, заменил строку ds.state := y0 на бывшее ds.state := Copy(y0), как это осталось в АО. Такая непоследовательность связана с тем, что я когда-то намучился, да так до конца и не разобрался, когда в разных Оберонах можно присваивать массивы напрямую, а когда нет. Отсюда вообще и появилась функция Copy. Но оказывается, в КП и сначала в Обероне-2 я в этом месте попробовал прямое копирование, и оно сработало, а я об этом забыл и не распространил везде в последовательной манере. В любом случае, теперь программы совсем эквивалентны. Блэкбокс с новым текстом выдал следующие результаты:
Код:
360 s with heating:
BlackBox                    01m03.954s

360 s without heating:
BlackBox                    00m02.662s

То есть эти различия никак не влияли на производительность.

На на самом деле там есть ещё одно отличие. Коррекция шага на КП и Обероне-2 происходит путём взятия степени 1/8 от квадрата отношения заданной ошибки к её оценки через функцию Math.Pow, тогда как в АО берётся степень 1/4 через двойной вызов Math.Sqrt (я не нашёл функцию степени произвольного показателя). Но это примерно вдвое снижает производительность. К тому же это ошибка, так как степень не та. Если в ББ заменить Math.Pow(…,0.125) на Math.Sqrt(Math.Sqrt(…)), то получаем:
Код:
360 s with heating:
BlackBox                    01m58.629s

360 s without heating:
BlackBox                    00m04.114s

Скажите мне, как посчитать степень в АО, и я переделаю замеры.

Кстати, если будете запускать программу Офронта+ и Питона через run…, не забудьте в теле этих run… поменять в последней строчке $program на ./$program, а то скрипт не найдёт исполняемый файл. Я забыл это поменять.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Июль, 2024 00:32 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
В реализации для АО поменял всюду SIGNED64 на SIGNED32, убрал Copy из указанной выше строчки и заменил на прямое присвоение, и, самое главное, заменил реализацию возведения в неправильную степени 1/4 через sqrt(sqrt(x)) на реализацию возведения в правильную степень 1/8 через exp(0.125*ln(x)) (так реализована, например, функция Power в модуле MathRe в A2). Результат, действительно, улучшился. Теперь табличка выглядит вот так (заменены времена только для A2):
Код:
360 s with heating:
Ofront+                     00m31.743s
BlackBox                    01m01.397s
A2                          01m29.138s
Python                      62m00.986s
Julia,DP5                   00m50.533s
Julia,Tsit5                 00m49.785s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.106s

360 s without heating:
Ofront+                     00m01.366s
BlackBox                    00m02.923s
A2                          00m04.145s
Python                      02m28.379s
Python,solve_ivp            02m27.186s
Julia,DP5                   00m17.944s
Julia,Tsit5                 00m16.917s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.098s


Теперь A2 лишь в полтора или менее раза отстаёт от ББ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 01 Июль, 2024 03:55 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1236
однако. а не надо ли фоксу явно говорить, чтобы он оптимизироваел? ну не может он быть настолько медленней CP2, мне кажется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Июль, 2024 21:31 

Зарегистрирован: Вторник, 12 Март, 2024 20:31
Сообщения: 25
Небольшое дополнение. Используя библиотеку Lib Роберта Кэмпбелла (из которой, по большому счёту, мне нужны были только два алгоритма: разложение матриц на верхне и нижнетреугольную и решение линейных уравнений с помощью этого разложения), реализовал вчера метод Розенброка (адаптивный неявный метод Рунге-Кутты порядка 2–3). Этот то, что Джулия в моих примерах использовала на жёстких участках. Как реализовать детектирование жёсткости, пока не знаю (исходники в Джулии — это какой-то кромешный ад, описание тоже не нашёл). Так вот, первая реализация была для Блэкбокса. Затем перенёс её на Офронт+ (благо, он поддерживает КП, так что адаптация была легче, чем с Оберона-2 в Блэкбокс). Сделал измерение времени на той же задаче, но с использованием неявного метода на участке с высокой температурой (при этом нагрев и охлаждения обрабатывались старым явным методом). Заодно проверил, как работает компиляция Офронтом+ без оптимизации (ключ оптимизации -O0).

В табличке ниже (являющейся обновлением табличек выше) меткой IRK отмечены реализации с неявной схемой, меткой -O0 — без оптимизации gcc.
Код:
360 s with heating:
Ofront+                     00m31.743s
Ofront+, -O0                00m47.332s
Ofront+, IRK                00m16.556s
Ofront+, IRK, -O0           00m23.680s
BlackBox                    01m01.397s
BlackBox, IRK               00m27.656s
A2                          01m29.138s
Python                      62m00.986s
Julia,DP5                   00m50.533s
Julia,Tsit5                 00m49.785s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.106s

360 s without heating:
Ofront+                     00m01.366s
Ofront+, -O0                00m02.079s
BlackBox                    00m02.923s
A2                          00m04.145s
Python                      02m28.379s
Python,solve_ivp            02m27.186s
Julia,DP5                   00m17.944s
Julia,Tsit5                 00m16.917s
Julia,
 AutoTsit5(Rosenbrock23())  00m16.098s

Как видно, с сишной оптимизацией удалось догнать Джулию на сложной задаче (на простой Джулия делает непонятно что). Производительность Блэкбокса стабильно в два раза отстаёт от Офронта+ с оптимизацией, почти не отставая от него же, но без оптимизации.

Затея с отключением оптимизации посетила меня после созерцания 8 секунд работы gcc по компиляции/линковке моей программы (так как не просто переписал нужные мне два алгоритма, а портировал с потерями LibVectors, LibIVectors, LibMatcices, LibIntegers, LibLongInts, LibReals) на фоне мгновенной компиляции в Блэкбоксе. Без оптимизации компиляция шла, действительно, быстрее, раз в пять. Но всё равно заметно.

(А меня всё равно настойчиво просят переписать всё на другой язык.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Июль, 2024 00:08 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 302
Откуда: Russia
arisu писал(а):
однако. а не надо ли фоксу явно говорить, чтобы он оптимизироваел? ну не может он быть настолько медленней CP2, мне кажется.
В фоксе сейчас нет оптимизации. Проблема, скорее всего, не в оптимизации, а в том, что в цикле производится вывод данных и в варианте для а2 используется медленная реалищъзация.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 48 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB