Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2013-11-06

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:08 Will_the_Chill joined #perl11
00:08 Will_the_Chill bulk88: thanks!  :)
00:09 Will_the_Chill rurban: feedback yet?
00:09 mirjam joined #perl11
00:18 rurban super busy with B::C
00:47 Will_the_Chill rurban: can you please look at it tonight to see if I forgot anything?
01:49 mirjam joined #perl11
02:49 mirjam joined #perl11
02:57 rurban1 joined #perl11
03:01 mirjam joined #perl11
03:28 mirjam joined #perl11
04:01 mirjam joined #perl11
04:14 mirjam joined #perl11
05:02 mirjam joined #perl11
06:03 mirjam joined #perl11
06:28 rurban1 joined #perl11
06:30 bulk88 some of "shall not"s turn Perl too much into C instead of into a Javascript or C# and break Perl too badly, they even forbid features of C which are fast, or "magic" which is C compile or Byteloader compile time optimized away, that has no runtime impact
06:33 bulk88 Will_the_chill, ^, for a line by line analysis I need a few hours when I'm more awake, I've been shopping/out all day, first time in a few weeks due to ilness
06:35 bulk88 1 example, "Use Indirect Access To $ Scalar Variables Via References Or Pointer Arithmetic" copying is much more expensive
06:36 bulk88 aliasing my vars to @_, which some CPAN modules have claimed to do, is more efficent
06:38 bulk88 "Use Aliased, Non-Descriptive, Special (%ENV, %SIG, etc), Or Punctuation Variables ($_, @_, %!, $@, $$, $[, etc)" these are fine, these would be getter/setter methods/functions in other langs
06:38 bulk88 $_ is fine, since that could/would be optimized away into something
06:40 bulk88 AFAIK Perl's implicit $_ is de-implicted at Perl compile time, not at runtime, there aren't runtime branches in pp_* checking if its a pad SV or $_ sv
06:40 bulk88 the $_ gets optimized to an anonymous pad SV
06:40 Will_the_Chill okay I'm reading what you've written
06:41 Will_the_Chill bulk88: good initial feedback, thanks!
06:42 Will_the_Chill maybe tomorrow when you're more awake you can e-mail me back?  :)
06:42 bulk88 "Use Static Number Of Arguments & Single Return Values For Subroutines" single or multiple return values aren't an efficeency problem, incoming params/@_ and return params (scalar or list context) are both Perl stack,
06:43 bulk88 since list is a variant of array, it is probably more efficient than returning a hash in some cases, since hashes waste memory due to holes in the array, and rarely collision handling
06:44 bulk88 fixed field/key hashes are highly optimizable, they are just arrays with constant indexs
06:44 bulk88 there are cpan modules which claim to do that
06:44 Will_the_Chill remember the whole point here is we're compiling from RPerl into C/C++
06:45 Will_the_Chill I'm not trying to speed up Perl 5 core itself, not right now at least!  :)
06:46 bulk88 a Perlmonks post recently involved discussion whether some Perl code was 4 or 5, because the OP saw arrays with "if($array[FIELD_NAME]) {" in it, and thought "wow, either the guy is an idiot for not using hashes, or Perl didn't have hashes when this was written"
06:46 Will_the_Chill okay, and?
06:47 bulk88 Perl 4 had hashes, later in the code section there was a method call, so it was definetly Perl 5 code the OP posted, point of story is, it took a senior poster on perlmonks to realize why the hell was the code using Perl arrays instead of hashes
06:47 bulk88 it was for performance reasons
06:48 Will_the_Chill oh well hashes are okay, I can make them run fast in C++
06:48 bulk88 only if they are restricted/const keys, so they are gapless arrays
06:49 Will_the_Chill nope, C++11 includes maps
06:49 bulk88 then you are back to the same number of steps the CPU has to take in C++ as in Perl 5 C
06:49 Will_the_Chill already got it working in my beta RPerl code released on github
06:49 bulk88 unless there is a CS concept IDK of being used there
06:50 Will_the_Chill sure, hashing takes the same time
06:50 Will_the_Chill but everything else in Perl, less the magic, runs faster in C/C++
06:50 bulk88 "Use Basic String Processing" good, "Use Regular Expressions, Smart Match, q Quoting Mechanisms, Or String Interpolation" q quotes are compile time optimized away
06:50 Will_the_Chill so use low-magic Perl and we can compile to C/C++ which is equivalent and runs much faster
06:51 bulk88 perl 5 compiler in p5p perl converts all interpolation to catting
06:51 bulk88 in those q/qq/qx operators
06:51 Will_the_Chill I know people will want to add back in all that string stuff, I'll try to do it in RPerl v2.0
06:52 Will_the_Chill gotta hack away ALL the magic for v1.0 :)
06:52 bulk88 "Use Late Binding (Autoload, Run-Time Dispatch, etc) Or Lazy Evaluation (“eval”, Promises, Run-Time Compile, etc)" if the sub doesn't exist at compile time, it wont exist later
06:52 bulk88 fine
06:53 Will_the_Chill my question is more like "what magic did I forget to destroy?"
06:53 bulk88 few people use autoload or eval unless it is to save memory or religious OOP/CS adherance without thinking
06:55 bulk88 with the curennt not use list unmodified, my answer to "what magic did I forget to destroy?", is, don't use Perl or JS, or C++, use assembly
06:57 bulk88 local isn't evil, it can be synthed in Perl/C as copy to a my/pad var at subroutine start, copy back from my/pad var at subroutine return, banning it will just generate more LOC with no gain
07:00 bulk88 "Use Private Dynamic-Scope (“local”), Private Persistent Lexical-Scope (“state”), Global, Or Package Variables (“our”)" globals have to exist, state/C function scoped static vars, I dont like closures personally. They quickly are forgotten about and lead to leaks/unused but persistent vars
07:01 bulk88 "Use Experimental Perl Features (lvalue Subroutines, attributes Pragma, etc)" sort of agree, lvalues are basically synthesized as the left hand function, with a secret 1st or last parameter, which is the right hand side of the assignment
07:02 bulk88 so lvaules are okay if my knowledge of lvalue is correct
07:03 bulk88 lvalue, "foo("cat", "dog") =  boo(5);", compiled into/executed as normal perl, "foo(boo(5), "cat", "dog");"
07:03 mirjam joined #perl11
07:03 bulk88 I dont remeber how lvalue is implemented under the hood in P5 though
07:04 Will_the_Chill the point of this is to create a low-magic subset of Perl 5 that can be compiled into C/C++ and linked back in to normal high-magic Perl 5 code
07:04 Will_the_Chill so saying "don't use Perl" is kinda silly  ;)
07:04 Will_the_Chill you can keep all your high-magic stuff, and I can get my low-magic Perl to run super fast
07:05 Will_the_Chill and they can plug together seamlessly
07:05 bulk88 well, many Perl 5 features are candy on a language level, they TIMTOADY into the same code after being "compiled"
07:06 bulk88 or optimizaing compilers can break them down to existing code, and the existing code path is the same number of steps under the hood as the fancy code
07:06 Will_the_Chill and all that sugar needs to be removed to get to my low-magic scallion core
07:06 Will_the_Chill less candy, more veggies
07:07 Will_the_Chill I considered a sugar beet as the vegetable mascot for RPerl since it still has enough sugar to make you hyper.  :)
07:07 Will_the_Chill but then I decided on a scallion instead, since it is the smaller cousin to the onion.
07:07 bulk88 sugar isn't the problem, the problem is when you open the 1 lb bag and find 3 different colors, one for corn sugar, red for beet sugar, and green for cane sugar, which do you put in your coffee now?
07:07 Will_the_Chill I drink my coffee black only.  problem solved.
07:07 bulk88 I didn't see your sugar beet comment before i made the past psot
07:08 Will_the_Chill lol BEETS FTW
07:08 Will_the_Chill black coffee analogy: works in real life and in code!
07:08 Will_the_Chill so again, which magic did I forget?
07:09 bulk88 I dont remember how rperl matches P5 code to C code, I looked at it once
07:09 bulk88 regexp, optree, deparse back into Perl 5
07:09 bulk88 or what
07:10 Will_the_Chill low-magic P5 -> B -> (C/C++ using Perl data types) OR (C/C++ using native data types) -> Inline::C/CPP -> XS -> link back to original P5
07:10 Will_the_Chill I keep changing my mind on the parser, my current decision (hopefully it sticks) is B
07:11 bulk88 what you want to avoid is "branches" in asm, these are usually branches in C, but some C if/else statements are easily made branch free in asm
07:11 bulk88 Perl
07:11 bulk88 beb
07:11 bulk88 brb
07:11 Will_the_Chill roger
07:11 Will_the_Chill *goes to get coffee*
07:13 bulk88 back
07:14 bulk88 perl spends a large amount of time, checking flags all over the place and then doing branches
07:14 Will_the_Chill yes and none of that will happen in RPerl
07:15 Will_the_Chill because I'm cutting out all the crap
07:15 bulk88 nothing is ever broken down into pure int math, pure float, or pure character operations, there is an runtime cast in ever operator
07:15 Will_the_Chill NOT IN RPERL THERE ISN'T
07:15 Will_the_Chill Thou Shalt Use A Type System And Static-Type Data
07:15 Will_the_Chill my int $foo = 24 * $baz;
07:16 bulk88 in some cases, you will never get around the runtime casts, you can't create an SQL statement from a FP number, you will have a "cast"
07:16 bulk88 which will have a penalty
07:16 Will_the_Chill well then I'll just have to use my big ol' sword and CHOP THAT MAGIC AWAY
07:16 bulk88 static type is important
07:16 Will_the_Chill static type is the MOST important
07:16 bulk88 but, I'd say, explicit static casts arent necessery in many cases
07:17 bulk88 it can be detected from revious operations on the last couple statements
07:17 Will_the_Chill want your code to run fast?  TELL THE COMPILER WHAT KIND OF DATA YOU'RE USING.  only Perl people would think otherwise.
07:17 Will_the_Chill Thou Shalt Not Use Impatience To Create Inefficient, Slow Code That DOES MORE THAN ITS JOB
07:18 Will_the_Chill don't make me guess what your data is
07:18 Will_the_Chill people don't LIKE to guess what you're thinking
07:18 Will_the_Chill neither do compilers
07:18 bulk88 its 2 AM maintence hour at Time Warner cable, my VNC ping jumped by 10x a few minutes ago, 900 ms ping to go 20 miles
07:19 Will_the_Chill wow nice
07:19 Will_the_Chill at least it still works!
07:20 Will_the_Chill I'd love to convince you (and everyone else) to use low-magic code, but that's not what this discussion is (supposed to be) about.
07:20 Will_the_Chill I'm trying to figure out what kinds of magic I forgot so I can put it in there.
07:20 bulk88 ok, static types are good, but they can be guessed for some statements, my opinion is new code should use static types, but its easier/cheaper to write a better compiler, than to rewrite all code for a new existing compiler
07:20 Will_the_Chill honestly I don't think I forgot any because I've spent weeks searching for all kinds of magic...
07:21 Will_the_Chill all existing code that NEEDS TO RUN FAST must be re-written.  most existing code can stay the same.
07:21 Will_the_Chill the re-written low-magic fast code is a drop-in replacement and won't break anybody's existing high-magic Perl 5 or XS.
07:21 Will_the_Chill which is also very very important.
07:21 Will_the_Chill all the other "new Perl" (aka Perl 11) projects is like "yeah we're just gonna break all your code and just FORGET about existing XS code"
07:22 Will_the_Chill I'm all like "keep all your existing wacky code and just write new and/or needs-to-run-fast stuff in RPerl cuz it will run just fine with your wacky stuff"
07:23 bulk88 I'd say the rule is should be explictly for "if you use right column, you dont get optimized, dont use the right column for hot perl code as determined by nytprof"
07:23 Will_the_Chill yes, that's the general idea.
07:23 bulk88 you didn't forget anything on the right hand column, I'd say you banned Perl in it
07:23 Will_the_Chill I'm going to write some very basic preface that says "use this if you want your code to run fast".
07:24 bulk88 it needs a disclaimer its just just for hot code, not all code
07:24 Will_the_Chill YAY I BANNED PERL and left behind... RPerl!
07:24 Will_the_Chill JUST FOR HOT CODE, yes that is correct my good friend!
07:24 bulk88 "Use Preprocessed Code (Source Filters, etc)" those are fine, whatever the source filter spits out is more Perl 5
07:25 Will_the_Chill NOPE it is (likely) high-magic Perl 5
07:25 Will_the_Chill BANNED
07:25 bulk88 I like the C preprocessor, compile time logic is penalty free
07:25 bulk88 *runtime penalty free
07:25 Will_the_Chill there is already tons of preprocessing being done by RPerl, don't need it happening anywhere else in the toolchain!
07:26 bulk88 what if you want to const fold but don't want to use P5's subs that return litterals are consts implementation? I'd rather the compiler drop the if conditional, and the else statement block
07:27 Will_the_Chill okay I'm a little confused by your question(s)?
07:27 bulk88 there is memoize on CPAN, but its clunky/crazy/doesnt work right
07:27 bulk88 IMO
07:27 ingy1 joined #perl11
07:27 Will_the_Chill oh, caching
07:28 Will_the_Chill you won't need it once your code is compiled to super-fast C/C++
07:28 Will_the_Chill ;)
07:28 Will_the_Chill (I'm happy to add caching into RPerl v2.0)
07:28 bulk88 to cache, you must have proof it will be the same in the future, at that point, you can constant fold optimize and remove "the cache"
07:28 Will_the_Chill right
07:28 Will_the_Chill I'm not actually implementing any traditional optimization techniques in RPerl v1.0
07:29 Will_the_Chill all the speed-up in v1.0 is based on removing magic and compiling to C/C++, then gaining the benefit of an existing C/C++ compiler suite
07:29 Will_the_Chill in future versions we can add all kinds of static (and dynamic!) compiler optimization techniques
07:29 bulk88 eval is evil, my/pad vars shouldnt have to exist all the time
07:30 Will_the_Chill yes, eval is banned
07:30 bulk88 another Perl problem is, pad vars are never reused, 1 declaration, 1 unique scalar, liveness analysis would be nice
07:30 Will_the_Chill the C/C++ compiler should take care of that
07:30 bulk88 instead of 20 or 30 unique scalars on the ram stick/cpu cache, just have 5
07:31 bulk88 im talking about the cases where it doesn't make sense to use a basic machine type due to casts
07:31 bulk88 or compatibility back to legacy p5 apis/code
07:32 Will_the_Chill if you can't use static data types, then your code is too high magic to compile right now
07:32 bulk88 "Use Double-Quote Interpolated String Or Special Literals (__FILE__, __LINE__, __PACKAGE__, __SUB__, etc)" special litterals are all compile time constants, no overhead vs C
07:32 Will_the_Chill encapsulate that crap and compile code that doesn't do that magic casting dynamic type stuff
07:33 bulk88 double quotes are complied to cat operations
07:33 bulk88 *concast
07:33 bulk88 *concat
07:33 Will_the_Chill those are things that don't have an easy analogy in C/C++ (that I know of), so they are cut out in v1.0
07:34 bulk88 http://perldoc.perl.org/perlapi.html#sv_catsv
07:34 Will_the_Chill again, ask yourself "how would this easily be compiled to C"?
07:34 bulk88 that is every answer I've given above
07:35 Will_the_Chill okay how do I easily implement the __PACKAGE__ special literal in C++?
07:35 bulk88 well, im really thinking how would it be compiled to asm
07:35 Will_the_Chill I'm definitely NOT trying to compile anything to assembly myself
07:35 bulk88 look for the last package statement in the .pm text file
07:35 bulk88 at compile time
07:35 Will_the_Chill I'm trying to match up all the obviously-similar parts of low-magic Perl and high-magic C/C++
07:36 Will_the_Chill okay, yes, I could do that to get __PACKAGE__.  in v2.0, haha!
07:36 Will_the_Chill I'm trying to get v1.0 out the door on Christmas.  THIS CHRISTMAS.
07:36 bulk88 lol
07:37 Will_the_Chill LOL is right!  :)
07:37 Will_the_Chill I'm glad you got the joke.  Because it is also the truth.
07:37 bulk88 if your staff programmers are combative with you, the rules wont work
07:37 bulk88 if they cooperate with you, you dont need rules
07:38 Will_the_Chill compilers use rules to compile code, humans must follow those rules or their code won't compile
07:38 Will_the_Chill don't be silly
07:38 Will_the_Chill follow the rules and your low-magic Perl code will run super fast.
07:38 Will_the_Chill don't follow the rules and it WON'T.
07:38 bulk88 for 0.1 the rules list is fine
07:39 Will_the_Chill the idea is if I build a solid foundation for v1.0, then it can be extended by everybody to include support for their own pet magic
07:39 bulk88 for v*.0 3 years after v0.1, the rules are impossible to work with
07:39 Will_the_Chill uh, sure, except it is one-point-oh, not oh-point-one.
07:40 Will_the_Chill we will add more magic for each successive future release.
07:40 bulk88 that is fine, I'm just saying dont expect production usage with the v0.1 rule list, demos on a project are fine though
07:40 bulk88 *projector
07:40 Will_the_Chill there is a large, but finite, amount of magic in Perl 5.  it is conceivable that RPerl could eventually be extended to encompass all that magic, then you have a full Perl 5 compiler and can replace the runtime if you like.
07:42 Will_the_Chill maybe, we'll see.  :)
07:42 bulk88 if the point of the rules list is to optimize "$dest = ($src + 5)/4;" the rules list is fine
07:42 Will_the_Chill we are starting there, because we have to start SOMEWHERE.
07:43 Will_the_Chill low magic goes beyond simple arithmetic, but yes, your point is generally correct.
07:44 bulk88 if the point of the rules list is to do a DB transaction, then spit out AJAX with HTTP headers, someone will write a VM ontop of RPerl (turing complete), and there will be bets with green money in the break room if it will be 1000x, 10000x or 100000x slower
07:45 bulk88 (semi jk) the equivelent in C++ of Perl is, RTTI
07:46 bulk88 the rules list is fine
07:46 bulk88 "Use Global-Scope (“select”) Or Complex Builtin Operators (“format/write”, “pack/unpack” <PBP 102 Conflict>)" ban all I/O
07:47 bulk88 no <>, no handles
07:47 bulk88 IO is done in legacy P5 statements
07:47 bulk88 or subs
07:47 bulk88 "Use Special Code Blocks (Closures, Anonymous, BEGIN, UNITCHECK, CHECK, INIT, END, etc)" state is a closure
07:48 bulk88 ban objects/methods too
07:49 bulk88 objects, unless static typed, have lookup ovehead for method calls
07:50 Will_the_Chill I'm not against banning IO
07:51 Will_the_Chill I strongly considered it, in fact
07:51 bulk88 P5's IO, crlf correction, utf8 conversions, etc, are best left alone
07:51 Will_the_Chill objects are compiled straight to C++ objects, supah fast!
07:51 bulk88 not if methods are replaced at runtime
07:52 Will_the_Chill no late binding or lazy eval allowed
07:52 Will_the_Chill all methods must be static-typed just like subroutines
07:52 Will_the_Chill I'm willing to accept the overhead of C++ objects
07:52 Will_the_Chill it is fast enough I think!  :)
07:53 bulk88 C++ objects have no overhead if they dont do certain kinds of OOP
07:53 Will_the_Chill no overhead, yay!
07:53 bulk88 "virtual" keyword in C++ is evil
07:54 Will_the_Chill yes I know not to use virtual
07:54 Will_the_Chill in C++
07:54 bulk88 if you ever see it, runtime looks are done/vtable
07:54 bulk88 *lookups
07:54 Will_the_Chill other than giving me another thing to do for v1.0, what are the perceived drawbacks of implementing simple non-magic open() (or IO::File) in C/C++?
07:55 Will_the_Chill there is a pretty close mapping from low-magic Perl open() to C/C++ fopen() or fstream::open(), yes?
07:55 bulk88 no there isnt
07:55 Will_the_Chill no?
07:55 Will_the_Chill how so?
07:56 bulk88 perl does crlf correction
07:56 bulk88 and utf8 vs ascii on a Perl lang level
07:56 bulk88 ban utf8
07:56 bulk88 no unicode
07:56 Will_the_Chill right
07:56 Will_the_Chill good point!
07:56 bulk88 that also means no regexps
07:56 bulk88 and little string processing
07:56 Will_the_Chill regexps are already banned!
07:57 Will_the_Chill how would banning unicode negatively affect non-regex string processing?
07:57 ingy1 joined #perl11
07:57 bulk88 it also means your IO input must be ASCII/latin-1/legacy, not utf8
07:57 bulk88 in utf8, you have to do branches to see the length of each character
07:58 bulk88 in perl, everything is a character, it just happens to be, most of the time characters are 1 byte long under the hood
07:58 bulk88 but perl has to test to see if the input SV is utf8 or ascii
07:58 Will_the_Chill just modified #45:
07:58 Will_the_Chill Thou Shalt Not Use Regular Expressions, Smart Match, q Quoting Mechanisms, Unicode/UTF-8, Or String Interpolation
07:59 Will_the_Chill so if I ban unicode, THEN what is the problem mapping Perl open() to C/C++?
07:59 bulk88 crlf, what is "\n" in bytes on a  disk?
08:00 bulk88 binmode function in P5
08:00 bulk88 that turns off crlf if the platform has it
08:01 bulk88 I think only windows perl does crlf conversion
08:01 bulk88 on unix perl "\n" printed to console is 1 byte, not 2
08:01 bulk88 on win32 perl, "\n" printed to console is 2 bytes, \r\n
08:01 bulk88 on classic mac its \
08:01 bulk88 r alone
08:02 Will_the_Chill uh, what happens if I just ignore that issue?
08:02 Will_the_Chill and/or isn't there a simple fix to just convert the crlf chars?
08:03 bulk88 pray the production code you want to RPerlize has a good test suite
08:03 Will_the_Chill okay, yes, that is (hopefully) a given
08:04 bulk88 I/O is 1% of the CPUs time, it can be done through the P5 engine, delivered as a SV, then unwrapped into a char * or machine types
08:04 ingy1 joined #perl11
08:05 bulk88 you wont save anything measurable on inline open() into RPerl
08:05 bulk88 unless you call open() 100s of times a second
08:05 bulk88 at that point you will hit hardware or kernel driver limits
08:05 bulk88 "
08:06 Will_the_Chill huh
08:07 bulk88 RPerl can't help when open fails with "ENOMEM"
08:07 Will_the_Chill I'll have to think about that one.  I'm surprised at my own self wanting to keep IO
08:07 Will_the_Chill I think if it is low-magic file IO then I'll at least give it a chance to be in RPerl v1.0, if there is any problem I'll just ban it and let it wait until v2.0
08:08 Will_the_Chill I need to look closer at the mapping between Perl IO and C/C++ equivalent before I can make this decision...  you've given me something to think about for sure!
08:08 Will_the_Chill and your point of banning Unicode is AWESOME
08:08 bulk88 the other problem with I/O is, RPerl can't add async or nonblocking I/O, to an app that uses sync IO, if your app uses sync IO, converting it to use RPerl is a waste
08:09 Will_the_Chill I won't argue with that
08:09 bulk88 most P5 code I write deals with I/O that returns strings
08:09 bulk88 parse strings/files, return more strings
08:10 Will_the_Chill I may end up banning some-or-all IO once I start actually coding that part
08:10 Will_the_Chill but I still think if we ban Unicode and keep to low-magic in general, then some basic file IO is okay
08:10 Will_the_Chill BUT I COULD BE WRONG!
08:10 bulk88 if your perl process isn't maxing the CPU in ps/top, RPerl will never help
08:10 Will_the_Chill oh I know that already
08:11 Will_the_Chill I've had CPU-maxed-out Perl code for a decade, thus I have NO CHOICE but to write RPerl
08:11 Will_the_Chill or re-write all my code forever into C/C++ by hand, which is what RPerl will do anyway
08:12 Will_the_Chill after converting chunks of code from Perl 5 into C/C++ I was like "this stinks, I need to automate it", BAM the concept of RPerl was born
08:13 bulk88 my opinion is, Rperl needs to convert Perl statements (aka ";") to C++, not entire subs, you will be hard pressed to find any subs in existing code that can be fully C++ed ever in 2-4 years of RPerl development
08:13 Will_the_Chill yes it should be able to compile single statements
08:13 Will_the_Chill but I'm gonna start with subs because it is easier
08:14 bulk88 breaking a regexp into C++, umm, that sounds like solving a civil war at the UN
08:14 ingy1 joined #perl11
08:14 Will_the_Chill once we can do individual statements, then RPerl can do JIT
08:14 Will_the_Chill I will never try to compile regexes into C/C++, that will be one of those "just call the Perl engine to do it" situations.
08:15 Will_the_Chill regex is a sub-language of it's own, I have no interest in re-implementing it
08:15 bulk88 but if every damn sub has a regexp into it, what subs are there left to optimize?
08:16 Will_the_Chill huh?  every sub has a regex?  what?
08:16 Will_the_Chill I don't get it.
08:16 bulk88 in some cases, I've written string processors/parsers that dont generate perl data trees, since its too much overhead to fill out a couple hundred/1000s hash slices instead of just recording a couple byte offsets into the file
08:17 Will_the_Chill is there some hidden magic regex attached to ever perl sub?
08:17 bulk88 load from disk->convert string to Perl data tree->logic on data tree->serialize back to string->save to disk
08:18 bulk88 that is the traditional way of doing it
08:18 Will_the_Chill okay I'm totally lost.
08:18 Will_the_Chill let's go back to your comment about "every damn sub has a regexp", what does that mean?
08:19 Will_the_Chill I don't use regular expressions (usually), so none (or few) of my subroutines have any regular expressions in them.
08:19 bulk88 that is a programming style/design
08:19 bulk88 then you are fine with RPerl
08:19 Will_the_Chill well regular expressions are banned in RPerl, so you have to NOT USE THEM
08:19 bulk88 my P5 code I use for production never does math
08:19 Will_the_Chill mine does
08:20 bulk88 then your code easier to optimize
08:20 Will_the_Chill and it is totally possible for RPerl to embed calls to the P5 regex engine, I just don't want to deal w/ it in v1.0
08:20 Will_the_Chill regex will never run faster than what is already implemented in Perl so there is no re-implementing any regex stuff in RPerl
08:20 ingy1 joined #perl11
08:22 Will_the_Chill Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
08:22 Will_the_Chill ~ Jamie Zawinski
08:22 Will_the_Chill XD
08:23 bulk88 one question for Rperl, how will you handle, (and I dont any answers in my head of pros/cons/implementation) in a sub, when there are my vars, that are declared in a new block in the sub, but aren't visible in scope to the enclosing block/root block of the sub? or limiting scope has no runtime overhead since there is no eval?
08:24 bulk88 let me give an example 1 sec
08:24 Will_the_Chill Number 48: Thou Shalt Use Normal Code Blocks (Bodies Of Conditionals, Loops, & Named Subroutines)
08:27 Will_the_Chill I may need to explicitly state that all variable declarations need to be at the top of each subroutine to avoid any weird smaller-than-subroutine scopes.
08:27 Will_the_Chill all variables must be EXACTLY scoped to 1 subroutine
08:27 Will_the_Chill like in C/C++, big surprise!
08:28 Will_the_Chill oh wait I'm wrong about that!
08:28 Will_the_Chill because we need to allow idiomatic lexical scopes inside of conditional and loop bodies
08:29 Will_the_Chill I'll just need to have RPerl check the scope of all vars declared as lexical to a conditional/loop body
08:29 bulk88 http://pastebin.com/8Sr3xfWJ
08:30 bulk88 its a compile time problem, not a runtime
08:30 Will_the_Chill I assume the "$1" are supposed to be "$v1", yes?
08:31 Will_the_Chill that is going to have to be a compile-time scope check done by RPerl
08:31 Will_the_Chill because we want to keep Perl's idiomatic lexical-inside-conditional-and-loop-bodies construct
08:31 bulk88 AFAIK, every my/pad SV, regardless of scope, in a sub is "alive" and alloced at all times, a flag on each SV says if an eval can use it or not at that line, the my operator changes the flags to say if this SV is visible or insible
08:31 bulk88 no, not $1
08:32 bulk88 wait
08:32 bulk88 yea, $v1
08:32 bulk88 im not using capture magic vars
08:32 Will_the_Chill yes, I was gonna say, $1 is MAGIC!  haha
08:33 Will_the_Chill that will have to be extra scope-checking logic done by RPerl at compile time
08:33 Will_the_Chill so that normal C/C++ scope semantics can be used at runtime
08:33 Will_the_Chill UNLESS... does C/C++ do automatic scoping if you declare a variable inside a loop body?
08:34 bulk88 yes
08:34 bulk88 but on asm, there is only 1 scope, in the root scope
08:35 bulk88 of course there is compile time scope check which generates a syntax error
08:35 Will_the_Chill hey yeah!  it should work just fine according to C89 standard allowing block scopes!
08:35 Will_the_Chill so I don't see the problem?  I don't even have to do extra RPerl logic!
08:35 bulk88 but there is no runtime overhead on C (not talking about C++ destructors),  on opening new scopes and making new machine types in a function
08:36 bulk88 in C, opening new scope then doing my, has no overhead
08:36 bulk88 in Perl, it has overhead to allow eval to work
08:36 bulk88 since eval sees the sub's my cars
08:36 Will_the_Chill so are we in agreement that it is good and this particular scoping issue will map well from RPerl -> C/C++?
08:36 Will_the_Chill (or am I confused again?)
08:37 bulk88 ive thought of just storing the start and stop line numbers for each my var, then the line number of the eval, then figure it all out at runtime when the eval runs, eval will take longer, but "my" has zero overhead now
08:37 bulk88 it is fine
08:38 bulk88 I assume static types initially bans objects, so destructors at ";" or end of block boundaries dont run in RPerl
08:41 bulk88 ban undef
08:41 bulk88 it doesn't exist in C
08:41 Will_the_Chill BAN undef, good!
08:41 bulk88 it does, it is called NULL pointer
08:41 bulk88 but integer 0 is zero, not NULL
08:42 Will_the_Chill no we are definitely not banning objects, see #62
08:42 Will_the_Chill and #63
08:42 Will_the_Chill object is a static type
08:42 Will_the_Chill my object $foo_obj = MyClass->new();
08:42 bulk88 when do you run dtors for objects? at the end of the sub or the end of the scope?
08:43 bulk88 or at the
08:43 Will_the_Chill whenever perl garbage collection runs
08:43 bulk88 "=" that caused the dtor/ref to be deleted
08:43 Will_the_Chill in C/C++ it will be at the end of the sub I think, for simplicity to begin with
08:43 bulk88 you infected yourself with P5's C designt hen
08:44 bulk88 you dont want ref counting
08:44 Will_the_Chill ref counting works if it is all we have
08:44 bulk88 not for ints in P5
08:44 bulk88 those are C autos
08:44 bulk88 in Rperl gened code
08:45 bulk88 and your objects can't be SVs really
08:45 Will_the_Chill in the RPerl generated code that uses Perl data types, it will use refcounts and Perl GC
08:45 Will_the_Chill in the RPerl generated code that uses C/C++ data types, it will be explicitly calling C/C++ destructors as needed
08:45 Will_the_Chill two very different RPerl compile modes
08:46 bulk88 so RPerl gened functions will use Perl stack like Xsubs?
08:47 bulk88 so an RPerl method implementation, gets incoming params via Perl stack, like any xsub or optree (pure perl) sub?
08:47 bulk88 it is just when an RPerl method is called from an Rperl sub, not GV/package lookup is done, and the SV object's type is never checked?
08:48 bulk88 but if legacy P5 sub calls an RPerl method, it will go through normal P5 dynamic dispatch through a package?
08:49 bulk88 so each RPerl method has a CV struct, but the CV struct is only used for legacy calls to the new RPelr method?
08:50 Will_the_Chill two totally different RPerl compile modes
08:51 Will_the_Chill when using Perl-data-types compile mode, everything is handled via Perl stack as in Pure Perl
08:51 Will_the_Chill Inline helps handle the stack stuff
08:52 Will_the_Chill when using C/C++-data-types compile mode, all calls between RPerl-generated-C/C++-subs and Pure-Perl-subs pass data through typemaps I created
08:52 bulk88 ok
08:52 Will_the_Chill so for code that crosses the Perl-C/C++ boundary a lot, you want the Perl data types mode
08:52 Will_the_Chill for code that does NOT cross the language boundary a lot, you want C/C++ data types mode
08:53 Will_the_Chill the code generated for both modes is identical in function, just the internal data types are different
08:53 Will_the_Chill in fact, if the code has no side effects, you could generate both modes and run them in parallel to see which finishes first
08:54 bulk88 ban "\", no refs
08:54 bulk88 if you cant make a ref, everything is a C auto
08:54 bulk88 or from the caller or a glbal
08:54 Will_the_Chill number 25: Thou Shalt Not Use Indirect Access To $ Scalar Variables Via References Or Pointer Arithmetic
08:55 Will_the_Chill ALREADY DONE!
08:55 Will_the_Chill arrays and hashes MUST be references, scalars must NOT be references
08:55 bulk88 if its a huge string, you are screwed perf wise to do a copy
08:55 bulk88 if its an int, its unmeasurable
08:56 Will_the_Chill yeah well people should know about copying huge strings
08:56 Will_the_Chill :)
08:56 Will_the_Chill then put the string inside a hash ref, haha!
08:56 Will_the_Chill (mostly kidding)
08:57 bulk88 when you make rules, expect kids to spend 100% of their time figuring out how to break them and get away with it
08:57 Will_the_Chill there is no "getting away with it".  either your code will compile to be fast, or it WON'T.
08:57 Will_the_Chill if you do something that makes your code not compile through RPerl, you haven't gotten away with a dang thing, you've just ensured your code will run slowly
08:58 bulk88 but it will compile to fast, then call another Rperl method, which calls to leg p5 to the original work needed
08:58 Will_the_Chill yes, could be, if that's how they designed their code
08:58 Will_the_Chill just put your friggin' magic in another subroutine
08:59 bulk88 I dont think I have much more to say
08:59 bulk88 i can't complain about the left side column
08:59 Will_the_Chill PBP #247. Don’t be clever.
09:00 Will_the_Chill PBP #248. If you must rely on cleverness, encapsulate it.
09:00 Will_the_Chill Commandment #13: Use Pragmata To Mark Magic Level Of Code (“use magic;” & “no magic;”)
09:00 Will_the_Chill :)
09:01 Will_the_Chill I'm hope it was conveyed that the left and right columns are meant to be related and complementary?
09:01 Will_the_Chill IOW, each "Thou Shalt" has a corresponding "Thou Shalt Not"?
09:02 bulk88 i saw they were opposites horizontally instantyly
09:02 Will_the_Chill awesome!
09:02 Will_the_Chill back to undef briefly...
09:03 Will_the_Chill why couldn't I just use NULL pointer as the equivalent of undef?
09:03 bulk88 so all integers are "new"ed now? and no C stack integers?
09:04 Will_the_Chill my int $foo_int = 23 * $baz_int;
09:04 Will_the_Chill no new() there!
09:04 mirjam joined #perl11
09:04 bulk88 what is "my int $foo_int = 23 * undef;"? segv?
09:05 bulk88 what if $baz_int is undef?
09:05 Will_the_Chill hmm, runtime segfault I guess.
09:05 Will_the_Chill prolly don't want that
09:05 bulk88 undef can not be represented as a C machine integer
09:05 bulk88 not on x85
09:05 bulk88 *not on x86
09:06 Will_the_Chill if undef simply doesn't work with C/C++ then it must be banned
09:06 Will_the_Chill also, what do you mean when you say "C stack integers"?
09:06 bulk88 x86 FPs have NaN
09:06 bulk88 char *s have NULL
09:06 bulk88 Integers have, ummm, -1? :-p
09:07 bulk88 but -2 is perfectly fine
09:07 bulk88 no, ints on x86 have no concept of undef
09:07 Will_the_Chill hmm...
09:07 bulk88 "foo(void) { int i;"
09:08 Will_the_Chill yes I have void type
09:08 bulk88 "foo(void) { int * i =malloc(sizeof(int)); i *= 5"
09:08 bulk88 1st is more efficient
09:09 Will_the_Chill if there is no easy map from Perl -> C/C++ for undef then it must be banned
09:09 bulk88 2nd is stupid unless i is passed to callee or lives longer than the call of foo
09:09 Will_the_Chill I was mostly thinking that sometimes it is useful to test for undef of hash values and stuff like that
09:09 bulk88 in the casts/bridge between P5 leg and Rperl
09:09 Will_the_Chill but it can be replaced with testing for special values like -1 or empty string
09:10 bulk88 if you find an undef SV, its a fatal error, and the brige into a C++ Rperl sub isn't crossed
09:11 bulk88 I wont mention the over/underflow dangers of adding machine types to Perl either
09:11 Will_the_Chill I can't think of any reason why I'd NEED to have undef
09:11 bulk88 P5 can't overflow on math
09:11 bulk88 machine ints can
09:12 Will_the_Chill once I hit the limits of C/C++ arithmetic I can deal w/ it
09:12 Will_the_Chill prolly not in RPerl v1.0 though
09:12 Will_the_Chill I think you've convinced me to ban undef
09:13 bulk88 http://www.youtube.com/watch?v=kYUrqdUyEpI what happens when you replace P5 with C
09:13 bulk88 jkjk
09:15 Will_the_Chill explosion video: naw, low-magic Perl 5 can be made into perfectly runnable and stable C/C++... IF DONE CORRECTLY
09:15 Will_the_Chill many people have hand-compiled bit of P5 into C/C++ using Inline, just never any automated compiling
09:16 bulk88 a navigation sensor returned a FP number, it was cast to a short (32K/65K), the FP number was over 32K
09:17 bulk88 the code was used on an older rocket that took a different flight path, the sensor never returned > 32K before
09:17 Will_the_Chill ah, yes, well that's why we want STRICT RULES and AUTOMATED COMPILING
09:17 Will_the_Chill can't have Starfleet vessels experiencing such catastrophic failures!
09:20 Will_the_Chill anyhoo, great feedback, thanks SO MUCH!  :D
09:20 Will_the_Chill you helped me ban unicode and undef, yay!
09:22 bulk88 the dilema with the rocket is, if you use an infinite precision math library, suddenly each math operation is O(unknown) instead of O(1), what now? well, hope nothing important is underneath since the wing flaps haven't moved in 4 seconds since it was a really long number that had to be computed
09:22 bulk88 IDK how I'd solve it, that why I dont do real time/life critical computing
09:26 bulk88 I also wont mention about SIMD/SSE/vector math and Perl and auto paralleization
09:27 bulk88 (AKA, investigate it, but you might need to sell your kidney and every kidney in your neighborhood to pull it off)
09:28 bulk88 basically, in C, $sv < 5, is 1 asm op
09:28 bulk88 in perl, it is about 200
09:29 bulk88 in Rperl, maybe it can be 20 asm ops
09:29 bulk88 ultimately, everything you do, will be one of these dozen commands http://read.seas.harvard.edu/cs261/hwref/i386/Jcc.htm
09:30 bulk88 oh wait, in Rperl, maybe it will be 1 asm op
09:30 bulk88 since its normal c
09:47 Will_the_Chill reading your comments
09:48 Will_the_Chill in RPerl compile mode using Perl data types it will be 20 asm ops
09:48 Will_the_Chill in RPerl compile mode using C/C++ data types it will be 1 asm op
09:49 Will_the_Chill from http://rperl.org/faq.html
09:49 Will_the_Chill Q: Who needs RPerl?
09:49 Will_the_Chill A: Normal computer users will like running RPerl apps because it will empower them to finally take full advantage of all their shiny, new multi-core processors and cloud accounts. Software developers will like programming in RPerl because it will automatically parallelize their applications to be compatible with current and future high-performance computing platforms.
09:49 Will_the_Chill Q: What is RPerl?
09:49 Will_the_Chill A: RPerl is a computer programming language, based on the popular Perl 5 programming language. RPerl gives software developers a compiler to make their apps run really fast on parallel computing platforms like multi-core processors, the cloud, clusters, and supercomputers. RPerl stands for Restricted Perl, in that we restrict our use of Perl to those parts which can be made to run fast. RPerl also stands for Revo
09:49 Will_the_Chill lutionary Perl, in that we hope RPerl's speed will revolutionize the software development industry. RPerl might even stand for Roadrunner Perl, in that it RUNS REALLY FAST.
09:49 Will_the_Chill Q: When will RPerl v1.0 be released?
09:49 bulk88 https://skydrive.live.com/redir?resid=DCA201F1227DA3C2!328&amp;authkey=!AM6XEzor6UlFOaM this is how P5 adds 2 numbers in asm
09:50 Will_the_Chill A: Christmas.
09:50 bulk88 in C this would be 1 line
09:50 Will_the_Chill Q: Which Christmas?
09:50 bulk88 1 opcode
09:50 Will_the_Chill A: This Christmas, 2013. 'Tis a Perl family holiday tradition.
09:50 Will_the_Chill RPerl compiles low-magic Perl 5 into real C
09:50 Will_the_Chill it does what should have ALWAYS been done
09:51 Will_the_Chill except not really, 'cuz C/C++ have come a long way since Perl 5 was released
09:51 Will_the_Chill and maps (AKA hashes) have only just been added in C++11
09:51 Will_the_Chill so yeah
09:51 Will_the_Chill so whatever you can point to in C, RPerl should be able to achieve it exactly
09:51 Will_the_Chill by _being_ real C
09:51 Will_the_Chill and using gcc or g++ or whatever your compiler is
09:52 Will_the_Chill then I think we really could compile both the Perl 5 core and the RPerl-in-C combination source code using LLVM into LLVM bytecode, then apply massive cross-source optimizations
09:53 Will_the_Chill if you wanna really get jiggy with the low-level optimizations
09:53 Will_the_Chill but that's not my job, that belongs to the low-level compiler guys
09:53 Will_the_Chill I like doing high-level compilers
09:53 Will_the_Chill like RPerl, it is more useful
09:53 Will_the_Chill nowadays at least
09:53 Will_the_Chill I think  :)
10:00 Will_the_Chill YES I'M TRASH-TALKING THE LOW-LEVEL COMPILER GUYS!
10:00 Will_the_Chill (not really, sorry if it sounded that way)
10:00 bulk88 1 P5 less than ideal code bug I recently was this huge uncommented unreview lump of code from 2000, http://perl5.git.perl.org/perl.git/commit/14dd3ad8c9 , specifically someone tried to optimize 3 NULL assignments to 1 memset 0, instead of writing 3 4 byte ints, it now makes a func call and writes to ~80 bytes of memory
10:01 Will_the_Chill I mean for Perl 5 it is more important to have a new high-level compiler now rather than just more low-level compiler stuff.
10:01 bulk88 5 years later 2 1/3rd of the members of that struct disapper (all 4 byte ints/pointers)
10:01 bulk88 too bad a 0x40 zeroing is still left of something that is perfectly happy being uninit mem since there is a flag that says if its valid or not
10:02 bulk88 http://perl5.git.perl.org/perl.git/commit/caa674f3cc1c9e05da7c41f3dffbea4b2640af3c my fix
10:02 Will_the_Chill that is exactly the kind of low-level stuff I'm trying to avoid in the long-run by taking care of in the short-run in RPerl.  ;)
10:03 Will_the_Chill I hate programming in C/C++, I find it terribly tedious, so if I can just do a lot of it right now then in the future RPerl will write all my C/C++ code for me!  :D
10:03 Will_the_Chill then I can spend my days happily writing super-fast low-magic Perl 5 code.
10:04 Will_the_Chill and whenever I get a weird itch to write some high-magic Perl code, it will work just fine alongside my compiled low-magic code.
10:04 Will_the_Chill ACHIEVEMENT: best of both worlds
10:05 bulk88 http://perl5.git.perl.org/perl.git/commitdiff/5882ddb381a033c6699801b9b1046860bf7bfa9c another recent one, sorta found by me, when a non commit bit person tried to copy paste it and asked for code review and I noticed it, the source of the copy paste dated to 2012, later a guru came by and fixed it in that commit
10:06 Will_the_Chill I love Perl guts and also I HATE PERL GUTS
10:06 Will_the_Chill I'm not conflicted about it at all!  :D
10:06 bulk88 replaced a function call to itself with goto :-p http://perl5.git.perl.org/perl.git/commitdiff/9d176cd8dda1d6b2f98386843a92abe96e8a328e
10:07 bulk88 I had to unroll a huge macro to do it though
10:08 bulk88 http://perl5.git.perl.org/perl.git/commitdiff/52379eb83d6750e5a25234194773cdad131ae34f 20 patches over 20 years, none of them looked at the big picture
10:08 bulk88 it took 4 hours
10:09 bulk88 also a linked list of magic could have been searche upto three times previously, now the linked list searched a max of 2 times
10:09 bulk88 *MAGIC
10:10 Will_the_Chill lovely
10:11 Will_the_Chill I find great satisfaction in finally finding a way to turn off the magic.
10:11 bulk88 http://perl5.git.perl.org/perl.git/commitdiff/fc5771079abcc2fce5ac42d93197705063548366 lets mortalize an immortal scalar, the mortal func has a check BTW to make sure you can't mortalize an immortal scalar, but each func has overhead
10:13 Will_the_Chill all magic, all must die
10:15 bulk88 mortalize is part of reference counting/GC, immortal is a scalar (there are 4 of them) that is global/permanently allocated
10:15 bulk88 http://perl5.git.perl.org/perl.git/commitdiff/851ffa6e66f5cbb2878b578e7d833b4d728c6975 2 calls to cast SV to IV on my C compiler in assembly (but maybe not on other)
10:16 bulk88 2*4*2=slow
10:16 bulk88 macros inside macros lead to multiple eval problems, when your are calling a getter method in a C macro, yeah,
10:16 Will_the_Chill GC is fine when appropriate
10:17 Will_the_Chill casting must die
10:17 Will_the_Chill macros must die
10:17 Will_the_Chill eval must die
10:17 Will_the_Chill what are the 4 immortal scalars?
10:17 bulk88 undef, true, false, and HV placeholder
10:18 bulk88 http://perldoc.perl.org/perlapi.html#PL_sv_no http://perldoc.perl.org/perlapi.html#hv_clear_placeholders
10:18 bulk88 placeholders is undocumented/kindda private
10:19 Will_the_Chill good all 4 of those can doe
10:19 Will_the_Chill *die
10:20 bulk88 the immortals are quite efficient compared to allocing a new scalar and setting it every time
10:20 bulk88 I'm worried about your RPerl perl mode thogh
10:20 bulk88 in C++ mode, you wont have SV structs
10:21 bulk88 but to interact with P5 they are required
10:23 bulk88 I've had ideas that all of http://perldoc.perl.org/perlvar.html should be implemented as immortals rather than the current "package vars" system (the package look up code (and packages/symbol table are hashes), if it seems one of these special key names, will return the SV for this special var from somewhere else)
10:24 bulk88 then in perl's opcodes, the special vars are accessed with an offset into the interp struct, and the interp struct * is used everywhere (on 1 out of 2 lines of C code in the perl engine on average)
10:28 bulk88 im leaving for the night
10:30 Will_the_Chill okay nighty night!
10:30 Will_the_Chill :)
14:17 rurban1 joined #perl11
14:46 bluescreen joined #perl11
14:53 Will_the_Chill bluescreen: hi, how are you?  also, who are you?  :)
14:55 bluescreen Will_the_Chill: Just as a start, I'm human... from planet earth
14:55 bluescreen Although I don't know if I can pass the turing test
14:58 bluescreen Will_the_Chill: does that help in anyway?
15:19 mirjam joined #perl11
15:41 Will_the_Chill okay that was kinda weird!  :)
15:54 rurban bulk88: adding two "numbers" is not trivial in asm. depends in the size and type and location of the numbers. heap or stack
15:54 rurban U32,I32,U64,I64,double,long double, ...
16:02 Will_the_Chill right
16:04 rurban and where and how the float is stored. FP stack, SSE/MMX register, which parts are normalized or not, ... what to do with the carry flag, or use traps
16:05 rurban or if it's properly 16-byte aligned
16:06 rurban there's an ongoing war going on between bsd and linux, and java and C99 what to do with the long double 2 extra bytes. use or ignore.
16:06 rurban intel only
16:09 rurban1 joined #perl11
16:20 bluescreen joined #perl11
16:27 rurban http://www.cs.berkeley.edu/~wkahan/ and Goldberg contains most of the number problems, but not the recent vectorization issues
16:32 rurban it's also very important to know on intel if the double is volatile (rounded down to 8 byte) or not (kept extended precision on the FP stack)
16:44 rurban1 joined #perl11
17:00 mirjam joined #perl11
18:12 bulk88 rurban, so "mov, add, mov" is slower than "add", but its still faster than 10 conditional jmps and tests
18:12 bulk88 you dont need to check the carry flag unless on a software level you aren't using native machine math and are instead using some other standard for math operations
19:22 mirjam joined #perl11
20:06 rurban sure, but add is only wordsize. what about addl,addsd,addpd or faddl/faddq, faddp using xmm or x87
20:27 bluescreen_ joined #perl11
21:14 rurban1 joined #perl11
21:26 mirjam joined #perl11
21:35 mirjam joined #perl11
21:39 rurban1 joined #perl11
21:42 bulk88 rurban, then do a SSE movaps/movups, then the SSE vector add, then keep it around in a XMM
21:44 rurban yes, but then you still have to know the different rounding modes
22:26 mirjam joined #perl11
22:49 mirjam joined #perl11
23:18 mirjam joined #perl11
23:38 Will_the_Chill joined #perl11
23:54 mirjam joined #perl11

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary