Chat log from the meeting on 2021-02-09

From OpenSimulator

Jump to: navigation, search
[11:02] Gavin.Hird @grid.xmir.org:8002: Hi Andrew
[11:02] Chat Logger: Meeting chat logging has been enabled.
[11:02] Chat Logger: You can view the log at: https://web.youcantfixstupid.wtf/outreach/index.php
[11:02] Andrew Hellershanks: Hello, everyone.
[11:03] Andrew Hellershanks: Who is going to start us off today?
[11:04] Kayaker Magic: I have an animesh question:
[11:04] Andrew Hellershanks: Go ahead, Kayaker.
[11:04] Kayaker Magic: I want to make animesh sails, but apparently you cannot animesh a child prim?
[11:05] Ubit Umarov: ofc you can
[11:05] Kayaker Magic: The LL Wiki has an ambiguous paragraph saying you can...
[11:05] Kayaker Magic: But when I try, the viewer turns off the animesh bit and grays it out.
[11:06] Ubit Umarov: see this?
[11:06] Gavin.Hird @grid.xmir.org:8002: I have heard you can't, but it is probalby better to bring it up in the LL content creation meeting
[11:06] Kayaker Magic: I see the red dancer
[11:06] Andrew Hellershanks: Hello, Jagga.
[11:07] Jagga Meredith: hi
[11:07] Ubit Umarov whispers: and now its root prim :)
[11:07] Gavin.Hird @grid.xmir.org:8002: that figure is one mesh
[11:07] Ubit Umarov: in fact not having a root prim is a pain
[11:07] Kayaker Magic: Why do I get the animesh bit turned off when I link them?
[11:07] Ubit Umarov: to touch the thing when moving
[11:08] testObjAnim: animation danceRoot
[11:08] testObjAnim: Stop
[11:08] testObjAnim: animation 
[11:08] testObjAnim: Starting
[11:08] Ubit Umarov: no idea animwhat is do so old.. i don't remember the details now :)
[11:08] testObjAnim: animation danceRoot
[11:08] testObjAnim: Stop
[11:09] Gavin.Hird @grid.xmir.org:8002: because you cannot animesh two rigged items and then link them
[11:09] Ubit Umarov: actually this red thing ha several prims
[11:09] Kayaker Magic: I animesh one rigged item, then link it to a cube.
[11:09] testObjAnim: animation 
[11:09] testObjAnim: Starting
[11:09] Gavin.Hird @grid.xmir.org:8002: ok
[11:10] Kayaker Magic: link first, then animesh will work?
[11:10] Ubit Umarov: well i do control is on root prim with  llStartObjectAnimation("danceRoot");
[11:11] Gavin.Hird @grid.xmir.org:8002: can't you link with the cube as root, select the rigged mesh separately and mark it as animesh
[11:11] testObjAnim: animation danceRoot
[11:11] testObjAnim: Stop
[11:11] Ubit Umarov: actually no
[11:11] Ubit Umarov: the root prim does have Animated mesh set
[11:11] testObjAnim: animation 
[11:11] testObjAnim: Starting
[11:12] Kayaker Magic: The root prim runs the script? What if you have two animesh child prims nd want a different animation in each?
[11:12] Ubit Umarov: as is said.. i don't remember lol´
[11:12] Ubit Umarov: not sure you can do that really
[11:14] Ubit Umarov: yeha think it is one per linkset
[11:14] Ubit Umarov: as we add meshes to it, it addes all their bones
[11:14] Kayaker Magic: My goal is to have each sail an animesh, each running their own animation.....
[11:14] Kayaker Magic: so a tall ship with dozens of sails is possible....
[11:15] Ubit Umarov: don't think you can link them
[11:15] Gavin.Hird @grid.xmir.org:8002: I would ask the SL content creation meeting
[11:15] Ubit Umarov: but well long time since i did look
[11:15] Kayaker Magic: Or at least a catamaran with main, jib and spinnaker
[11:15] Gavin.Hird @grid.xmir.org:8002: make your prototype in SL
[11:16] Ubit Umarov: "
[11:16] Gavin.Hird @grid.xmir.org:8002: as far as I can remember you can only have one animated mesh per link set
[11:16] Ubit Umarov: Animated objects work by associating a skeleton with a linkset containing one or more rigged mesh primitives. When animations are played by a script in any of the prims in the linkset, the skeleton will animate and any rigged meshes in the linkset will move accordingly. "
[11:16] Kayaker Magic: What about wearing animesh pets? Each one can do a different animation, can you not wear two?
[11:16] Ubit Umarov: so one linkset == one anim thing
[11:17] Ubit Umarov: yes you can wear 2 if you have a sl premium account :p
[11:17] Gavin.Hird @grid.xmir.org:8002: wearing is different
[11:17] Ubit Umarov: yeah wear is not link
[11:18] testObjAnim: Hello, Avatar!
[11:18] testObjAnim: animation 
[11:18] testObjAnim: Starting
[11:18] Ubit Umarov: see ?
[11:19] Kayaker Magic: So animated sails will never work ....
[11:19] Ubit Umarov: ( as i said this at sl depends on account type )
[11:20] Ubit Umarov: normal accounts can wear only one.. premium 2
[11:20] testObjAnim: animation danceRoot
[11:20] testObjAnim: Stop
[11:21] Gavin.Hird @grid.xmir.org:8002: you should be able to make some kind of animated sail by suing the wing and tail bones fore each cloth
[11:21] Gavin.Hird @grid.xmir.org:8002: using*
[11:21] Ubit Umarov: a pain to mk i guess :)
[11:22] Ubit Umarov: their are sl  npcs
[11:22] Ubit Umarov: that was their only goal
[11:23] Kayaker Magic: So, use the right hand for the square sails, left for the for-andd-aft sails, tail for the jib and wings for the spinnaker?
[11:23] Gavin.Hird @grid.xmir.org:8002: something like that
[11:23] Ubit Umarov: wearing a boat? :)
[11:23] Ubit Umarov: well wearing airplanes did work
[11:23] Ubit Umarov: or cars
[11:24] Kayaker Magic: No, I want the sails of the boat to work smoothly while I ride it.
[11:24] Gavin.Hird @grid.xmir.org:8002: I have wore bloats ages ago in SL :-)
[11:24] Gavin.Hird @grid.xmir.org:8002: boats
[11:24] Gavin.Hird @grid.xmir.org:8002: except they did not animate
[11:24] Ubit Umarov: crossings did work a lot better
[11:25] Ubit Umarov: well about code changes
[11:25] Ubit Umarov: still not that many
[11:25] Ubit Umarov: made one just bf the meeting
[11:25] Ubit Umarov: seems oars assets aren't loaded  yeack
[11:26] Ubit Umarov: that seems related to the negative caching..
[11:26] Ubit Umarov: usefull thing.. but a big pain to mk it work right
[11:27] Gavin.Hird @grid.xmir.org:8002: negative cacheing .... does it suck objects out of the region?
[11:27] Ubit Umarov: :)
[11:28] Ubit Umarov: nahh just remembers missing assets and does not try to go get them from grida again
[11:28] Ubit Umarov: good idea.. a BIG fail as it was added
[11:28] Ubit Umarov: and still not that good
[11:28] Ubit Umarov: well the commit i did today should improve it a bit.. lets see
[11:29] Andrew Hellershanks: Three bug reports saw some attention this past week.
[11:29] Andrew Hellershanks: The mantis numbers are: #8855, #8861, and #8862.
[11:30] Andrew Hellershanks: One other change this past week dealt with making osteleport work with phantom prims.
[11:30] Ubit Umarov: another one is about some objects that ppl have that a are a total disaster on unlink then link
[11:30] Gavin.Hird @grid.xmir.org:8002: why not try to go get them from grida again after a while. The backend might have been interrupted for any reason, so a retry could succeed fetching the asset
[11:30] Ubit Umarov: i found the reason.. those objects have invalid rotations
[11:30] Ubit Umarov: ie not normalized
[11:31] Ubit Umarov: so added normalization on setting the prims rotations
[11:32] Ubit Umarov: and yeha as andrew said made osteleportobject also work with phantom objects
[11:32] Ubit Umarov: don't remember why i excluded them :)
[11:33] Ubit Umarov: lets hope ppl don't find why ;)
[11:33] Ubit Umarov: ohh that as last week already
[11:33] Ubit Umarov: was...
[11:35] Jagga Meredith: having a lot of problems with my regions.  strings of messages...2021-02-09 10:15:59,971 ERROR - OpenSim.Region.Framework.Scenes.EventManager [EVENT MANAGER]: Delegate for TriggerOnScriptChangedEvent failed - continuing.  Exception of type 'System.OutOfMemoryException' was thrown.    at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)
   at System.Threading.Thread.Start(StackCrawlMark& stackMark)
[11:35] Jagga Meredith: windows 10 pro.  task manaer says 8 Gb available
[11:35] Andrew Hellershanks: Out of Memory could be just that.
[11:35] Andrew Hellershanks: Jagga, Are you running a 32-bit or 64-bit version of Win 10?
[11:35] Jagga Meredith: 64
[11:36] Ubit Umarov: Xengine?
[11:36] Andrew Hellershanks: ok. That eliminates one source of problem.
[11:36] Jagga Meredith: hmmm I should check
[11:36] Jagga Meredith: Xengine AFAIK
[11:37] Andrew Hellershanks: If the thread pool was exhaused would it say out of memory or give a different error message?
[11:37] Ubit Umarov: xengine does set threads memory stack
[11:38] Ubit Umarov: or hmm stack size in memory :)
[11:38] Andrew Hellershanks: Jagga, have you used task manager to see how much memory is used by the OS instance?
[11:38] Ubit Umarov: did you change those settings on Xengine?
[11:38] Gavin.Hird @grid.xmir.org:8002: nursery-size or is that mono specific?
[11:39] Jagga Meredith: Ubit: didn't change anything in Xengine
[11:39] Jagga Meredith: Andrew how do I do that?
[11:39] Ubit Umarov: ;; How many threads to start at maximum load
    ; MaxThreads = 100
[11:39] Andrew Hellershanks: Gavin, I think that is mono specific but I don't run OS under WIndows so I wouldn't know how to do the equivalent in Windows.
[11:39] Ubit Umarov: this is suicidal :p
[11:40] Ubit Umarov: ;; Stack size per script engine thread in bytes.
    ;; If you are experiencing StackOverflowExceptions you may want to increase this (e.g. double it).
    ;; The trade-off may be increased memory usage by the script engine.
    ; ThreadStackSize = 262144
[11:40] Jagga Meredith: ok I'll try that
[11:40] Ubit Umarov: those 2 == 2GB of crititcal stack memory
[11:40] Ubit Umarov: errr
[11:41] Ubit Umarov: oops
[11:41] Ubit Umarov: bad math :)
[11:41] Jagga Meredith: which .ini is taht in?
[11:41] Andrew Hellershanks: Jagga, Start taskmgr (IIRC, or hit ctrl-alt-del and pick Task Manager from the list), You can use that tool to check overall system memory use as well as per application/process memory usage.
[11:42] Ubit Umarov: opensim.ini
[11:42] Ubit Umarov: keep xengine number of threads not that large
[11:43] Andrew Hellershanks: Jagga, does the region have a lot of objects and or scripts?
[11:43] Ubit Umarov: bet a lot of scripts
[11:43] Andrew Hellershanks nods
[11:43] Andrew Hellershanks: I've run regions with lots of scripts and haven't run in to that issue.
[11:44] Ubit Umarov: yeah its strange
[11:44] Jagga Meredith: andrew one has lots of scripts
[11:44] Ubit Umarov: but the error is allocating threads stack on xengine
[11:44] Gavin.Hird @grid.xmir.org:8002: does Windows have settings for number of allowed files open and such like Linux(Uinix does?
[11:44] Andrew Hellershanks: yea. I have run regions with around 5,000 or more scripts using XEngine with just the normal XEngine default settings.
[11:44] Gavin.Hird @grid.xmir.org:8002: I have had to raise those limits
[11:45] Ubit Umarov: more hidden gavin.Hird
[11:45] Gavin.Hird @grid.xmir.org:8002: right
[11:45] Andrew Hellershanks: Windows does have a limit on number of open files. It might be settable via a registry entry but I'm not sure about that.
[11:45] Ubit Umarov: some depending one how much you paid ms on the win flavor
[11:45] Gavin.Hird @grid.xmir.org:8002: I bet
[11:45] Ubit Umarov: like those "home" craps
[11:45] Ubit Umarov: just like apple :p
[11:46] Ubit Umarov runs and hides
[11:46] Jagga Meredith: i'm running pro
[11:46] Andrew Hellershanks: :)
[11:46] Jagga Meredith: had to upgrade to get remote
[11:46] Gavin.Hird @grid.xmir.org:8002: The Rasberry community has been up in arms (!) the last week over a MS repository being stealth added to Raspbian OS
[11:46] Ubit Umarov: check MaxThreads in [xengine]
[11:46] Jagga Meredith: ok
[11:46] Ubit Umarov: mb you have it defined with 2 many threads
[11:47] Ubit Umarov: if not mb the default 100 is 2 many.. try set it lower.. like 20
[11:47] Ubit Umarov: you can also test YEngine
[11:47] Ubit Umarov: (after backups etc etc )
[11:48] Jagga Meredith: ok, and may go Yengine route
[11:48] Ubit Umarov: yengine will crash in diferent ways :p
[11:48] Ubit Umarov: oops  i mean will work...
[11:48] Ubit Umarov: ;)
[11:48] Andrew Hellershanks: hehe
[11:48] Ubit Umarov: did you look to region mem usage?
[11:49] Ubit Umarov: see stack is a critical thing.. must be continus memory etc
[11:49] Andrew Hellershanks: That's why I was suggesting using Task Manager to see what it says.
[11:49] Ubit Umarov: yeah
[11:49] Gavin.Hird @grid.xmir.org:8002: I am running with MaxThreads = 150 for Xengine, but that is on mono
[11:50] Ubit Umarov: well guess region just using  a lot of memory
[11:51] Ubit Umarov: blows up on xengine threads stack bc that does need more restricted memory as i said
[11:51] Gavin.Hird @grid.xmir.org:8002: but I had to increase the number of threads per process and numer of open files at some point
[11:52] Ubit Umarov: yeah
[11:52] Ubit Umarov: number of fds is needed
[11:52] Andrew Hellershanks: Gavin, any idea how many scripts you were running before you needed to increase the limits?
[11:52] Ubit Umarov: fds (files ) is needed bv of stupid http viewers use
[11:52] Gavin.Hird @grid.xmir.org:8002: it was actually for Ode compilation I exeeded the limit
[11:53] Andrew Hellershanks: Ode? That's going back a ways. :)
[11:53] Ubit Umarov: duhhh
[11:53] Ubit Umarov: ubode uses ode :p
[11:53] Gavin.Hird @grid.xmir.org:8002: it spawned about 2000 threads duirjng compilation, but dilaed back to around 300 after
[11:53] Gavin.Hird @grid.xmir.org:8002: it was a bit back
[11:53] Ubit Umarov: 2000 LOL
[11:54] Ubit Umarov: yr gcc thinks it is running on a ibm super ?
[11:54] Ubit Umarov: :)
[11:54] Gavin.Hird @grid.xmir.org:8002: 8 cores running mono at 730% CPU
[11:54] Ubit Umarov: 2000 threads is just waste of cpu
[11:55] Jagga Meredith: 730%  what were y ou using for coolant?  liquid nitrogen?
[11:55] Gavin.Hird @grid.xmir.org:8002: it loaded ot 730% :-)
[11:55] Ubit Umarov: see 200 threads and even didn't use all the cores :p
[11:55] Ubit Umarov: 2000´
[11:55] Gavin.Hird @grid.xmir.org:8002: it just means  that 7.3 cores were running mono only
[11:55] Ubit Umarov: ode is not mono
[11:56] Ubit Umarov: or what do you call ode ?
[11:56] Gavin.Hird @grid.xmir.org:8002: ode compiled physics on mono
[11:56] Ubit Umarov: ??
[11:56] Gavin.Hird @grid.xmir.org:8002: during region startu
[11:56] Gavin.Hird @grid.xmir.org:8002: startup
[11:56] Ubit Umarov: ahh running...
[11:56] Ubit Umarov: ok
[11:57] Ubit Umarov: well ode only uses one thread :)
[11:57] Ubit Umarov: hmm plus 2 to decode meshes
[11:57] Ubit Umarov: so that load was elsewhere
[11:58] Gavin.Hird @grid.xmir.org:8002: It has to do with how macOS does threading using something Grand Central Dispatch,
[11:58] Ubit Umarov: 7 regions on same instance?
[11:58] Gavin.Hird @grid.xmir.org:8002: * called
[11:58] Gavin.Hird @grid.xmir.org:8002: it started one region at the time
[11:58] Ubit Umarov: no idea
[11:58] Ubit Umarov: ubode is single thread as i said
[11:58] Gavin.Hird @grid.xmir.org:8002: but this is the old ODE
[11:59] Ubit Umarov: well same
[11:59] Gavin.Hird @grid.xmir.org:8002: before ubode existed
[11:59] Ubit Umarov: but that one may fire a ton of threads to decode meshes and sculpts
[11:59] Gavin.Hird @grid.xmir.org:8002: which is what it did
[11:59] Ubit Umarov: old opensim idea  more threads == faster..  duhhh
[11:59] Selby.Evans @grid.kitely.com:8002: must gp -- bye
[12:00] Ubit Umarov: have fun Selby.Evans
[12:00] Gavin.Hird @grid.xmir.org:8002: mark that I used Thread and not smartthreadpool
[12:00] Andrew Hellershanks: ok, tc Selby.
[12:00] Ubit Umarov: smartthreadpool also uses threads :p
[12:01] Gavin.Hird @grid.xmir.org:8002: I still use async_call_method = Thread
[12:01] Ubit Umarov: thats not that good
[12:01] Ubit Umarov: in fact it is bad.. very
[12:02] Gavin.Hird @grid.xmir.org:8002: I find it to be very efficient
[12:02] Gavin.Hird @grid.xmir.org:8002: on macOS
[12:02] Ubit Umarov: it is not..
[12:02] Ubit Umarov: is a disaster
[12:02] Jagga Meredith: you on intel or AMD?
[12:02] Gavin.Hird @grid.xmir.org:8002: Intel
[12:02] Ubit Umarov: u sould use (not so) smartpool
[12:03] Ubit Umarov: thread is just the WORSE option
[12:03] Gavin.Hird @grid.xmir.org:8002: I have found it to be both stable and performant
[12:04] Ubit Umarov: it is not
[12:04] Ubit Umarov: just misleading testing
[12:04] Gavin.Hird @grid.xmir.org:8002: it is stable
[12:04] Ubit Umarov: other option is QueueUserWorkItem
[12:04] Gavin.Hird @grid.xmir.org:8002: that one does not work at all on macOS
[12:04] Ubit Umarov: that uses .net main pool
[12:05] Ubit Umarov: oh? .net fail?
[12:05] Gavin.Hird @grid.xmir.org:8002: it crash very early during startup
[12:05] Ubit Umarov: uff
[12:05] Gavin.Hird @grid.xmir.org:8002: or did so I have not tried it since
[12:05] Ubit Umarov: well i prefer smart still bc several reasons
[12:06] Ubit Umarov: well and did change it recently
[12:06] Ubit Umarov: but all code assumes there is a Pool
[12:06] Gavin.Hird @grid.xmir.org:8002: for Robust I use async_call_method = SmartThreadPool
[12:06] Ubit Umarov: to use full threads is a disaster
[12:06] Gavin.Hird @grid.xmir.org:8002: Thread made Robust very unstable
[12:07] Ubit Umarov: their creation/dest is heavy etc etc
[12:07] Jagga Meredith: *mutters* "...which made Robust  not very robust?"
[12:07] Ubit Umarov: well ms did rush adding their pool ages ago
[12:07] Gavin.Hird @grid.xmir.org:8002: hehe
[12:08] Ubit Umarov: now they even think direct use of the pool threads is bad
[12:08] Ubit Umarov: so they created Tasks
[12:08] Gavin.Hird @grid.xmir.org:8002: thread creation on macOS is quite fast compared to other operating systems
[12:08] Ubit Umarov: that are actually basicly workitems
[12:08] Gavin.Hird @grid.xmir.org:8002: and the system place them across all cores using GCD
[12:09] Ubit Umarov: change to smart pool :p
[12:09] Ubit Umarov: Framework main threadpool
workers:    1 (500 / 4)
Completion: 0 (1000 / 4)

Threadpool (excluding script engine pools)
Thread pool used           : SmartThreadPool
Max threads                : 300
Min threads                : 8
Allocated threads          : 8
In use threads             : 1
Work items waiting         : 0

Total process threads active: 34
[12:09] Ubit Umarov: ( show threads on console )
[12:09] Ubit Umarov: that is a region just started
[12:10] Gavin.Hird @grid.xmir.org:8002: smartthreadpool does not know anything about GCD so it performs worse
[12:10] Ubit Umarov: on you box actually :)
[12:10] Ubit Umarov: nonsense
[12:10] Gavin.Hird @grid.xmir.org:8002: that is a Linux box
[12:10] Gavin.Hird @grid.xmir.org:8002: you are on
[12:10] Ubit Umarov: diferent levels
[12:11] Gavin.Hird @grid.xmir.org:8002: it runs debian and debian does not know anything about GCD
[12:11] Ubit Umarov: diferent levels
[12:11] Gavin.Hird @grid.xmir.org:8002: https://en.wikipedia.org/wiki/Grand_Central_Dispatch
[12:12] Ubit Umarov: a pool is just keep threads busy
[12:12] Ubit Umarov: yeah seems like what .net did with tasks
[12:13] Ubit Umarov: for c++ programs that use it
[12:14] Ubit Umarov: who knows what mono does
[12:14] Ubit Umarov: as i said that is concurrent to .net tasks, from what i see on that link
[12:15] Ubit Umarov: while .net thread is suposed to be a low level almost os level thread
[12:15] Gavin.Hird @grid.xmir.org:8002: Apple states that 15 instructions are required to queue up a work unit in GCD, while creating a traditional thread could easily require several hundred instructions.
[12:16] Gavin.Hird @grid.xmir.org:8002: so mono is taking advantage of that
[12:16] Ubit Umarov: yeah.. that is called threads pool :p
[12:16] Ubit Umarov: and that is what that side tells
[12:16] Gavin.Hird @grid.xmir.org:8002: I doubt smarthreadpool is using 15 instructions to queue up a new task :-)
[12:17] Ubit Umarov: "It is an implementation of task parallelism based on the thread pool pattern. The fundamental idea is to move the management of the thread pool out of the hands of the developer, and closer to the operating system. "
[12:17] Ubit Umarov: so.. it is a pool
[12:17] Jamie.Jordan @grid.kitely.com:8002: Thanks for the company everybody. I'm out. See you next week
[12:17] Ubit Umarov: for c++ and other programs
[12:17] Andrew Hellershanks: ok, Jamie. tc. See you next week.
[12:17] Ubit Umarov: queue a task is not the heavy part
[12:17] Ubit Umarov: is the waiters :p
[12:18] Andrew Hellershanks: It is almost 20 past the hour. Did anyone else have a question they wanted to ask before we wrap things up for today?
[12:18] Gavin.Hird @grid.xmir.org:8002: the effect from the app developer's standpoint is that thread creation usuisally is almost instant
[12:18] Ubit Umarov: you can see smart code :)
[12:18] Ubit Umarov: no
[12:19] Ubit Umarov: depends on the pool state
[12:19] Ubit Umarov: is just like .net pool or smartpool
[12:19] Gavin.Hird @grid.xmir.org:8002: no, it is not just like that :-)
[12:19] Ubit Umarov: just integrated on the os
[12:20] Ubit Umarov: it is just like that :p
[12:20] Gavin.Hird @grid.xmir.org:8002: in the kernel
[12:20] Gavin.Hird @grid.xmir.org:8002: anyways
[12:20] Ubit Umarov: it is their lib for tasks
[12:20] Gavin.Hird @grid.xmir.org:8002: but it is a kernel lib
[12:20] Ubit Umarov: that is not that relevant
[12:21] Gavin.Hird @grid.xmir.org:8002: I posted a new version of the Windows vieer a few days back
[12:21] Ubit Umarov: in fact  theories changed on where should some mem managament be
[12:21] Ubit Umarov: if kernel space or user space
[12:21] Gavin.Hird @grid.xmir.org:8002: after having my build machine up and running again
[12:21] Ubit Umarov: and out of coffee :)
[12:22] Gavin.Hird @grid.xmir.org:8002: I also managed to persuade vmware to build the Windows version 5X faster than before
[12:22] Gavin.Hird @grid.xmir.org:8002: so that was a real win
[12:22] Ubit Umarov: yeah ... the chips still have coffee .. to run fast
[12:22] Ubit Umarov: :)
[12:22] Gavin.Hird @grid.xmir.org:8002: :-))
[12:22] Ubit Umarov: ...so run..
[12:23] Gavin.Hird @grid.xmir.org:8002: to was the insanely slow implementation of shared folders in vmware fusion or worksttion that was the issue
[12:23] Gavin.Hird @grid.xmir.org:8002: so sharing the files over a on-machines SMB share made the trix
[12:24] Ubit Umarov: well i made changes to smartpool
[12:24] Ubit Umarov: and use it even more
[12:24] Ubit Umarov: parts of code do assume it is there even
[12:24] Gavin.Hird @grid.xmir.org:8002: probalby why robust barfs
[12:25] Ubit Umarov: dunno
[12:26] Ubit Umarov: gess both ms and apple think programmers are bad
[12:26] Ubit Umarov: well and they are right :)
[12:26] Gavin.Hird @grid.xmir.org:8002: ok :-)
[12:26] Ubit Umarov: this threading things are such a case
[12:27] Ubit Umarov: take them out of programmers
[12:27] Ubit Umarov: well and grabage collector in other ways
[12:28] Ubit Umarov: but just looking the amount of threads opensim did use ( and still does)  just tells they aare right :)
[12:28] Ubit Umarov: no one knows the amadahll ??? gezz never remember the name, law
[12:29] Ubit Umarov: Amdahl's law
[12:29] Gavin.Hird @grid.xmir.org:8002: the good thing about the way they have implemented it, the system will dispatch htreads on high performance or low energy cores on AS completely transparent to the programmer
[12:29] Ubit Umarov: ( and that is about cores, not threads )
[12:30] Ubit Umarov: thats intel thingies
[12:30] Ubit Umarov: and amd
[12:30] Ubit Umarov: and no.. its trying to keep threads on cores already hot
[12:31] Ubit Umarov: a mess
[12:31] Gavin.Hird @grid.xmir.org:8002: speaking of AS, LL was asked multiple times at the last TPV dev meeting about AS support for the viewer, and they did not answer once
[12:31] Ubit Umarov: another is about SIMD
[12:32] Ubit Umarov: ppl making code so SIMD only runs on some cores
[12:32] Ubit Umarov: bc otherwise preformance goes down
[12:32] Ubit Umarov: thing its openssl
[12:33] Ubit Umarov: using AVX512,  overall machine performance went down more than 10%
[12:33] Ubit Umarov: the linux guy rants about avx specialyy 512
[12:33] Ubit Umarov: linus?
[12:34] Ubit Umarov: avx more than 256 is just bad
[12:34] Gavin.Hird @grid.xmir.org:8002: linus rants a lot :-)
[12:34] Ubit Umarov: slows down the cores a lot
[12:34] Ubit Umarov: totally stops a core, turning on and off parts of it even
[12:35] Ubit Umarov: so as i said, overall performance of a server went down using avx 512 on ssl  cyphers
[12:36] Ubit Umarov: so guys sigesting to only use simd on a few and always the same cores
[12:36] Ubit Umarov: :)
[12:36] Ubit Umarov: sugesting..
[12:37] Ubit Umarov: well and another meeting went by
[12:37] Ubit Umarov: we are a week older.. etc
[12:37] Andrew Hellershanks: Yes, it has.
[12:37] Andrew Hellershanks: and we are.
[12:37] Ubit Umarov: gezz time flies..
[12:37] Gavin.Hird @grid.xmir.org:8002: Tomorrow is ny 4th born again day :-)
[12:37] Gavin.Hird @grid.xmir.org:8002: my*
[12:38] Andrew Hellershanks: I think its time to end todays meeting. I need to get back to work deciphering some code.
[12:39] Andrew Hellershanks: That will do it for this week. Thank you all for coming. See you again next week.

Personal tools
General
About This Wiki