cr1901_modern has quit [Ping timeout: 255 seconds]
cr1901_modern has joined #solvespace
wpwrak has quit [Ping timeout: 245 seconds]
wpwrak has joined #solvespace
<wpwrak>
translating has worked remarkably well, so i halfway expected that there could be some karmic retribution :) in fact, thinking of it, i imported some assembles twice instead of using translation. should probably have used translation. alas, they're in "old" groups, so impossible to change now
<whitequark>
I've never seen anything like this bug before and it's not really in my area of exertise
<wpwrak>
yeah, it seems to be the sort of nasty things you sometimes get with graphical algorithms, e.g., when some small numerical instability causes things to go haywire
<wpwrak>
let's hope evil-spirit can find the what's going on. this is a real blocker for what i'm doing :(
<ohsix>
i had a horrible problem earlier where no workplane would work, everything was drawn in 3d, after restart everything worked normally again :]
<ohsix>
tool window showed the right workplanes and the menu was showing draw in workplane, but nothing
<wpwrak>
eek :)
<ohsix>
luckily it seemed immediately bizarre enough that i restarted pretty quick and could continue
<ohsix>
whitequark: someone else in the lab has taken initiative to learn solvespace and the 3d printer, it's pretty cool
<whitequark>
nice
<ohsix>
parametric modeling is hard
<d42>
let's go shopping
<wpwrak>
i like the 2d part of slvs very much. once you've mastered the basics (which are not that difficult), it makes it look easy :)
<ohsix>
earlier i was trying to put a workplane on the face of something i could just have extrude the other direction and use the original work plane :p
<wpwrak>
then the next plateau of the learning process are groups, which introduce a "data diode" for constraints and require you to develop a suitable workflow. plus, at that point you lose the previous ability to easily from A to B. i.e., if in a sketch you did something the wrong way, you just rearrange that area. with groups, if the depenency tree is wrong, there's often no easier way than to undo an then redo lot of work.
<wpwrak>
and the final plateau seems to be assembly, where you have to fully master 3d space, in addition to all before. and that's also when performance issues begin, at least at the moment.
<whitequark>
that sounds quite right to me
<wpwrak>
i wonder how much that "data diode" is really needed. it seems that slvs doesn
<wpwrak>
't make full use of the optimization potential there yet. which in turn suggests that, once it does, perhaps some "feedback" could be allowed without slowing things down too horribly.
<whitequark>
all of it... this is what keeps generation tractable
<wpwrak>
well, slvs doesn't seem to do too badly if you have a single complex group. so two simple groups where the "data diode" between them is lifted ought to be fine as well.
<whitequark>
you're thinking of best case and I'm thinking of worst case
<wpwrak>
ah, speaking of recalculation: when editing a group that's early on the list, do dependent groups (or parts of them, e.g., the geometry but not the meshes, or such) get recalculated after each change or only when they get activated ?
<whitequark>
50/50
<whitequark>
the entire stack gets re-solved but the groups after the active one don't get mesh computed
<wpwrak>
hehe ;) i guess some "number of dependencies" meter could be useful to guide designers, and to keep them from merrily constructing themselves into combinatorial explosion
<whitequark>
or prevent that by construction, which is done right now.
<wpwrak>
(recompute) ah, that's what i though. how about making the re-solving optional ?
<wpwrak>
well yes, but that restriction has a high cost in terms of usability
<whitequark>
definitely not until chirality lands
<wpwrak>
(lands) you mean the cluster of changes around the new file format ?
<whitequark>
no, I mean it requires chirality
<whitequark>
if we don't resolve after every small change, the later groups will get mangled after a big one
<wpwrak>
ah, i see
<wpwrak>
well, it wouldn't if the big one consists of many small ones. e.g., if adjusting tolerances and such. so it may still be useful to have this as an option.
<whitequark>
I don't think an option that is almost guaranteed to result in broken sketches is useful to have
<wpwrak>
i'm thinking of cases like: 1) design an expermiental version, 2) print/mill, 3) fix all the mistakes you find. step 3) can often involve lots of tiny changes, all over the list of groups. so it's unpleasant if they're slow.
<whitequark>
mostly it's the mesh generation
<whitequark>
have you tried turning off the mesh display and turning on all hidden lines?
<whitequark>
the solver shouldn't be slow on your sketches at all, it's mostly visible when doing e.g. extremely large 2d sketches
<wpwrak>
i generally turn on all hidden lines. i have the mesh on, too, though. so i'll try without that once.
<wpwrak>
i also have the dragging lag overlaying everything (remember the video where i could spin the mouse without the line ever moving). so that's a confusing element.
<whitequark>
right, did we ever figure out what was the cause?
<whitequark>
does x11 still consume outrageous amounts of CPU?
<wpwrak>
ah, in terms of performance: instead of the super-optimistic fps indication, how about displaying time between last user input and completion of resulting the operation ? (not sure if this would be easy to determine)
<d42>
super optimistic fps indicator seems like a decent ballpark imho :^)
<wpwrak>
(cause) you once said that you could reproduce it under some for you unusual configuration (was it vnc ?)
<ohsix>
whitequark: is there any operation that is known to be dog slow with extruding curves; when i import a dwg with a few (50?) curves/edges the interaction speed really falls off when i'm moving the extrusion
<wpwrak>
d42: you mean, everybody does that ? ;-)
<whitequark>
wpwrak: the fps indicator simlpy has a different purpose
<whitequark>
we used to have immediate mode rendering, which is extremely slow, and some bottlenecks in the VBO rendering
<whitequark>
we don't have that anymore and it can probably just be removed
<whitequark>
ohsix: try lowering chord tolerance
<ohsix>
whitequark: k, don't have any at hand but it happens often enough, will do
<wpwrak>
whitequark: yeah, rendering seems to have excellent speed. but i think a "response time" indicator could be useful for chasing bottlenecks. at least i found that very helpful in eeshow (where i try very hard to be inefficient, but rarely succeed in getting the user to notice. so much about all that experience with optimizing on 1980es hardware :)
<whitequark>
wpwrak: what I would rather like to see is to move all heavy operations (really, all operations) off hte UI thread
<whitequark>
now *that* would be useful
<wpwrak>
you mean to exploit multiprocessing ?
<whitequark>
no
<whitequark>
the UI thread (the one that runs gtk) would handle only the rendering and input
<whitequark>
the backend thread would do regeneration
<whitequark>
this is essentially 'as fast' as currently but the interface will have a soft-real-time characteristic in its response
<whitequark>
(most people aim at processing input at 60fps these days)
<whitequark>
well, 60 Hz
<wpwrak>
hmm, not sure how to imagine that. to me it would seem that things that don't need much computation should be fast in any case, and if they need computation, that would be part of the feedback, so it has to be synchronized anyway
<whitequark>
regeneration blocks the UI
<whitequark>
right now I can't even show a progress bar
<whitequark>
much less provide any way to cancel a long operation or anything
<ohsix>
withotu cancelling i could have used some progress bars today :p
<whitequark>
and anyway, 'fast' is stretchable. if it doesn't finish in 16.5ms then it's not fast
<ohsix>
message loop ui stall looks not good on windows, an operation that takes a few seconds has people clicking all over expecting it to work, then it starts working again -> mess
<wpwrak>
ah yes, a "cancel" button could be useful :) e.g., when exporting a mesh with small chord tolerance. slvs is rather unforgiving even at settings that seem reasonable.
<ohsix>
i'm generally happy tho, consider this not clammoring ;]
<wpwrak>
ohsix: if (elapsed_some > 1 s) flush_input_queue();
<wpwrak>
meh. elapsed_time
<whitequark>
no.
<whitequark>
oh, flush in the sense of empty
<whitequark>
that's still really awful.
<ohsix>
windows apps do that pretty regularly but it is gross
<ohsix>
need to decouple ui/input thread like he mentioned already
<wpwrak>
whitequark: yeah, probably. it may just work, though, once you get used to it :)
<ohsix>
on android there's actually a warning if you do work on the ui thread
<ohsix>
software sucks, doign something right is always such a massive pile of work
<whitequark>
not that much if you do the design right in the first place
<whitequark>
slvs would have been so much better had it been written in rust. not because rust is inherently better but because it constrains you such that the most convenient way to write code also works well with threading
<wpwrak>
that's thinking that quickly leads to a lot of regret ;-)
<whitequark>
you *can* do the same thing in C++ (in fact I'll have to) but most people don't bother
<whitequark>
brushing your teeth vs getting ten implants at 45, pretty much :p
<wpwrak>
freshly impoverished dentists, welcome to the underclass
<wpwrak>
(drag lag) X11 gets 20%, slvs about 8%. some ~10% background load
<whitequark>
ok, that sounds more or less what should happen
<whitequark>
weird.
<wpwrak>
that's for "dragging" a line (which doesn't move unless i stop moving the mouse) after File > New
<wpwrak>
another weird effect is that, if the line is "in stasis", H and V constraints still are shown immediately and at the right place
<whitequark>
yes. this is very weird.
<whitequark>
hm, I think I know what could help.
<whitequark>
wpwrak: ok, that code isn't ported to linux yet
<whitequark>
wpwrak: can you rig up gdb so it shows the backtrace every time PaintGraphics or InvalidateGraphics is entered?
* wpwrak
snivels
<ohsix>
i have just the thing!
<whitequark>
a macro or something, pretty sure you could do this
<whitequark>
anyway also pipe that to a file, or your terminal emulator may slow things down
<whitequark>
I was thinking f perf but didn't immediately know if it has that capacity
<ohsix>
perf rules heh
<ohsix>
i tried to use systemtap and oprofile a few times but perf just worked :<
<ohsix>
and ftrace can do a lot
<whitequark>
systemtap works pretty well but I don't think it can do backtraces
<whitequark>
not easily at least?
<whitequark>
it has some weird view into the process
<ohsix>
yea it looked good but i never built a kernel just to run it, or used a distro that supported actually running it with the debug information they ship
<ohsix>
perf comes with the kernel so i can just tell people to go use it for stuff
<whitequark>
huh? debian let me run systemtap trivially
<ohsix>
nice
<ohsix>
tbh i dunno a whole swath of things that may have just been ubuntu problems, because it was a pain in the ass to do it on ubuntu
<ohsix>
will have to check it out on debian
<ohsix>
ftrace can do almost everything i would do with systemtap, tho
<wpwrak>
hmm, never used perf. lemme see ...
<wpwrak>
meanwhile, just a thought: would it be possible to use a small chord tolerance for lines in sketches ? i.e., in the order of a few pixels. to avoid those confusing situations where chords of a large arc/circle are drawn far from the points that lie on them
<whitequark>
wpwrak: the display chord tolerance cannot be expressed in relative units, like pixels
<whitequark>
then it will depend on zoom level, which is even worse
<whitequark>
you cannot regenerate on every re-zoom, that's too slow. so you zoom out, regen, zoom in and have the exact same effect
<wpwrak>
whitequark: i mean, for arcs/circles, it's just an arc/circle or, worst case, ellipse. even if it only works for an orthogonal view (so you don't need to deal with ellipses), that would be a great improvement
<whitequark>
wpwrak: then it won't match extrusions though.
<wpwrak>
would one even notice ? i mean, solids are mere shadows at that point
<whitequark>
uhm, yeah? or do you suggest having yet another representation for non-sketch-in-plane groups?
<whitequark>
yes. I understand what are you talking about.
<whitequark>
I just think the fix you propose makes behavior more surprising along corner cases
<wpwrak>
the point that's floating above the chord is conincident. if you have lots of points in a design, it can get pretty hard to guess which og the off-arc points are actually on it
<whitequark>
well, I guess for *this* one there is some sense in having an option
<wpwrak>
i can't actually imagine when this would be a problem. i mean, even if i wanted chord tolerance to be part of my design, then i'd rather have coincident points aligned with the chords, not the ideal arc. so there's a disconnect no matter how you look at it. and designing for a specific chord tolerance seems a little dangerous anyway.
<ohsix>
hm trying to reproduce the slowness, imported the outline of oregon from a pdf (via dxf,) solvespace added h/v constraints and i don't remember if it did before, and if it did, how i made it not do that or how i deleted them all (there are a few hundred)
<whitequark>
try importing in 3d
<ohsix>
not in a workplane?
<whitequark>
yeah
<ohsix>
if the hide options had a hide lines, i could select just the constraints :>
<ohsix>
huh, ok that seemed to work, and i may have done that before but not deliberately :o
<ohsix>
how do i get it in a workspace after that, export / import diff format?
<whitequark>
hm?
<ohsix>
copy only works in a workplane
<ohsix>
or so says the popup when i try
<whitequark>
yeah
<ohsix>
ah i think i remember, i simplified the edges and this wasn't a problem
<ohsix>
simplified before i imported that is
<ohsix>
right now it has like 4000 parts and the tool pane says 'too many unknowns in a single group', it's two contours i need to close, but if i try and draw a segment (s) it only drops one vertex and the tool stops
<ohsix>
aaaa every mouse move is being entered into the undo history too
<ohsix>
OR, i can figure out how to use inkscape, but that is boring
<whitequark>
yes, right now solvespace doesn't do well on extremely large 2d sketches
<whitequark>
like I mentioned we need eigen for that
<wpwrak>
mmh. not getting output that looks very useful from perf. not sure if it even really works on ubuntu. things like this don't look promising: stop: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<wpwrak>
let's try gdb
<ohsix>
whitequark: yea i'm trying to reproduce slowness, i get it; also math dumb so mentioning some stuff can just go right over my head :p
<whitequark>
ohsix: eigen is just a library
<ohsix>
linear solver right?
<ohsix>
what would it do that currently isn't being done, or is it something to just augment it to make those decisions much cheaper
<whitequark>
sparse matrices
<whitequark>
the latter
<ohsix>
oic
<ohsix>
well, i sort of get it but can't ask any more useful questions about it huhu, like why they are sparse or large
<ohsix>
one simplify step changed (after import) objects from 4500~ to 378 :o
<whitequark>
they're large because you have a lot of unknowns
<whitequark>
every point has 2 (or 3) degrees of freedom
<whitequark>
so that's like a 8000x8000 matrix at *least*
<whitequark>
they're sparse because almost every element is zero
<ohsix>
k i reproduced slowness, thoguh it is much faster than i remember already
<ohsix>
ah
<ohsix>
the part where i get lost is how those degrees of freedom get stuck into the matrix :p
<ohsix>
how do operations on sparse matrices work, are the zeros just skipped
<ohsix>
i sort of get why it is slow, but i'm curious if anything can even be done about it
<ohsix>
solvespace actually does the csg itself right? not using stencil buffer hax you can do with gl
<whitequark>
solvespace doesn't use csg
<ohsix>
(i mean, it would have to do both to save the model, but you can cheat displaying it)
<ohsix>
what's it doing when you intersect volumes?
<ohsix>
'solid model as' union/difference/assemble
<whitequark>
nurbs or mesh operation
<ohsix>
hm i'd call that csg, what is the distinction?
<whitequark>
it doesn't use primitives
<whitequark>
the extrude/lathe operations generate the corresponding nurbs directly
<ohsix>
hm
<ohsix>
primitives would be like a sphere? and csg is just an implicit thing you do between say, a sphere and a cylinder
<ohsix>
i have an older book on writing 3d modelling programs, it called the principle of intersecting objects CSG, it's probably also a specific method
<whitequark>
CSG modeling packages give you a limited number of primitives: cuboids, spheres, etc, then allow you to combine them
<whitequark>
solvespace doesn't have the primitive part
<whitequark>
it also has fewer boolean operations. no xor.
<ohsix>
k that makes sense
<ohsix>
they do cover nurbs and splines and their intersection but they don't make a distinction between what they introduced before
<ohsix>
don't want to bug you on twitter to ask, the llvm build time, how much memory is in that machine?
<whitequark>
it's CPU-bound
<whitequark>
it's so CPU-bound it reliably brings my laptop into thermal throttle
<ohsix>
i got 16gb in my laptop recently and i feel really stupid about how slow it used to be, all the disk io stays in ram
<whitequark>
but yes, the amount of memory is 12GB
<ohsix>
right
<ohsix>
cool
<whitequark>
it doesn't matter until linking
<whitequark>
for linking I have 12GB of swap
<whitequark>
also hibernation
<ohsix>
that will take forever :D io through page reclaim is sub 1MB/s
<whitequark>
for the twitter tab in chromium, primarily
<wpwrak>
is this format useful ?
<whitequark>
otherwise it becomes an OOM massacre
<ohsix>
nice
<ohsix>
yea i've tweeted a few times about going back a few hours is a few gigs
<whitequark>
wpwrak: yes. this is exactly what I wanted
<wpwrak>
kewl :)
<whitequark>
let me fix this LLVM codegen issue and I'll look at it...
<ohsix>
but my hard drive is practically unused compared to what it was doing before, almost no io touches the disk even when i'm working with huge files, i'm astonished really
<whitequark>
I use an SSD anyway so the difference isn't anywhere as dramatic
<ohsix>
not with intent to big it up, but gnome shell is really nice when it isn't hitting disk for things; starting and jumping around programs that are open looks like some minority report shit
<whitequark>
with an SSD I can just not care if I drop my laptop on the floor or something
<ohsix>
if it hits the disk even a little to load app icons it is not fun
<whitequark>
sounds like it needs preloading and nonblocking IO
<whitequark>
the lack of true nonblocking IO in linux is obnoxious
<ohsix>
maybe
<whitequark>
(since you cannot use O_NONBLOCK with files on disk)
<ohsix>
they dno't load impostors while files are loading
<ohsix>
when you have a cold cache, it just has to touch a lot of stuff on disk
<ohsix>
they should/could probably index them a better way
<wpwrak>
a(sync)io ?
<ohsix>
when there was only 4g in this machien tho, they were never resident, since chrome is a beast and stuff they'd get evicted in preference for other more often used files
<whitequark>
wpwrak: it doesn't work
<whitequark>
it spins up background threads
<whitequark>
you can't use that with epoll and such
<whitequark>
well, the glibc AIO implementation specifically
<ohsix>
the aio library in glibc you mean?
<ohsix>
k
<whitequark>
not that other OSes fare better
<whitequark>
I think maaybe solaris had a true impl? not sure
<ohsix>
is the posix model for aio actually useful or is it one of those poop things
<wpwrak>
mmh. there ought to be also real async io. at least the bangalore group from IBM was very busy on it some years ago
<ohsix>
trying to think what async would actually mean in practice if it was added to linux
<whitequark>
it is one of those poop things, largely
<whitequark>
well
<whitequark>
it's a design similar to WinNT IOCPs
<ohsix>
there's a block io scheduler already, wouldn't there then have to be another scheduler? or would it just be implicit round robin, or implicit plus existing io priority
<whitequark>
this isn't bad in itself but the world has moved to abandon those through no fault of its own
<ohsix>
yea i'm familiar with iocps
<whitequark>
now if you do AIO in linux you use epoll
<whitequark>
so any disk AIO must also use epoll
<ohsix>
you mean multiplexing multiple file descriptors?
<whitequark>
you actually don't need that much changes API-wise, just expose readiness of disk FDs
<whitequark>
I mean it must integrate with existing event loops
<ohsix>
sure
<ohsix>
in linux land you'd probably get another fd that would signal for 'write finished' or something
<ohsix>
which isn't super disimilar to iocps
<whitequark>
huh?
<whitequark>
no
<whitequark>
just make the *existing fds* signal readiness correctly
<whitequark>
instead of being always ready so long as the file's on a disk
<ohsix>
they can only be signalled for one thing, how does the kernel decide it means something about the state of the page writeback
<ohsix>
the fd's are pretty quickly decoupled from 'this file' that the application opened, in the kernel
<whitequark>
a) it works for sockets
<ohsix>
heheh it sort of does
<whitequark>
b) at least you have read and write readiness
<whitequark>
so two things
<whitequark>
and that's all the things you need
<whitequark>
and even the read AIO would be enough
<ohsix>
on windows there's more than one thing that it means to be alerted, and you can't know which withotu jumping out of the socket apis
<whitequark>
like, make the fd ready-read when there is a nonzero amount of stuff after the seek position in the cache
<whitequark>
that's it
<whitequark>
that's everything you need
<ohsix>
write readiness on sockets is about a scarce memory resource associated with the socket, what does it mean for the file, would you set a watermark or something for outstanding uncomitted pages, and when it is signalled does it mean the pages are on disk (fdatasync)
<whitequark>
write AIO doesn't make a whole lot of sense
<whitequark>
read AIO can use the readahead syscall
<ohsix>
ok right i was thinking about what you said with the file position when i said 'this file', think about writev and discontiguous access, that's more like what actually happens after the kernel is entered for write(), only the fd that's part of the process has file pointers, and they're just pages quickly thereafter
<whitequark>
yes, if you wanted to read from multiple positions at once you'd have to get an fd per position
<ohsix>
anyways i'm talking around what i was going to say eventually, mmap io is 'better', in that you can control writeback of individual pages to some degree, and other things like whether the pages are important or not
<whitequark>
mmap has many other problems though
<whitequark>
faulting is slow, and you get even less control over it than with blocking io
<ohsix>
if there was an aio impl i'd want to be able to query file ranges, and for some stuff like msync and madvise to have more rigid 'do what i'm asking'
<ohsix>
right
<whitequark>
sequentially reading a mmapped file is slower than with read()
<whitequark>
so for the icons use case? mmap is out
<ohsix>
i think i've tested that and found the opposite
<whitequark>
there was mmap support in grep, and it was removed because it slowed things down
<ohsix>
the kernel will readahead mmap like it does with a normal file, opportunistically grabbing more on a fault, but yea the fault is slow
<whitequark>
it might have been sequentially reading many small fils
<ohsix>
yea i heard about that, what i was doing wasn't grep
<ohsix>
most of the time not all parts of the file are useful/important at the same time
<whitequark>
segfaults also don't compose
<whitequark>
SEH would help here...
<ohsix>
you can also use madvise to tell the kernel what you're going to do with that region, but what the vm will actually do is vaguely defined
<ohsix>
basically the position i'm coming from is ways to inform the io subsystem about what you're actually doing so overall it can opportunistically speed that up
<ohsix>
in the other direction, madvise can tell the kernel that the file io isn't random, which is taken to mean that readahead won't be beneficial, and you save that load in the actual vm/disk
<ohsix>
you can tell the kernel that some pages are less important, and page reclaim will take them if it needs to, the only penalty being that it might fault in the future
<ohsix>
i'm not a KISS guy but i can only imagine how nutty it would get to do it for 'real'
<ohsix>
oh well, not going to litigate the past; buuuuuuuuuuuuut should one add the option back in the interest of measuring it, perf can do it! :]
<ohsix>
hrm in the case of aio, is the only real difference in your use, having a real fd to be signalled in the event loop?
<whitequark>
the ripgrep author has got similar results btw
<whitequark>
on modern linux
<ohsix>
sure but it's not likely due to sequential reads, the vm will readahead in the mmap and write case, setting up the mapping is expensive tho, so if you mmapped a file that was like, smaller than 64k it'd be much slower
<ohsix>
first fault is expensive too
<ohsix>
one of the disk benchmark tests supports alternately using mmap, so you can compare it for arbitrary file sizes, and blktrace can show you the io patterns while it is going on
<ohsix>
aaaaaaaaaaaaaaaaaaaaaaaaaah i see a killer in the glibc aio impl, threads have stacks, and creating a thread just to get notification does not scale and sucks real bad
<whitequark>
correct
<ohsix>
i was trying to concieve of a performance benefit
<ohsix>
whitequark: so is there anything pathologic about what slow.slvs is doing?
<whitequark>
haven't looked yet
<ohsix>
k, i should use perf to just look at it ;]
<ohsix>
also re: aio, you could implement it by passing through barrier tokens, something that is thrown away by the disk driver but goes through the vfs/vm and you can get alerted when it has passed a certain stage
<GitHub>
[solvespace] wpwrak commented on issue #177: @Evil-Spirit: by the way, with the version I use for actual work, which is a mix of master, DISPLAY_TEXTWND, your two performance enhancements, the #186 fix, and explorability enhancements, I get only 11 naked edges:... https://github.com/solvespace/solvespace/issues/177#issuecomment-277453029