|The stupid question is the question not asked|
Re^4: perllVm: A start.by BrowserUk (Pope)
|on Sep 05, 2012 at 13:22 UTC||Need Help??|
Thanks for the link Reini.
I can see that I am duplicating some of Yuval's efforts, but I think it will be worth it.
Beyond simply using llvm as an alternate C compiler -- though if doing so recovered (some of) the 15% to 30% loss of performance that has come about since perl5.6.1 with the additions of threading and Unicode support, that alone would be worth something -- I also want to explore what benefits (or not) are derived from the passes of the individual optimisers in llvm, on a the various groups of the perl core.
For now, my chosen task of having llvm-built binaries (perl.exe/perl5x.dll) that inter-operate with an otherwise standard distribution and modules -- including XS modules -- built using the normal compiler for the platform is (cautiously) going well. Most of the problems I've encountered so far result from my choosing to use MSVC rather than a gcc-compatible compiler to build the distribution I am inter-operating with. Simple reasoning: if I can make LLVM inter-operate with MSVC, gcc/mingw should be a doddle; but more importantly, inter-operation on other more obscure platforms should also be possible.
One of the bits of using LLVM that has gone completely unmentioned in all of the discussion I've seen so far, is the benefits of using its (frankly amazing) analysis & tracing tools. I've learnt more about the structure (and cruft) of the perl internals in the last 100 hours than in the previous 5 years.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.