I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-). However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner. Is this is a possibility? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
MacPerl? Hey, what happened to macruby? I go on vacation and MacRuby becomes macperl ;) -Matt Sent from my iPhone On Apr 5, 2009, at 0:23, Rich Morin <rdm@cfcl.com> wrote:
I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-).
However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner.
Is this is a possibility?
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Yeah after some extensive benchmarking it seemed the performance of (Mac)Ruby was never gonna be enough compared to perl. An example of some code that 99% of the apps exist of: % time ./miniruby -e "print 'hello world'" hello world./miniruby -e "print 'hello world'" 0,05s user 0,08s system 86% cpu 0,143 total % time perl -e "print 'hello world'" hello worldperl -e "print 'hello world'" 0,00s user 0,00s system 66% cpu 0,007 total So the right choice was made… :-P Seriously though, I'm sure lots could be done to help ppc users out. But I feel this is exactly one of the reasons why OSS is a good choice. Because people who really need a feature can go fix it themselves. And because they really need it, it will be done the right way. Obviously I can't speak for Laurent, but atm I would suggest simply doing it if you care about it. Patches are always very welcome. Kind regards, Eloy On 5 apr 2009, at 16:51, Matt Aimonetti wrote:
MacPerl? Hey, what happened to macruby? I go on vacation and MacRuby becomes macperl ;)
-Matt
Sent from my iPhone
On Apr 5, 2009, at 0:23, Rich Morin <rdm@cfcl.com> wrote:
I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-).
However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner.
Is this is a possibility?
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
At 08:51 -0600 4/5/09, Matt Aimonetti wrote:
MacPerl? Hey, what happened to macruby? ...
Yeah^3. What's really embarrassing is that I've made that braino before on this list. Sigh. Eloy is certainly correct about OSS letting folks add features for themselves. However, this particular situation is (IMHO) one which calls for effort by the "core team". Specifically: * Simply figuring out which parts of the interpreter are involved would be a major undertaking for any "luser". * Even offering patches to the interpreter, in its current state of rapid change, might cause Laurent and company to lose time and/or focus. So, I'll leave this as a request: if there are things that the core team easily can do to keep the PPC code running in some fashion, please do so. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Hi Rich, Technically there is no reason why the experimental branch wouldn't work on PPC. The VM itself should work I think in big endian byte order and LLVM is supposed to support PPC (ppc & ppc64) too. However, since I do not have the time to verify and test I prefer to claim that PPC is not supported, because it could provide "false hopes". If you're willing to contribute time to verify that it works on PPC (by periodically running the tests for instance) then I would be glad to mention that PPC is supported. You have the sources, so let me know :-) Laurent On Apr 4, 2009, at 11:23 PM, Rich Morin wrote:
I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-).
However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner.
Is this is a possibility?
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (4)
-
Eloy Duran
-
Laurent Sansonetti
-
Matt Aimonetti
-
Rich Morin