[10:40:06] <Kemet> в Win64 SIZE_T - 64 бита?
[13:47:41] <_valexey_> Kemet: а какая лицензия у А2?
[13:49:20] <_valexey_> FSF одобряет?
[13:51:27] <_valexey_> Kemet: size_t? Скорее всего. Зависеть от компилятора может.
[14:09:21] <Kemet> _valexey_: bsd like
[14:12:44] <Kemet> _valexey_: SIZE_T из винапи наверное
[14:13:19] <_valexey_> Kemet: а где файл и текст лицензии?
[14:13:58] <Kemet> _valexey_: есть в каталоге винаос, есть на сайте
[14:14:11] <_valexey_> Ok. Гляну
[14:14:16] <Kemet> но не все под бсд
[14:14:30] <Kemet> оберон под своей лицензией
[14:14:38] <Kemet> часть модулей под гпл
[14:15:33] <Kemet> _valexey_: вот тут этот сайзт https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
[14:16:25] <_valexey_> Gpl норм
[14:17:33] <Kemet> под гпл какието сторонние прилады только, да не нужна эта гпл
[14:18:53] <_valexey_> Оберон - не активный, классическая необязательная подсистема?
[14:19:44] <Kemet> да
[14:21:40] <_valexey_> Ok. Значит остается bsd и gpl
[14:21:49] <_valexey_> ЭТо ок
[14:25:48] <Kemet> эээ, наверное модули, портированные с оберона так и остаются под обероновской лицензией
[14:27:23] <Kemet> но помойму старай обероновская лицензия тоже бсдподобная, но точно не помню
[14:31:02] <_valexey_> Хм. Все сложно
[14:31:24] <_valexey_> Мне важно совместима лицензия с gpl или нет
[14:31:43] <_valexey_> То есть можно ли в gpl конвертануть
[14:38:48] <Kemet> ETH Bluebottle (formerly Aos)
Copyright (c) 2008, Computer Systems Institute, ETH Zurich
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the ETH Zurich nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
[14:39:22] <Kemet> This is a compilation of the
- ETH WinAos System (Windows Emulation of the Active Object System, aka A2)
and
- the software packages Voyager and AntsInFields.
Nearly all parts of this compilation belong to the ETH WinAos System, exceptions are the files of "AntsInFields" and "Voyager"
----
Oberon is the name of a modern integrated software environment. It is a single-user,
multi-tasking system that runs on bare hardware or on top of a host operating system.
Oberon is also the name of a programming language in the Pascal/Modula tradition.
The Oberon project was launched in 1985 by Niklaus Wirth and Jьrg Gutknecht.
See also http://www.oberon.ethz.ch
Voyager is a project to explore the feasibility of a portable and extensible system
for simulation and data analysis systems. It is mainly written in and for Oberon.
The Voyager project is carried out by StatLab Heidelberg and was launched
in 1993 by Gьnther Sawitzki.
See also http://www.statlab.uni-heidelberg.de/projects/voyager/
AntsInFields is a Software Package for Simulation and Statistical Inference on Gibbs Fields.
AntsInFields is written in Oberon and uses Voyager. It has been developed since 1997
by Felix Friedrich.
----
Voyager is - in this distribution - located in the directory "Work/vy"
Source code of Voyager is marked by preceding "vy" for all Module-Names
AntsInFields is - in this distribution - located in the directory "Work/ants"
Source code of AntsInFields is marked by preceding letters "ants" for all Module Names.
----
The WinAos System is protected by the following copyright, start and end marked by ">>" and "<<" respectively:
>>
ETH Bluebottle
Copyright (c) 2002-2008, Computer Systems Institute, ETH Zurich
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the ETH Zurich nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<<
----
The following copyright note (start and end marked by ">>" and "<<" respectively)
concerns either of the software packages
Voyager
(C) 1993-2002 Project Voyager, StatLab Heidelberg ; (C) 1993-2002 G. Sawitzki et al.
and
AntsInFields
(C) 1997-2002 Felix Friedrich, Munich:
>>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
<<
the copy of the LGPL can be found in this directory as file "LGPL.TXT"
[14:43:20] <_valexey_> Thx
[14:44:53] <Kemet> но в gpl думаю нельзя и не надо
[14:45:40] <_valexey_> Почему нельзя? Где запрет?
[14:48:21] <_valexey_> Bsd совместима с gpl в этом смысле
[14:48:24] <_valexey_> Обратно вот уже нельзя будет, да.
[14:50:48] <Kemet> поэтому и не надо херней страдать и плодить форки с разными несовместимыми лицензиями
[14:51:16] <Kemet> распространяется под бсд-лавйк и норм
[14:51:18] <_valexey_> Нежизнеспособное само сдохнет
[14:52:15] <_valexey_> Но мне важна принципиальная возможность.
[15:31:35] <_valexey_> Вообще, gpl форк всяко лучше, чем проприентарный.
[15:33:50] <_valexey_> Пилимый не публично.
[15:42:48] <_valexey_> ver
[15:42:55] <_valexey_> Version
[15:43:01] <_valexey_> version
[15:43:02] <Жаба> _valexey_, you have Talkonaut 5.95 on iPhone 7.1.2
[16:10:35] <Kemet> _valexey_, Ты Феликсу писал?
[16:11:06] <_valexey_> Нет исчо.
[16:11:54] <_valexey_> Там когда эта фигня происходит, до кучи пачка сигналов приложению прилетает, судя по gdb
[16:13:40] <Kemet> Там в двух местах проблемк в хипе и в массивах и проявляется когда адрес или размер больше некоторого значения
[16:14:21] <_valexey_> Ну, с хипом проблему ясно видно даже если массивы мелкие.
[16:14:39] <_valexey_> А как проблему с большими массивами увидел?
[16:15:10] <Kemet> У меня на 7000 зависает инициализация
[16:16:16] <_valexey_> То есть я систему убивал просто много раз (руками, не прогой) делая NEW(A), где A - массив мегабайт 10-20.
[16:16:53] <Kemet> Причем на первом массиве, начальный адрес которого норм
[16:17:01] <_valexey_> Причем ясно же что поскольку я инициалищирую одно и то же, в памяти просто много мусора.
[16:17:24] <_valexey_> Kemet: это у тебя и на винде так?
[16:18:24] <Kemet> _valexey_, Только на винде, натива под рукой нет нового
[16:18:33] <_valexey_> Матрица с на 7000 это что-то около 400 метров.
[16:18:48] <Kemet> _valexey_, Да
[16:18:58] <_valexey_> Возможно просто непрерывного куска памяти найти не может такого размера.
[16:19:27] <_valexey_> Но это не повод виснуть, это повод для исключения, или что там в Аос вместо них.
[16:19:40] <Kemet> _valexey_, Оно выделяет, виснет на a := 10
[16:19:55] <_valexey_> Ну, вдруг ты unixaos попробовал
[16:20:14] <_valexey_> Ыыы.. Странно.
[16:21:12] <_valexey_> Что-то ломается.
[16:21:30] <_valexey_> А отладчик в A2 бывает? Пошаговый :-)
[16:22:01] <Kemet> Угу, три массива на 7000 норм выделяется
[16:23:44] <Kemet> в паблике нет
[16:23:54] <_valexey_> Всем нужен пошаговый отладчик!
[16:23:58] <_valexey_> Жаль.
[16:24:52] <_valexey_> Еще в IDE там забавно - если капсовый модуль, то подсветка есть, а если все мелкими буквами, то нет.
[16:25:05] <Kemet> какое-то поделие есть но скорее он не пошаговый, а просто на посмотреть стек вызовов как в трапах, ноя не смотрел и папиров нет
[16:25:07] <_valexey_> Хотя должно бы быть наоборот :-)
[16:26:06] <Kemet> _valexey_: просто текущий хайлайтер туповатый, я так понял ктото новый пилил, универсальный
[16:26:38] <_valexey_> В паблике опять нет?
[16:28:29] <Kemet> я думаю опять по заказу или семестровая может и появится - тот недоотладчик что залили тоже студенчекая работа
[16:29:03] <_valexey_> Жуть!
[16:29:09] <Kemet> ну феликс чтото правил, для унихайлатера
[16:29:19] <Kemet> сейчас он тукпо один
[16:29:29] <_valexey_> Вообще, ощущение, что по крайней мере unixaos никто не использует.
[16:29:31] <Kemet> а будет много хайлатеров
[16:29:36] <Kemet> красивых и разныхз
[16:29:51] <Kemet> теперь же там еще и недошарп есть, а подстветки то нет!
[16:29:59] <_valexey_> Иначе такие баги пропустить просто невозможно.
[16:30:21] <_valexey_> При регулярном использовании.
[16:31:19] <Kemet> возможно, что проблема связана только с выдеклением и инициализацией шматка памяти для матмассивов, и их врядли в юниксаос юзают
[16:31:36] <Kemet> надо попробовать обычные динмассивы
[16:31:48] <_valexey_> А как обычный массив объявить?
[16:33:18] <_valexey_> У меня оно виснет без всяких умножений матриц. Просто когда хип исчерпывантсч.
[16:35:26] <Kemet> у меня простой динмассив 10000 один выделило нав втолром также зависло,, а мат массив вроде 7500 тока былоо
[16:35:58] <_valexey_> А как выделить простой?
[16:35:59] <Kemet> _valexey_: POINTER TO ARRAY OF ARRAY OF LONGREAL
[16:36:10] <Kemet> NEW(a,n,n)
[16:36:19] <_valexey_> А, поинтер. Ок
[16:38:08] <_valexey_> А когда лучше обычными пользоваться?
[16:38:34] <_valexey_> То есть какие недостатки у математических?
[16:39:00] <Kemet> vfn vfccbds nzyen dytiy.. kb,e
[16:39:11] <Kemet> мат массивы тянут внешнюю либу
[16:39:31] <_valexey_> Какую? Я ничего не импортировал
[16:39:57] <Kemet> если не нцжны мат операции лучше стандартными обероновскими массивами статиками и динамическими
[16:40:17] <Kemet> _valexey_: это магия компилятора!
[16:40:53] <Kemet> ты же не импортируешь хип, но new можешь использовать!
[16:42:05] <Kemet> причем математические сначала грузят либу расширения а потом оптимизированную перегруженную либу!
[16:42:24] <Kemet> гдето они нужны гдето нет
[16:43:08] <Kemet> а мат массивов есть инициализаторы, включая констаты, а у стандартных нету (
[16:43:39] <Kemet> у мат массивов есть перегрузка операций, а у стандартных нету
[16:45:12] <Kemet> мат массивы можно описать как объект, который будет вести себя как мат массив Например A = OBJECT (ARRAY [*] OG CHAR)
[16:46:27] <Kemet> не, мат массивы также на 1000 норм первый выделяет на втором виснет
[16:46:33] <Kemet> 10000
[16:46:57] <Kemet> впринципе и больше выделяет для одного, проблема в том что виснет
[16:47:11] <Kemet> ну тут понятно почему
[16:47:33] <Kemet> Heaps же не может в KernelLog писать )
[16:48:23] <Kemet> оно пишет в Trace
[16:54:24] <Kemet> и в трасе видно что срабатывает ASSERT
[16:57:34] <Kemet> при попытке хапнут у системы памяти
[17:09:26] <_valexey_> А какой ассерт то?
[17:12:23] <Kemet> ade#0
[17:12:28] <Kemet> adr
[17:13:56] <Kemet> причем если шматки под массивы норм выделились, то при инициализации создается еще кеш и вот тут то и происходит обломов - тожке при запросу у системы
[17:15:55] <_valexey_> А за какую функцию хост-систему там дергают?
[17:16:15] <_valexey_> Эта функция нуль возвращает?
[17:16:25] <Kemet> Machine.ExpandHeap
[17:17:17] <_valexey_> Это понятно, это на обероне писано, то есть. састь гостя, а хост-системы какую функцию?
[17:17:24] <Kemet> не, в процессе запроса у системы
[17:18:03] <Kemet> ну у винды VirtualAlloc
[17:18:37] <_valexey_> Гм. И вот оно то нуль и возвращает?
[17:19:08] <Kemet> dblbvj? nen cvjnhtnm tot yflj? yj gjcktlytt cjj,otybt d nhfct nfrjt b fllhtcc nfv yekm
[17:19:08] <_valexey_> А где лог этих ассертов глянуть? В unixaos я не нашел такого файла.
[17:19:23] <Kemet> хз где в юниксаос
[17:19:42] <_valexey_> А в винде?
[17:19:57] <_valexey_> Думаю вайн поставить и виндоверсию погонять.
[17:20:00] <Kemet> там где экзешник
[17:20:13] <Kemet> systemtrace*
[17:20:14] <_valexey_> Файл как зовется?
[17:20:17] <_valexey_> Ок
[17:21:16] <_valexey_> Надо будет таки в сырцы глянуть подробнее
[17:21:26] <_valexey_> Благо они тут в нормальном формате.
[17:27:37] <Kemet> ну в общем да, от винды возвращается 0
[17:33:17] <Kemet> причем 0 там после двух попыток
adr := Kernel32.VirtualAlloc(initVal, memBlkSize, {Kernel32.MEMCommit, Kernel32.MEMReserve}, {Kernel32.PageExecuteReadWrite});
IF adr = NilVal THEN (* allocation failed *)
adr := Kernel32.VirtualAlloc(NilVal, memBlkSize, {Kernel32.MEMCommit}, {Kernel32.PageExecuteReadWrite});
END;
[17:35:34] <Kemet> _valexey_: вобщем тебе не Феликсу надо писать
[17:44:04] <_valexey_> А кому?
[17:44:24] <_valexey_> Вообще, кто подобной системщиной там занимается?
[17:45:54] <_valexey_> Если в юнихаос бы подобную диагностику добавить и расковырять... Впрочем, думаю все решабельно.
[17:52:03] <Kemet> _valexey_: юниксаос вроде Гюнтер занимается
[17:52:16] <_valexey_> А вынь?
[17:52:20] <Kemet> этп дипгоностика должнаа быть везде
[17:52:29] <Kemet> _valexey_: Феликс
[17:52:35] <_valexey_> Ибо похоже что в этих багах есть нечто общее.
[17:53:35] <Kemet> _valexey_: открой Glue.Mod там чтото про трассировку должно быть может просто отключсено
[17:54:39] <_valexey_> Ok. Гляну. Но наверно уже завтра. А то тут основные задачи меня сейчас зохавают.
[17:54:59] <Kemet> не, нету
[17:55:18] <Kemet> есть переменная debug, но ее ключи не описаны там
[17:56:30] <Kemet> _valexey_: возможно, что в юниксаос трасер пишет в домашниё каталог или еще куда, может просто поиск типа SystemTrace*
[17:57:15] <_valexey_> А может и в линуксовый лог пишет, кстати. Надо глянуть.
[17:59:23] <Kemet> ибо в модулях вывод трассировочной инфы есть
[18:01:03] <Kemet> и кстати в а2 есть такая замечательная штука - реплей трассы
[18:01:50] <_valexey_> Ы?
[18:06:26] <Kemet> файл с системтрасе на другой машине можно "проигратьт" и воспроизвести результат
[18:15:01] <Kemet> Или не сисьемтрасе а трап, не помню
[18:26:55] <Kemet> _valexey_, Я не вижу в юниксаос настроек вывода трассы в файл
[18:34:51] <Kemet> Такая штука только в винаос, в нативе экран компорт
[19:02:20] <Kemet> _valexey_, Если я убираю ассерт то а2 пытается несколько раз запросить память у хоста, после чего трап аут оф мемори. вобщем винда память не отдала, её нету - всего 2 мб осталось
[19:20:24] <vlad2> /me погружается в код до-2003 года...
[19:22:28] <Kemet> бгг в а2 добавили декодер блекбоксовского стандарного пакера, уж не надумали ли лни портировать бб под а2?
[19:26:21] <vlad2> Такой типичный "ООП" - 1 класс с мильеном методов.иТипич
[19:30:04] <Kemet> vlad2: угу вот тоже недавно смотрел на дельфе - почтии 1,5 методов, причем это вообще синглетон был, нах там классы
[19:30:16] <Kemet> 1,5к
[19:31:05] <vlad2> Ужос :) Не генеренный?
[19:31:18] <Kemet> не
[20:49:23] <_valexey_> Kemet: это в винде осталось 2 мб или в аос?
[20:57:29] <Kemet> _valexey_: в винде
[20:57:46] <_valexey_> Хы. Где смотрел?
[20:58:00] <_valexey_> У тебя сколько рамы вообще?
[20:59:23] <Kemet> _valexey_: эээ, у мну вин32, 3гб, юзерспейс же все равно максимум 2гб, за минусом сколькототам
[21:00:00] <Kemet> смотрел в в Диспетчер-Быстродействие
[21:00:16] <_valexey_> Это да. Но у тебя валился аллок когда было скушано уже около 2 гиг?
[21:00:34] <Kemet> да
[21:00:47] <_valexey_> Если да, то это скучно и совсем не так как падает unixaos
[21:00:56] <Kemet> я брал 6500, запускал - норм
[21:01:51] <Kemet> потом повторно - выделение под массивы норм, но при умножении тампод кеш запрашивается, а памяти нету
[21:01:58] <_valexey_> А sse2 ускорение для матриц для 64бит aos там работает?
[21:02:39] <Kemet> я же писал что ссе только 32 бита в паблике
[21:04:10] <_valexey_> :-(
[21:05:29] <_valexey_> Печально это. На 32 битах нехватит памяти, а на 64 - времени.
[21:06:23] <_valexey_> Ну и опять же получается, что я сравниваю 64 битный код на плюсах с 32битным на aos. Не очень корректно.
[21:15:53] <_valexey_> Kemet: а какая сборка winaos считается самой кошерной?
[21:16:58] <_valexey_> Официально лежит что-то от 2012 года
[21:19:34] <_valexey_> Гм. А что за файл aosdebug.exe?
[21:33:51] <TRUE> запусти и узнаешь
[21:34:09] <Kemet> _valexey_: из репозитория )
[21:35:17] <Kemet> _valexey_: для отладки же ), но думаю с появлением сессионтрасе и сессионреплей неактуальна
[21:36:31] <Kemet> _valexey_: нуууу, я думаю что переписать ссе под 64 не трудно
[21:37:05] <Kemet> вот под авх сложнее
[21:38:08] <TRUE> я запустил этот файл, и он запустился. Я закрыл приложение, а оно не закрылось...
[21:38:36] <Kemet> _valexey_: наверное про 2 мегабайта я сморозил, правильнее скорее всего просто винда не смогла выделить непрерывный шматок нужного размера,
[21:39:20] <valexey> /me upgrading linux arch...
[21:39:44] <TRUE> с выделением памяти как таковым проблем быть не должно.
[21:39:53] <TRUE> виртуальной памяти, естественно
[21:40:14] <TRUE> ведь, аос в отдельном процессе запускается, верно?
[21:40:15] <_valexey_> Не
[21:40:35] <_valexey_> Если адресное пространство процесса кончается, то ничего не сделаешь
[21:40:50] <TRUE> а в системных сообщениях винды нет сообщений об ошибках?
[21:41:20] <TRUE> так оно и не кончается, если аос в отдельном процессе запускается.
[21:41:33] <TRUE> вряд ли только что запущенный аос сожрал все адреса
[21:41:46] <_valexey_> Кончается, если aos уже почти два гига сожрало
[21:42:35] <_valexey_> А мы ей память умножением матриц сжираем
[21:42:52] <_valexey_> Умножение матриц жрет озу как не в себя.
[21:44:52] <TRUE> а вы один столбец на одну строку перемножаете?
[21:46:47] <Kemet> TRUE: я умножаю две матрицы размером [6500X6500]
[21:46:58] <Kemet> RONGREAL
[21:47:23] <Kemet> LONGREAL
[21:47:49] <Kemet> VAR a, b, c : ARRAY [6500, 6500] OF LONGREAL
[21:49:16] <Kemet> _valexey_: не, aosdebug всё еще полезна, да, ибо не надо смотреть сессию
[21:49:19] <TRUE> так должна же создаться треться матрица такого же размера и всё. Или сильнее, чем надо забыл принцип перемножения матриц?
[21:49:53] <_valexey_> Ты просто думаешь про наивную реализацию
[21:49:55] <TRUE> *я забыл
[21:50:09] <_valexey_> Наивная реализация она медленная очень
[21:51:01] <TRUE> но программе на плюсах памяти же хватает...
[21:51:22] <_valexey_> Плюсы работают в 64 битах
[21:51:28] <TRUE> или вероятно, что плюсы и а2 разные алгоритмы используют?
[21:51:31] <TRUE> а
[21:51:50] <TRUE> а если на 32 проверить?
[21:52:23] <_valexey_> Приумножении матрицы размером 30000 на 30000 матлаб отожрал 30 гиг и хотел еще
[21:52:53] <Kemet> _valexey_: хм, при умножении а2 затребовала кеш 784000064
[21:53:26] <Kemet> или все ж под с не надо выделять, или это не кеш
[21:53:56] <Kemet> и тут ей венда по рукам
[21:55:00] <_valexey_> Ибо нефиг! :-)
[21:59:36] <TRUE> eventvwr.msc
[22:00:19] <TRUE> в пунктах Приложение или Система могут быть сообщения о том, почему приложение было закрыто
[22:04:46] <Kemet> TRUE: оно было закрыто потому что я его грохнул
[22:05:04] <Kemet> а грохнул потому что оно зависло
[22:05:19] <Kemet> а зависло потому что Out of memory
[22:16:46] <_valexey_> Интересно
[22:17:09] <_valexey_> В winaos умножение матриц похоже в несколько потоков фигачит
[22:17:23] <_valexey_> Все ядра заняты
[22:19:50] <_valexey_> Но от этого в линуксе есть лекарство :-)
[22:22:12] <_valexey_> При этом performance в самой aos херню показывает
[22:36:51] <Kemet> _valexey_:
[22:37:55] <Kemet> а ты что хочешь получить от c:= a* b, если все элементы а = 5, а элементы b = 10&
[22:38:19] <Kemet> чему должны быть равны элемениты с?
[22:39:17] <_valexey_> Э?
[22:39:51] <Kemet> ну типа c[i] := a[i] * b[i] &
[22:39:58] <_valexey_> Умножение матриц же. Есть вполне четкие правила что должно в итоге получиться
[22:40:02] <Kemet> ?
[22:40:06] <_valexey_> Нет
[22:40:14] <Kemet> а ок
[22:40:36] <_valexey_> Это поэлементное умножение, то что ты показал. Это совсем быстро
[22:40:41] <_valexey_> И просто
[22:40:49] <Kemet> угу
[22:40:58] <Kemet> это ю*
[22:41:02] <Kemet> .*
[22:41:07] <_valexey_> Да
[22:44:49] <Kemet> _valexey_: да, операции многопоточные
[22:45:48] <Kemet> поэтому картинка про сравнение такая и была, на то время оно так и было
[22:46:30] <_valexey_> Ы?
[22:47:21] <_valexey_> Картинка по вертикальной оси имела не время, а колличестао тактов/циклов.
[22:47:23] <Kemet> сравнение с цпп
[22:47:51] <_valexey_> Алсо многопоточное умножение матриц в cpp есть с незапамятных времен.
[22:47:58] <Kemet> а ну может быть
[22:48:05] <_valexey_> Там же нет ничего хитрого.
[22:48:58] <Kemet> _valexey_: а может на юниксаос какие лимиту устанавливаются?
[22:48:59] <_valexey_> Фича же в том, что на той картинке по факту сравнивали производительность кода писанного на ЯВУ с кодом писанным руками на асме.
[22:50:02] <_valexey_> Без интрисиков таеой производительности не достичь. (Но интрисик это таки не асм) А на чистом асме еще быстрей сейчас можно.
[22:50:03] <Kemet> иначе почему хип не увеличивается?
[22:51:01] <_valexey_> Вроде нет специальных лимитов по хипу с т.з. Линукса
[22:51:19] <_valexey_> Вайн то тоже 32битное приложение и у него проблем с хипом нет
[22:51:50] <_valexey_> Где-то в unixaos бага сидит злобная.
[23:03:30] <Kemet> _valexey_: вотя [5000x5000] уже 15 раз подряд просчитал и оно непадает ино памяти в итоге 1б4 отожрало
[23:03:51] <Kemet> 1,4
[23:04:10] <_valexey_> У меня 5000 виндоверсия тоже считает
[23:04:26] <Kemet> оно и 6500 считае
[23:04:42] <Kemet> но повторно вичснет
[23:05:39] <Kemet> просто с 5000 я в цикле запустил 15 раз
[23:06:15] <Kemet> видимо и больше норм, но ждать то неохота
[23:11:05] <Kemet> 6700 норм
[23:11:17] <Kemet> 6800 памяти нет
[23:12:49] <Kemet> _valexey_: кстати в aos.ini Поставь EnableReturnBlocks=1
[23:13:47] <_valexey_> Повторно не будет виснуть, если дернуть сборщик мусора
[23:14:10] <_valexey_> Это чтобы системе память возвращали?
[23:15:34] <Kemet> ну оно и так в итоге само вызывает гк
[23:15:44] <Kemet> да
[23:17:17] <_valexey_> Не вызывает вроде. Gc зовется по таймеру
[23:21:07] <_valexey_> Хотя не. Таки вызывает похоже.
[23:21:20] <_valexey_> У меня 6500 посчитало неоднократно.
[23:22:12] <_valexey_> А, не. Сейчас вот упало
[23:23:20] <_valexey_> Затыкается в критической секции где-то
[23:25:17] <_valexey_> Видимо все кому нужна память ждут когда манагер памяти освободится и обратит на них внимание.