Reini Urban

• Website: rurban.xarch.at/
• About: Working at cPanel on B::C (the perl-compiler), p2, types, parrot, B::Generate, cygwin perl and more guts (LLVM, jit, optimizations).

Recent Actions

• Commented on Why you don't need File::Slurp…
  mmap should be faster than sysread -s or read -s, and there exist a portable module for it....
• Posted Reverse debugging with gdb to Reini Urban

  I managed to work with gdb's reverse debugging finally. not only back out the backtrace.

  It should work since version 7.0 but got it working only today. The first times I got annoyed by the warning: …

• Posted Using kcachegrind on potion to Reini Urban

  cachegrind gives you information on the callstack and callcount, dependencies and efficiency. You can easily see hotspots in your code.

  I use it to check the JIT and objmodel efficiency of potion, which is the vm for p2.

  See my first post today …

• Posted Install kcachegrind on MacOSX with ports to Reini Urban

  Well, you don't want to install kcachegrind with port.

  $ sudo port search cachegrind
  kcachegrind @0.4.6 (devel)
      KCachegrind - Profiling Visualization
  

  Because building KDE takes hours, and you wont need it other than for cachegrind. But ther…

• Posted Idea - costmodel for B::Stats to Reini Urban

  Co-workers often ask me, what is faster. This or this?

  Of course you can benchmark the real speed, but theoretically you can look at the optrees and predict what will be faster.

• Commented on parser updates
  ryan.dietrich: p2 is good, just greg is limited. Yesterday I tried to fix greg memory leaks, leaks in greg itself, and leaks created by the parser library created by greg. v0.x shows off here. I probably have to come up...
• Posted parser updates to Reini Urban

  I worked on a new perl11 vm, p2, in the last months. In some perl11 meetings we identified several problems with the current architecture, and came to similar results as the parrot discussions a decade before.

  Not only is the VM (the bytecode interpreter) horribly designed as previously o…

• Posted no indirect considered harmful to Reini Urban

  Several p5p members argue that using indirect method call syntax is considered harmful.

  I argue that using indirect method call syntax is the best and sometimes only way to extend the language without changing core or the parser rules.

  method_name ClassN…

• Commented on Pumpkin Perl - Redux
  I thought perl emphasis collaborative maintainance over the single hero. I hear "matz ruby" and I'm displeased, but it might be okay because matz is in control of the language despite a lot of competitors who change and enhance the...
• Commented on Patch known perlcore ptr problems
  Thanks Tim for the comment with the revisions. I still stand to the recommendation against 5.16 at all. The reasons were posted on p5p, without any reaction. \0 in names are unprotected and exploitable. The whole new GV api with...
• Commented on Big module sizes
  The initial idea why M::B uses much more compiled space is related to the number of subs (CV). The numbers of those are in the last table. The memory and exe size is roughly comparable to this metric and less...
• Commented on Patch known perlcore ptr problems
  There was no drama in this announcement. It was IMHO a helpful community service with an easy way to apply the patches and keep your production perls safer. And it should be warned about the decreasing quality of the releases....
• Posted Patch known perlcore ptr problems to Reini Urban

  App::perlall 0.27, a better perlbrew at CPAN for multiple global perls, now patches some of the known security problems with buffer-overflows and use-after-free errors for the perl production releases.

  E.g.

• Commented on Announcement for Sereal, a binary data serialization format, finally live!
  We will definitely try to use it, thanks! I'm a bit sceptical about the benchmarks, as I found my own benchmarks also a bit flawed. https://github.com/rurban/msgpack-perl/blob/master/t/26_roundtrips.t...
• Commented on Optimizing compiler benchmarks (part 4)
  -funroll-loops is currently implemented by me and Will for B::CC only. See https://github.com/wbraswell/perl-compiler/commits/unroll-loops This is done at compile-time by analyzing the optree, and changing the emitted C code, as this was the easiest to do without adding more dependencies to...
• Commented on Optimizing compiler benchmarks (part 4)
  Will Braswell volunteered to implement loop unrolling, which will gain 100% with known loop sizes and some array accesses in the loop. When the B::CC implementation looks stable, we can bring it back to op.c....
• Commented on Optimizing compiler benchmarks (part 4)
  Steffen: I haven't implemented types and the simple state optimizations yet, only stack optimizations for lexical arrays, -fno-magic and -fno-autovivification for B::CC. This is the 6.5x faster figure I did in a few days. I will not start with types...
• Commented on Optimizing compiler benchmarks (part 3)
  Moose would rather need the optimizations I outlined at http://blogs.perl.org/users/rurban/2012/09/my-perl5-todo-list.html but so far they choose to ignore me. They even choose to break the upgrade path by implementing the worst signature proposal ever. So it looks like Moose even with...
• Commented on My perl5 TODO list
  Toby: With types you get most optimizations for free. You can also try smaller pragmas or type qualifiers to reach the same, like const'ing, no magic (not yet written), no autovivification or better no vivify. Generally const (compile-time readonly) is...
• Commented on Optimizing compiler benchmarks (part 4)
  I concur that 10% would be a big deal to some, but my current results of 550% are not? Why on hell are you proposing omitting taint checks at all, when 1. optimizing TAINT checks would gain 10% (with keeping...
• Posted Optimizing compiler benchmarks (part 4) to Reini Urban

  nbody - More optimizations

  In the first part I showed some problems and possibilities of the B::C compiler and B::CC optimizing compiler with an regexp example which was very bad to optimi…

• Posted Optimizing compiler benchmarks (part 3) to Reini Urban

  nbody - Unrolling AELEM loops to AELEMFAST

  In the first part I showed some problems and possibilities of the B::C compiler and B::CC optimizing compiler with an regexp example which was ve…

• Posted Optimizing compiler benchmarks (part 2) to Reini Urban

  nbody - unboxed inlined arithmetic 2x faster

  In the first part I showed some problems and possibilities of the B::C compiler and B::CC optimizing compiler with an example which was very ba…

• Commented on Subroutine Signatures - my Plan (v.1)
  So the logic is: If someone disagrees with adding new syntax for signatures we are left in the stone age with this ridiculous oversimplifying proposal? Design by fear and ignorance, not even by committee? Signatures are the best chance to...
• Commented on My perl5 TODO list
  Computed objects are hardly optimizable, because the blessed stash is only known at run-time, not at compile-time. Same for computed methods, the METHOD op, compared to the better METHOD_NAMED op. If you however declare the type of the computed obj,...
• Posted My perl5 TODO list to Reini Urban

  Below is a formal list of possible optimizations, which most would agree on. I'd like to work on these for perl5 core and need decisions. Most p5p hackers seem to be informed about the general possibilities and directions…

• Posted Optimizing compiler benchmarks (part 1) to Reini Urban

  Since my goal is to improve the compiler optimizer (staticly with B::CC, but also the perl compiler in op.c) I came to produce these interesting benchmarks.

  I took the regex-dna example from "The Computer Language Benchmarks Game" at sh…

• Commented on 3 features I would like to see in Perl
  Code compiled with B::C is has about 10x faster startup-time and uses much less memory. But run-time is not faster, yes. With B::CC I still have the problem of stack-smashing, but I think I had an idea last month to...
• Posted Reading binary floating-point numbers (numbers part2) to Reini Urban

  As explained in my previous blog post about parrot and parrot writes floating-pointing numbers in the native format and reads foreign floating-point numbers in different formats.

  What kind o…

• Posted native_pbc in parrot revived (numbers part1) to Reini Urban

  The design for parrot, the vm (virtual machine) under rakudo (perl6), scripts and modules. Something perl5 was missing. Well, .pbc and .pmc from ByteLo…

Comment Threads

• Leon Timmermans commented on Why you don't need File::Slurp…

  mmap should be faster than sysread -s or read -s, and there exist a portable module for it.

  There is, and I wrote it ;-). Was planning to blog about that too at some point. It's close but not exactly the same as slurping.

• George Greer commented on Why you don't need File::Slurp…

  I use a one-liner slurp at $WORK. I am sooo tired of copy+pasting it into scripts when I start them (and perhaps remembering which is the most recent if I've changed it lately). I would much prefer it be as easy as a module.

• Nick Patch commented on Why you don't need File::Slurp…

  If I recall, File::Slurp had issues with the PerlIO :encoding layer and required manual decoding of the slurped data instead, which is why I have avoided it. Not sure if this is still an issue.

• Leon Timmermans commented on Why you don't need File::Slurp…

  If I recall, File::Slurp had issues with the PerlIO :encoding layer and required manual decoding of the slurped data instead, which is why I have avoided it. Not sure if this is still an issue.

  Looking at the code, that's still an issue. I hadn't realized that, but that's a rather serious issue.

  It also doesn't quite handle :crlf correctly either. This is a mess :-(

• Leon Timmermans commented on Why you don't need File::Slurp…

  Functionally it's identical to read_file(binmode => ':raw'), otherwise it's perfectly portable.

  Because File::Slurp can be rewritten in XS if speed is the overriding concern (and it will be faster than your 2-lines).

  And it would not be faster than what I just posted. It really wouldn't. It's speed limited by the actual IO, that's the whole point.

  Because File::Slurp is self-documenting.

  All …