Simulator User Group/Transcripts/2011.07.22
| Prev 2011.07.19 | Next 2011.07.22 |
List of Speakers
| Andrew Linden | Chaley May | Fancy Greeter |
| Griefer Evermore | 1Justin1 | Kadah Coba |
| Kallista Destiny | Kelly Linden | Leonel Iceghost |
| Liisa Runo | Moundsa Mayo | Pauline Darkfury |
| Ramona Criss | Rex Cronon | Simon Linden |
| TankMaster Finesmith | Techwolf Lupindo | Vincent Nacon |
Transcript
[16:01] Kallista Destiny: Eventually whne Mesh makes it to the ful grid.
[16:01] Chaley May: hmm i dont like that idea :(
[16:01] Vincent Nacon: me either
[16:02] Kallista Destiny: Hi Andrew
[16:02] Andrew Linden: Hello
[16:02] Chaley May: hi :)
[16:02] Vincent Nacon: good thing I still have my box-ful of mega prims
[16:02] Vincent Nacon: (yes, i'm rubbing it in your face, lindens)
[16:02] Andrew Linden: What is the idea you don't like? Megaprims?
[16:03] Liisa Runo: i dont think normal prims will count as more than one prim if bigger than 10m, just meshes, would be insane to have normal prims count more than one
[16:03] Vincent Nacon: no not mega prim, the prim count via scale
[16:03] Andrew Linden: Ah
[16:03] Kallista Destiny: with mga's prim count will drop
[16:03] Kallista Destiny: megas*
[16:04] Chaley May: if normal prims at 64m cost just one prim thats great
[16:04] Vincent Nacon: that's the problem, it won't
[16:04] Liisa Runo: we seem to have mixed information, Andrew? can you clarify?
[16:04] Kallista Destiny: Vincent I've heard notohing to indicate that
[16:04] Rex Cronon: hello everybody
[16:05] Kallista Destiny: Hi rex
[16:05] Andrew Linden: I think the new "prim" cost formula will introduce some pain as people adjust.
[16:05] Rex Cronon: hi ksllidys
[16:05] Liisa Runo: we are talking about normal prims now, not meshes
[16:05] Vincent Nacon: I can work around it with mega prim and sculpty just fine
[16:05] Andrew Linden: One thing that will make it more painful is that the formula are definitely not perfect and will have to be adjusted.
[16:05] Rex Cronon: hmm. sorry. kallista:)
[16:05] Chaley May: if your too harsh on normal prims then its really going to make it difficult for those creators who use only SL to build compete with those who can make meshes
[16:05] Vincent Nacon: it's only when the prim is bigger than 10m
[16:06] Andrew Linden: The plan is to leave 1-piece = 1 "prim" for "normal-only" objects... to support the legacy system
[16:06] Chaley May: great
[16:06] Liisa Runo: phew
[16:07] Andrew Linden: the new costs only kick in when using "new features" such as mesh, or "no shape"
[16:07] Andrew Linden: However...
[16:07] Vincent Nacon: you sure? that's not what other lindens said at mesh meeting
[16:07] Chaley May: yeah i dont think noone can complain about that
[16:07] Andrew Linden: the formulae for "prim" costs are being introduced to provide some feedback for guiding content creators
[16:08] Andrew Linden: it is a work in progress, but hopefully it will become a more clear feedback loop eventually
[16:08] Andrew Linden: not all "normal" prims are created equal
[16:08] Leonel Iceghost: is that feedback going to count more if the object is physical?
[16:08] Andrew Linden: some are much more expensive in CPU costs than others
[16:08] Chaley May: yes
[16:09] Andrew Linden: Leonel, the "prim" cost of the object may increase when it is "dynamic" (and using some of the new features such as mesh)
[16:09] Chaley May: its mostly the flat prims that people use anyway
[16:09] Vincent Nacon: as for scaling prim count for mesh itself, it would only encourage me more with sculpty + mega prim, regardless of CPU cost or resources, long as I "can" have less prim count.
[16:09] Vincent Nacon: but as for now, I'll just say "oh well"
[16:10] Andrew Linden: Yeah Vincent, we know that there will be incentives for people to bypass the feedback loops by going sculpty + mega
[16:10] Ramona Criss: Hello all
[16:10] Kallista Destiny: well clearly the 'cost' will be related to CPU and resource uage
[16:10] Andrew Linden: we'll have to figure out how to apply pressures later to help guide people toward more "optimal" content solutions
[16:10] Simon Linden: Welcome, Ramona
[16:10] Vincent Nacon: ionically I would favor less CPU resources with less prim count
[16:10] Ramona Criss: Thank Youuuuuuuuuu!!
[16:10] Rex Cronon: hi
[16:11] Andrew Linden: That's the idea... to make the costs truly scale up when actually using up resources.
[16:11] Kallista Destiny: Hi Ramona
[16:11] Andrew Linden: The two main resources at the server level are: CPU cycles and network bandwidth
[16:11] Ramona Criss: Hello Kallista
[16:11] Vincent Nacon: without making contents that look like just came out back in 1998?
[16:11] Leonel Iceghost: why not just use a "physics time".. that way there couldn't be a way to overuse sim resourses as well
[16:11] Rex Cronon: come on. sculpties didn't come n 1998:)
[16:12] Vincent Nacon: no, I meant when making mesh
[16:12] Vincent Nacon: to keep it at 1 prim count vs one sculpty prim
[16:12] Simon Linden: We don't know a 'physics time' for a single object, and it would vary widely based on what's going on, such as when it collides
[16:13] Rex Cronon: i guess if u want detail u choose mesh and if u want speed u choose sculpties
[16:13] Vincent Nacon: other way around
[16:14] Andrew Linden: We're trying to "anticipate" the physics cost by incrementing the cost of the object when it is more complex
[16:14] Andrew Linden: but physics really translates to CPU cycles
[16:14] Rex Cronon: a mesh can be way heavier than a sculptie
[16:14] Vincent Nacon: in my option, using generator to create the physic mesh for them.... force them to provide one instead
[16:14] Kallista Destiny: and Badnly made mesh can be horrible
[16:15] Andrew Linden: yeah, the cost of meshes can get big when scaled large, whereas a big sculpty is artificially set to cost of 1 for legacy support
[16:15] Kallista Destiny: badly
[16:15] Vincent Nacon: forget the generator, it's not very intuitive to make it effective
[16:16] Techwolf Lupindo: I can make a 10M prim a skuptie 20M normal prim and still count as one prim.
[16:16] Andrew Linden: I expect we'll be tweaking the resource cost formulae for a while.
[16:16] Vincent Nacon: yeah, after a ton of complaints in emails
[16:17] Andrew Linden: We definitely did not have time to figure out the perfect system. And providing info back to the viewer about how the costs are being computed is not finished.
[16:17] Kallista Destiny: Vincent, that is called feedback
[16:17] Simon Linden: ... and there really isn't a sane way to make it match up with legacy content, since every old prim is just one, regardless of how twisted and cut it is
[16:17] Vincent Nacon: honest... don't tweak it after the release
[16:17] Pauline Darkfury: Well, after release, you can only tweak the cost downwards, at least for static objects, anything which would push it upwards is world-breaking
[16:17] Vincent Nacon: because people would easily get angry if you made some tweaking
[16:17] Rex Cronon: until the cost formula gets right, lots of people will get a headache:(
[16:17] Vincent Nacon: yup, best to have final tweak before release
[16:18] Vincent Nacon: setting a standard, that is
[16:18] Liisa Runo: i would like to hear more about the scale effect to the resources. i find it hard to believe, numbers are numbers, computers dont care if it is 3 or 4. Bigger stuff is more heavy for the sim or for the client?
[16:18] Vincent Nacon: aye, Liisa
[16:19] Vincent Nacon: the only defense I've heard about it was LOD resources on client side
[16:19] Rex Cronon: what if the shape seen by havok is actually smaller than the actuall mesh?
[16:19] Andrew Linden: Yes. Size matters for physics... larger objects have a larger cross-section.
[16:19] Kallista Destiny: but larger objects do infact generate more activity on the server
[16:19] Andrew Linden: Also size matters for streaming, larger objects are more visible.
[16:19] Techwolf Lupindo: One cpu cycle is used to calc a 64-bit, same as a 32-bit calc. Number size not matter when at or smaller then data path bit wight.
[16:20] Pauline Darkfury: I'm still trying to get to grips with it all, personally. One thing I think I heard in passing is that adding any script to it can massively increase the prim-equiv cost. Is that true? Even if the script does not do anything physics-related?
[16:20] Moundsa Mayo: Meh. Just charge by MIPS and provide cost accounting so the 'rational marketplace' can work its magic B^D
[16:20] Kallista Destiny: more data points in the larget objct
[16:20] Andrew Linden: Yes, I think we're trying to consider script consequences into the cost.
[16:20] Andrew Linden: However, the details of the script are not analyzed
[16:20] Leonel Iceghost: :(
[16:20] Techwolf Lupindo: Kallista, not true. Small prim has same number of data points as large prim.
[16:20] Andrew Linden: even though not all scripts are created equal.
[16:21] Liisa Runo: only physics? so phantom stuff dont get more prim heavy when big? and if we are taxed for the visual cost for the client, why not make the cost change when people zoom their camera closer and further?
[16:21] Vincent Nacon: because no one in gaming industries had heard anything like that.
[16:21] Andrew Linden: Which is too bad... I guess it will eventually lead to a similar "legacy --> more complex" accounting transition in the future
[16:21] Pauline Darkfury: Well, that kinda prevents the use of mesh in a huge number of cases. It makes it sound like if you want to have any form of scripting, you need to avoid mesh at all costs, for static objects
[16:21] Pauline Darkfury: :(
[16:21] Leonel Iceghost: Andrew, if it is a fix for those 20ms script time sims welcome, but if it is just going to be the same... no good
[16:21] Techwolf Lupindo: It only when you get into skulpti LOD then it changes with size on viewere.
[16:21] Andrew Linden: when we get smart about filtering cheap scripts from expensive ones
[16:22] Vincent Nacon: might be best to separates prim cost and script cost
[16:22] Moundsa Mayo: I was thinking more like ALL simulator MIPS, whether from physics, tortured prims, mesh size, or scripts ...
[16:22] Rex Cronon: even the smartest script can have dumb function:)
[16:22] Moundsa Mayo: And a way for us to do our own cost analyses B^DDD
[16:23] Pauline Darkfury: 20ms script time sims are not the enemy, especially with the loss of script performance that came in with Mono 2. A sim hits 20ms script time at just 3000 scripts now (or less), long before it should be causing any significant impact on sims sharing the server
[16:24] Techwolf Lupindo: Mono 2 had better performace, but it impatec the sim resources negitelly.
[16:24] Kallista Destiny: the dispacher is in severe need of looking into
[16:24] Moundsa Mayo: Tools | MIPS Cost of Selection
[16:24] Pauline Darkfury: The timeslice measurements say that performance in terms of actual available compute performance is drastically reduced under Mono 2, Techwolf. It has helped the sim-freeze a bit, but it has harmed actual performance
[16:25] Leonel Iceghost: Pauline, they are the enemy.. you cannot play CCS for example in those 20ms script time sims
[16:25] Leonel Iceghost: or any other sports game
[16:25] Moundsa Mayo: Or even LSL cost accounting support ...
[16:26] Simon Linden: Kelly has been working on the time-slicing for scripts, and I know the last numbers were looking pretty good. There's no miracle cure, but the balance was a lot better
[16:26] Fancy Greeter: Kelly Linden has arrived!
[16:26] Kallista Destiny: well speak of the Devil.
[16:26] Pauline Darkfury: Well, if you have content like that, pretty much the only reliable solutioon is to either pay for a full sim and keep script count extremely low, or rent part of an island that has very active EM monitoring and a hugely restrictive covenant
[16:26] Techwolf Lupindo: Speak of the devel.
[16:26] Moundsa Mayo: Residents are always saying "just give us the data and let us make our OWN decisions" B^P
[16:26] Simon Linden: I should have warned him...
[16:26] Andrew Linden: Simon, that work went live this Tuesday didn't it? Or are you talking about something else?
[16:26] Kallista Destiny: laugh
[16:26] Simon Linden: I'm not sure, Andrew
[16:27] TankMaster Finesmith: hiya kelly
[16:27] Simon Linden: (both what went live, and what I'm talking about :)
[16:27] Pauline Darkfury: I've yet to do any measuring on the release that landed on Magnum on Wednesday - that has the Mono 2 perf fixes that are currently floating around
[16:27] Kelly Linden: Hello
[16:27] Rex Cronon: hello
[16:28] Simon Linden: We were just into the script time issue again ... can you update us on that and what's on the grid?
[16:28] Pauline Darkfury: My assertion that 3000 (or less) now maxes out a C5 full (down from approx 6000) is based on the current main channel release
[16:28] Kallista Destiny: ummm that was the SVC-7079 fixes, again
[16:28] JIRA-helper: http://jira.secondlife.com/browse/SVC-7079
[#SVC-7079] Simulator performance issues since server roll (2011-06-30)
[16:28] Kelly Linden: I am interested in hearing how the idle scripts test does on Magnum.
[16:28] Andrew Linden: brb...
[16:29] Kallista Destiny: K Andrew
[16:29] Pauline Darkfury: Yeah, I'm very interested in that as well, Kelly, just have not yet had time to do the test
[16:29] Kelly Linden: I did tweak one or two small things for that, but honestly it was not the focus. Sim performance and individual script performance was.
[16:29] Vincent Nacon: same here,
[16:29] Kelly Linden: so any imrovement would be a pleasant surprise but not really expected.
[16:29] Pauline Darkfury: Yes, there were more urgent issues in SVC-7079 than the timeslice / idle scripts issue
[16:30] Meeter: Timecheck : User Group is half over
[16:30] Techwolf Lupindo: Need to have scripts fire on actuall events, not polling for an event every frame.
[16:30] Andrew Linden: back
[16:30] Ramona Criss: *:::* WELCOME BACK *:::*
[16:30] Leonel Iceghost: Pauline, hare you tested the scripts necessary to put fps down?
[16:30] Kallista Destiny: yes, my comment was that the Scheduler wbears some serious looking at
[16:31] Pauline Darkfury: Yes, that's something I've wondered about, Techwolf, if improvements could be gained by maintaining 2 lists of scripts - the current "all scripts" list, and a 2nd "scripts with events pending" list. Move the per-frame iteration over to the second case, eliminate the 0.002ms for 100% idle scripts
[16:31] Rex Cronon: wb
[16:31] Vincent Nacon: nice chart
[16:32] Kelly Linden: So, that chart was the focus of the improvements on Magnum now.
[16:32] Kelly Linden: That is just SimFPS, there was also some focus on individual script performance.
[16:32] Leonel Iceghost: that would fix lots and lots of sims.. to fix the scheduller
[16:32] Pauline Darkfury: Oh, cool
[16:32] Pauline Darkfury: If I'm reading that chart properly, it looks very encouraging for the more serious issues over the last 2-3 weeks
[16:32] Kelly Linden: the graph is muddy cuz it has a lot of data (that is page 3 of the data)
[16:33] Vincent Nacon: got more on homesteads before and after?
[16:33] Techwolf Lupindo: Lower better or worse on that chart?
[16:33] Kelly Linden: The last 3 (outside the red block) are the only datasets with homesteads
[16:33] Kallista Destiny: worse I think.
[16:33] Kelly Linden: That is SimFPS so higher is better.
[16:33] Vincent Nacon: worst, it's the time dil
[16:34] Vincent Nacon: err or fps?
[16:34] Pauline Darkfury: higher is best, the chart is 42.40 FPS at the bottom, 44.80 FPS at the top
[16:34] Kelly Linden: And this is average for all regions in the Magnum RC.
[16:35] Kelly Linden: It looks promising. We will have more data points next week of course.
[16:36] Pauline Darkfury: Yup, fingers crossed
[16:36] Vincent Nacon: alrighty then, back to physic topic?
[16:36] Vincent Nacon: cause it seem Falcon is confused about density issue
[16:37] Andrew Linden: Did we have a phys topic?
[16:37] Pauline Darkfury: any comment on the suggestion above, to maintain a 2nd list of scripts in the sim, and get away from apparently iterating over all scripts, even those that have no events pending, and those that can't ever get an event unless reset?
[16:37] Vincent Nacon: https://jira.secondlife.com/browse/CTS-573
[16:37] JIRA-helper: [#CTS-573] Incorrect Prim Density Value
[16:37] Vincent Nacon: he or someone changed the label for the imput as a fix, which only make it worst in term of value
[16:37] Kelly Linden: We did that once upon a time. We stopped doing it because the overhead and bugs associated with maintaining two lists was more than just maintaining 1 list and early exiting if there is nothing to do for the script.
[16:38] Kelly Linden: It could possibly be revisited but it would be a big time investment, huge potential for bugs, and not a clear win.
[16:38] Andrew Linden: Ah yes... the density.
[16:38] Vincent Nacon: like 100kg/m^3 with 1000 input is 100,000 kg/m^3?
[16:38] Andrew Linden: The llGetMass() returns a number whose "units" are way too low.
[16:39] Pauline Darkfury: Ok, thanks, Kelly. It does look to me like it's worth at least giving high level consideration, but you've clearly got some experience with that idea already.
[16:39] Andrew Linden: Internally we use higher units, and translate for llGetMass() for legacy purposes...
[16:39] Vincent Nacon: what unit?
[16:39] Vincent Nacon: there wasn't any unit
[16:39] TankMaster Finesmith: i see its morning time
[16:39] Moundsa Mayo: troy ounces
[16:39] Kallista Destiny: lindengrams I htink
[16:39] Moundsa Mayo: (at g=1.000)
[16:39] Techwolf Lupindo: So each script object has a bool that is script is just waiting for a event, if (iter->wEvent) break;/continue;?
[16:39] Andrew Linden: Falcon introduced some density settings in the UI
[16:40] Vincent Nacon: reguadless of what unit, it's still incorrect based on density's formula
[16:40] Andrew Linden: but couldn't tolerate using more "legacy appropriate" units there... onese that would agree with the llGetMass() behavior
[16:40] Andrew Linden: so we used the internal units... which are 100 times bigger
[16:40] Vincent Nacon: but that's not... right
[16:41] Andrew Linden: yeah, something has to give
[16:41] Vincent Nacon: you'll have to either fix density or mass
[16:41] Moundsa Mayo: Different universe, different physical constants. I *know* Planck's is way different here!
[16:41] Kallista Destiny: how about Avatars, what density do they have?
[16:41] Griefer Evermore: some are very dense
[16:42] Rex Cronon: we sink, therefore we r heavier than water
[16:42] Vincent Nacon: they have density of something lighter than unknown gas
[16:42] Object: ============
Vincent Nacon is...
Height: 1.386509 meter. (4 feet, 7 inches)
Ideal Weight: 70.062410 kilogram. (154 lbs)
Mass: 1.655052
Density: 1.198930 gm^3.
NOTE: This is all secund of meter with Linden's metric.
========================
[16:42] Andrew Linden: oy... I don't remember the details but avatar density is messed up in another systematic way...
[16:42] Moundsa Mayo: Depends on whether they are sitting or not, too.
[16:42] Vincent Nacon: see? I have 1.1 density, too light to be gas
[16:43] Kallista Destiny: I ask becasue scales are somethin that my pirmary uses and hand to hack seerly
[16:43] Andrew Linden: I think avatar density is artificially high, to make them less "pushable" by in-world objects, if I recall correctly
[16:43] Pauline Darkfury: (not sure if you've got Moon's latest particle graph, Kelly. That's it there in the corner. The new green trace is the measured timeslice, i.e. suggesting that scripts are running at approx 70% speed here right now)
[16:43] Vincent Nacon: so the mass is incorrect?
[16:44] Kallista Destiny: OMG My primary so needs that
[16:44] Griefer Evermore: That's a handy graph
[16:44] Kelly Linden: well, this is Le Tigre I believe, not Magnum.
[16:44] Kallista Destiny: /sysinfo
[16:44] Andrew Linden: "correct"? what is correct is debatable here unfortunately...
[16:44] Pauline Darkfury: indeed, Kelly, just wanted to look at current perf here for curiosity's sake
[16:44] Object: ============
Vincent Nacon is...
Height: 1.386509 meter. (4 feet, 7 inches)
Ideal Weight: 70.062410 kilogram. (154 lbs)
Mass: 1.655052
Density: 1.198930 gm^3.
NOTE: This is all secund of meter with Linden's metric.
========================
[16:45] Vincent Nacon: see my mass and density?
[16:45] Andrew Linden: but "correct" in a sense that maps with the real world? definitely incorrect
[16:45] Object: ============
Chaley May is...
Height: 1.482347 meter. (4 feet, 10 inches)
Ideal Weight: 77.792510 kilogram. (172 lbs)
Mass: 1.837657
Density: 1.196540 gm^3.
NOTE: This is all secund of meter with Linden's metric.
========================
[16:45] Vincent Nacon: you said we have high density but we have around 1
[16:45] Vincent Nacon: that's not high
[16:45] Object: ============
Chaley May is...
Height: 2.146069 meter. (7 feet, 0 inches)
Ideal Weight: 77.792510 kilogram. (172 lbs)
Mass: 1.837657
Density: 2.224129 gm^3.
NOTE: This is all secund of meter with Linden's metric.
========================
[16:45] Vincent Nacon: normap prim has density of 10
[16:45] Vincent Nacon: normal*
[16:45] Andrew Linden: Oh ok. Well nevermind then. My memory fails me on the details there.
[16:46] Vincent Nacon: wooden block is lighter than gas... so is avatars
[16:46] Vincent Nacon: :/
[16:46] Vincent Nacon: in fact...
[16:46] Moundsa Mayo: Yah, Einstein said "never memorize anything you can look up"
[16:46] Vincent Nacon: no matter what units we use.... we're too damn light
[16:47] Techwolf Lupindo: Intresting item on kelly chart, sim perforamce goes down over time untless there is a rollout of a new version.
[16:48] Pauline Darkfury: Ahh yeah, it does kinda suggest that, Techwolf, interesting observation, although not entirely surprising to someone who actively manages heavier-loaded regions
[16:49] Simon Linden: We tend to see that for a lot of different stats ... they slowly degrade over time, and a re-start clears things up.
[16:49] Kadah Coba: Likely just the mass resetart palying with the averages
[16:49] Kelly Linden: Yeah, the avg drops by maybe 0.3FPS over a week, judging by that chart.
[16:49] Pauline Darkfury: Yes, Simon, there's a lot of us feel that the grid as a whole has much better performance since the weekly restarts came in
[16:50] Object: Hello, Avatar!
[16:50] Leonel Iceghost: Its a trick so we allways feel the new release good
[16:50] Rex Cronon: messy pointers?
[16:51] Kallista Destiny: Combat regions usually reset after a big fight
[16:52] Simon Linden: Several people have looked into that phenomenon before, and we haven't figured out why it degrades like that ... both performance and crash rates tend to get worse over time. It's not just a simple memory leak or starving the server of resources
[16:52] Andrew Linden: There may be some memory leaks in there, but they aren't big -- the slow degradation over time can also happen from "memory fragmentation".
[16:53] Kallista Destiny: you mean garbage collection in the malloc routines? or lack thereof?
[16:53] Ultimate Flight Band: All Go
[16:53] Andrew Linden: I was talking to a friend programmer who doesn't work for LL, and he was telling me about their per-frame memory blocks
[16:53] Pauline Darkfury: yeah, that theory works as well, Andrew. With lots of allocation & deallocation, eventually the actual CPU can run out of slots in units such as the TLB to keep all of the page mappings it needs for its most active workloads
[16:53] Andrew Linden: which they use to avoid memory fragmentation and not worry about memory leaks.
[16:53] Rex Cronon: they use c++. no need for malloc. i suppose
[16:54] Kallista Destiny: it's there somewhere, hidden from view
[16:54] Andrew Linden: It was a neat idea, but it would be hard to port all of SL into that paradigm at this stage...
[16:54] Andrew Linden: too bad
[16:54] Andrew Linden: well, actually the were using just plain old C...
[16:55] Meeter: Timecheck : User Group is almost over
[16:55] Pauline Darkfury: doesn't matter what language you use, Rex, there are hardware limits inside the CPU and hardware memory mapping silicon. Once you have a lot of memory frag, you run out of those resources, and the kernel has to work harder on each context switch, on average
[16:55] 1Justin1: hey
[16:55] Kallista Destiny: Hi 1Justin1
[16:55] Rex Cronon: hi
[16:56] Ramona Criss: hi 1Justin1
[16:56] 1Justin1: hi how are ya all?
[16:56] Pauline Darkfury: Efficient malloc, whether that's exposed in the high level language being used, or not, is one of the holy grails of high performance computing
[16:56] Vincent Nacon: tired and cranky but I'm feeling great. :D
[16:56] Kallista Destiny: Amen to that
[16:57] Moundsa Mayo: Yah, there needs to be a sliding window scheme that rolls a recovery aperature through the MMU as it operates.
[16:57] 1Justin1: ah haha good
[16:57] Moundsa Mayo: I don't know what tht means, it was just the best I could make up in a limited amount of time.
[16:58] Kallista Destiny: One of the problems with c++ is that it hides little details like that from everyone and sometiem you just donlt know how good or bad the actuall code is
[16:58] Andrew Linden: heh. pseudo computer science
[16:58] Kallista Destiny: Yeah but we all understood wnat you ment
[16:58] Kallista Destiny: CG is critical
[16:59] Pauline Darkfury: yes, the high level languages can often hide the detail, making it very hard to see if there's actually an issue or not
[16:59] Moundsa Mayo: For marketing purposes it could be called 'phantom dynamic garbage collection"
[17:00] Meeter: Thank you for coming to the Server User Group
[17:00] Kelly Linden: Have a good weekend!
[17:00] Kelly Linden: o/
[17:00] Moundsa Mayo: Andrew, Simon, Kelly, thank you for your time!
[17:00] Pauline Darkfury: Thanks, Lindens, have a good one :)
[17:00] Chaley May: bye :)
[17:00] Simon Linden: Thanks everyone for coming today
[17:00] Ramona Criss: was so short loll
[17:00] Rex Cronon: u 2 kelly
[17:00] Vincent Nacon: you're welcome meeter, thank you for coming.
[17:00] Liisa Runo: thanks everyone
[17:00] Kallista Destiny: Thank you all for an , as always, very intereting meeting.
[17:00] Rex Cronon: tc simon
[17:01] Rex Cronon: tc everybody
[17:01] TankMaster Finesmith: Take care kelly, andrew
[17:01] Rex Cronon: and havea nice day/night/morning/afternoon...
[17:01] Rex Cronon: :)
[17:01] TankMaster Finesmith: and simon
[17:01] Andrew Linden: See you all later.
[17:01] Ramona Criss: lol Rex
| Prev 2011.07.19 | Next 2011.07.22 |