Back
[11:53:39] <micges_work> micges_work is now known as micges
[15:15:00] <jepler> cradek: does this doc correction lok oOK?
[15:15:02] <jepler> http://pastebin.ca/1831959
[15:17:39] <cradek> it is correct, but I wonder if it might cause people to ask about diameter mode
[15:18:09] <jepler> I put that bit in because Andy Pugh already asked if CSS was affected by diameter mode
[15:18:10] <cradek> I'm struggling to come up with good words
[15:18:26] <cradek> I'm not sure what that question even means
[15:19:19] <cradek> if it used the gcode "X" word in a naive formula that assumes X means radius (or diameter) it would sometimes be wrong -- I think the question is whether we have this problem
[15:21:25] <cradek> "If the machine coordinates, offsets, and tool lengths are set in such a way that X=0 is the center of rotation, G96 mode will give the programmed surface speed no matter whether the G code is in radius or diameter mode."?
[15:22:04] <cradek> (talking about X=0 because that's the only one that's clear considering how X can mean different things)
[15:23:06] <jepler> Is that instead of or in addition to the text I already added?
[15:23:32] <cradek> it's only a suggestion that you should take if you think it's more clear
[15:24:10] <cradek> I'm afraid it has too many words, but I think it does answer all the questions
[15:29:25] <jepler> "When using G96, ensure that X0 in the current coordinate system (including offsets and tool lengths) is the center of rotation or emc will not give the desired spindle speed. G96 is not affected by radius or diameter mode.
[15:29:30] <jepler> "
[15:29:50] <cradek> sounds great
[15:29:58] <jepler> really?
[15:30:06] <cradek> sure
[15:32:21] <jepler> ARGH, I thought NURBS were out of the documentation.
[15:37:09] <JT-Work> did we drop NURBS?
[15:38:04] <cradek> they don't work
[15:38:30] <JT-Work> ok, didn't know
[15:45:32] <CIA-2> EMC: 03jepler 07v2.4_branch * rc9981698411d 10/docs/src/gcode/main.lyx: NURBS is so broken it's not worth documenting
[15:45:40] <CIA-2> EMC: 03jepler 07v2.4_branch * rc2c7bcac8eb3 10/docs/src/gcode/main.lyx: improve G96 discussion
[15:45:57] <jepler> it's too bad; the documentation for the feature looked pretty good
[15:50:58] <jepler> oops, I haven't been automatically updating the emc 2.4 documentation online!
[16:01:47] <aystarik> cradek, what code to test rotation_xy on?
[16:02:05] <cradek> aystarik: use systems.ngc
[16:02:13] <cradek> rotate and offset each system differently
[16:04:59] <aystarik> cradek, I don't see rotation code in systems.ngc, should I insert one?
[16:05:41] <cradek> sure, or just use mdi to rotate the various systems
[16:08:53] <aystarik> btw, G-code quick reference does not mention it.
[16:18:51] <cradek> it does have G10 L2 ... R
[16:19:20] <cradek> (but it also has L20 ... R which I think is an error)
[16:30:20] <aystarik> ok, one more optimization patch.
[16:35:35] <cradek> does it make a difference?
[16:36:53] <aystarik> don't know. probably will depend on what you are trying to rotate...
[16:38:12] <aystarik> for quite complex engraving it should make difference...
[19:26:21] <jepler> with a rotation (g10 l2 p1 r180) that patch decreases load time from 5.8 to 5.4 seconds, taking the best of 10 runs for each version.
[19:26:34] <jepler> time axis-remote --reload
[19:37:48] <aystarik> still 0.4/6 ~ 7% :)
[20:02:37] <aystarik> jepler, 180 might be easy sin/cos calc. try with 50 or something :)
[20:09:51] <jepler> I think that :) means you're joking .. I don't think there'd be a measurable difference.
[20:10:16] <cradek> well I thought that about this change...
[20:15:54] <aystarik> well, if you say that engravers are not EMC auditory, and if program does not load for them, they should drop it...
[20:16:14] <cradek> whu?
[20:16:20] <jepler> Avoiding Python function call overhead is often an effective optimization technique.
[20:16:23] <jepler> $ python -mtimeit -s 'import math; sin=math.sin(math.radians(30))' '3.0*sin'
[20:16:25] <jepler> 1000000 loops, best of 3: 0.269 usec per loop
[20:16:28] <jepler> $ python -mtimeit -s 'import math; th=math.radians(30)' '3.0*math.sin(th)'
[20:16:31] <jepler> 1000000 loops, best of 3: 1 usec per loop
[20:16:33] <jepler> $ python -mtimeit -s 'import math; th=math.radians(30)' 'math.sin'
[20:16:36] <jepler> 1000000 loops, best of 3: 0.27 usec per loop
[20:16:38] <jepler> $ python -mtimeit -s 'import math; sin=math.sin(math.radians(30))' '3.0*sin
[20:17:03] <jepler> multiplication on its own and lookup of math.sin on its own are each .27, so that leaves the function call as nearly half of the time in the middle test
[20:17:48] <cradek> huh, I obviously don't know how to program in python
[20:18:21] <aystarik> it's possible to move rotate_and_translate down into gcodemodule
[20:19:22] <jepler> aystarik: you may be confusing "the audience of EMC" with "the audience of AXIS". There are other GUIs (touchy, tkemc) which don't load a preview and so don't have the associated slowdown related to program size
[20:19:24] <aystarik> all the interpret.py essentially might go there...
[20:20:21] <aystarik> touchy is not yet released. and it requires hardware buttons to work.
[20:20:22] <jepler> but talking of AXIS for a moment, how much speed increase do you need before the time to load a part program doesn't bother you anymore? Is it possible to get there with a handful of these micro-optimization type patches (a 50% speedup in all), or does it need to be a 5x or 10x speedup?
[20:20:41] <aystarik> tkemc is old
[20:21:26] <aystarik> right now, AXIS *breaks* on the program I published here.
[20:21:53] <aystarik> I had to limit number of arc splits to allow it to load.
[20:22:39] <aystarik> under a minute is quite tolerable.
[20:23:03] <aystarik> Right now 2.3.4 and 2.3.5 spend 3-5 minutes on some code.
[20:27:01] <micges> aystarik: what program?
[20:28:17] <jepler> 14:41:26 <aystarik>
http://filebin.ca/kmzofr -- it appears to be several stamps with M1 separating them...
[20:28:20] <jepler> this one?
[20:28:31] <aystarik> right
[20:30:52] <aystarik> there are programs with a picture, they are less stupid :)
[20:42:10] <jepler> wow, there's a startling difference in memory usage from nvidia opengl to software opengl when loading that program. enough that I've now run out of ram+swap and have a very unhappy computer.
[20:42:52] <aystarik> welcome to my hell
[20:45:07] <jepler> It changes how I think about this problem when I know it's memory-bound, not CPU bound
[20:45:15] <jepler> for one thing, no number of 5-10% CPU speedups will fix it
[20:45:23] <jepler> bbiab
[20:45:41] <aystarik> you already rejected patch which fixed it...
[20:46:39] <aystarik> I am just cleaning the code, so I can understand it. If you don't like to see those patches, I will shut up.
[21:05:47] <jepler> your patch fixed it, but at a great cost to other users of the software (making the preview look worse). I tried to make it clear that *optionally* doing a lower-quality preview of circles was something worth doing, but *unconditionally* doing it is not something I will accept in the mainline emc2.
[21:06:05] <jepler> (I recall that we talked about adding a new menu item that would change this behavior)
[21:09:14] <aystarik> this discussion probably did not include me
[21:10:50] <aystarik> I already have stack of rejected patches, so one more does not change picture.
[21:12:55] <jepler> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-10.txt
[21:13:00] <jepler> hm, I guess last time I said that after you'd left
[21:13:12] <jepler> 22:06 timestamp
[21:15:59] <aystarik> yes, was absent for the whole proposal...
[21:18:06] <cradek> if AXIS didn't do the work of generating and saving the preview when it is turned off in the menu, a next possibly-useful step would be a way for it to detect when the preview is unreasonably big and just shut it off (notifying the user)
[21:19:24] <jepler> Assuming (AXIS,stop) is working again, you can get a truncated preview if that's the bargain you want to make.
[21:19:45] <cradek> true
[21:20:39] <aystarik> I already have working AXIS, and it works faster every day. You are free to take the patches or toss them.
[21:25:24] <jepler> There are the ones I recently put a form of in master. There's the arc number-of-segments one, which we've just discussed and I've tried to show a way forward. There's this new rotation patch and I see there's another arc patch in the "patches-master" that you sent me. Are there others?
[21:34:17] <aystarik> move of program text to the left -- rejected.
[21:34:39] <jepler> yes.
[21:34:51] <aystarik> add const to several Interp methods -- ignored
[21:35:59] <aystarik> to show way forward without other person seeing is helpful
[21:36:49] <jepler> I'm sorry I didn't make sure you saw what I said.
[21:39:26] <jepler> is there a specifig benefit to adding "const" in those places?
[21:39:53] <jepler> specific, I mean
[21:40:28] <jepler> there have got to be a lot of places in emc2 where adding "const" is technically correct..
[21:40:38] <aystarik> With const, I know that I can reorder them without digging through source core
[21:40:58] <aystarik> and compiler knows this too.
[21:43:19] <jepler> OK, so the reason you found those two is because you were trying to determine whether optimize_maybe_new_line.patch was correct
[21:43:38] <aystarik> right
[21:46:53] <jepler> (er, three methods, I guess)
[21:47:43] <aystarik> who's counting...
[21:48:24] <jepler> I see other methods of Interp that could probably be "const" as well. save_parameters, line_length, line_text, line, and so on (just guessing from the comments, didn't look at the implementations)
[21:48:54] <aystarik> possibly.
[21:49:31] <jepler> I think it is worse to have 3 out of 10 (or however many it is) methods that could be "const" marked "const" than to have 0 out of 10. I'd rather consider a patch that adds const to all the relevant methods in a single class than one that just adds it to a subset.
[21:50:10] <jepler> consider the next person to look at the code. He might see that active_g_codes is const, but sequence_number is not, therefore the latter must really have some side effect
[21:50:11] <aystarik> You also may gain if don't send x,y,z,... -- up to 3 args may be sent in registers.
[21:51:02] <jepler> where are we talking about now?
[21:52:13] <aystarik> Interp calls Canon methods with all axis as args. up to 10 args to a method. sending up to 3 is fast.
[21:58:30] <jepler> I think you're mistaken about that. On x86 linux, a function with extern linkage and no __attribute__((regparm)) is called with all arguments on the stack.
[21:59:12] <jepler> anyway, with multiple levels of Python function calls still involved, you're simply going to be unable to measure any performance difference if one level of the C/C++ code passes using registers instead of stack.
[21:59:23] <aystarik> maybe. speaking from kernel/local call perspective
[22:00:09] <aystarik> yes, uncluttering python is a task in itself.
[22:01:03] <aystarik> it is possible to move whole GLcanon into C++, this will greatly simplify AXIS.
[22:02:07] <aystarik> there is no need to save untranslated 9-axis vertexes. 3 axis ones after line9 will do just fine too.
[22:03:37] <jepler> a C(++) rewrite would probably do much more to improve the speed than any number of micro-optimizations of the Python will.
[22:04:27] <aystarik> are you familiar with idea of refactoring?
[22:05:15] <aystarik> you change code in smallest possible pieces and make sure you don't break it between changes...
[22:06:20] <aystarik> if you know every line of the code, you could rewrite it from scratch, but it rarely is this way...
[22:12:13] <jepler> consider
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=dd20c323 -- is it a refactor? Is it uncluttering?
[22:14:27] <jepler> to me, the new code is worse to read, but I understand that some amount of readability can be given up for speed (you'll find many attempts at such compromises in axis)
[22:14:31] <aystarik> yes. it is small change, which is improving performance of this code. Regardless of the language it is written in. Now I can rewrite it in C++ and be happy about it.
[22:17:54] <jepler> My intuition is pretty much the opposite. If a wholesale translation of the canon class into C++ is the long-term plan, you're better off doing it based on more straightforward code rather than lots of optimizations that cater to the peculiarities of optimization in Python
[22:18:21] <jepler> then if that still doesn't meet your performance requirements, do small-scale optimizations that make sense in C++
[22:18:41] <aystarik> no, trigonometric functions are expensive everythere.
[22:21:14] <aystarik> currently, I struggle with the mess in GLcanon/Translate/ArcSegmentMixin. duplicated methods, duplicated init of variables, fail to init other variables at all. quite fun.
[22:22:35] <jepler> much of what you're looking at is the debris of my own micro-optimization of that code.
[22:23:26] <aystarik> how 2 set_offsets could be optimization?
[22:31:04] <jepler> you mean set_origin_offsets? beats me.
[22:36:02] <aystarik> how about this piece:
[22:36:05] <aystarik> class Translated:
[22:36:06] <aystarik> offset_x = offset_y = offset_z = offset_a = offset_b = offset_c = 0
[22:36:55] <aystarik> class GLCanon(Translated, ArcsToSegmentsMixin):
[22:37:23] <aystarik> self.offset_x = self.offset_y = self.offset_z = 0
[22:37:54] <aystarik> no mention of offset_{u,v,w}
[22:39:29] <jepler> OK, you've proven I'm a shitty programmer. Now what?
[22:41:34] <aystarik> you may consider not to teach me how to best refactor this code...
[22:41:55] <jepler> OK.
[22:41:57] <jepler> bye
[22:42:01] <aystarik> bye
[22:43:51] <aystarik> on the other hand, you might improve if shown your drawbacks... don't know, it helped me.
[22:44:29] <CIA-2> EMC: 03seb 07v2.4_branch * r0782f7deb097 10/src/Makefile: don't put stuff in /usr/local