Emitting Optimal C
I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria. 1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold. 2. Separately, to perform Naive Bayes computation across huge datasets. What is required is function inlining as well as use of SIMD instructions. I would provide the inlined functions via .h's and compile them in with gcc. I really don't know much about language design and development, so I might be way off base here. For the GC, I guess this would imply that there would be a way to fix the scope of closures and other structures that are referenced/collected. With jhc taking a 'full program' approach to analysis and optimization, I thought that this might be possible. Or perhaps there is a way to use ref counting for objects of an indeterminate lifespan instead of incremental (or whichever) garbage collection. I see that jhc see offers a way to specify unboxed values and tuples. And I'm sure there is a way to manage large native arrays as well. Is there a way to pass that data directly to an inline C function that would be compiled in by gcc? (i.e. not loaded from a library through FFI) I've looked through most of the jhc mailing list archives and haven't found any such discussions. Would this be something that would be achievable somewhere in the jhc roadmap, or at least conceivable with a few hacks? -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein
Rick R wrote:
I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria.
1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold.
In what way is "garbage collection mostly disallowed"? Is there a technical restriction (rather than just documentation saying "we don't want you to use garbage collectors")? Is the issue the one you mention in the next sentence ("Program size and memory must fit below a threshold") in that most garbage collectors are complicated? -Isaac
It doesn't explicitly forbid GC in the Developer agreement. However,
cocoa's own garbage collector is removed in the iPhone SDK. In the
docs describing the API, it indicates that using Apple's your own GC
is disallowed. This means its not part of the official agreement,
however, since they're allowed to reject apps for any reason, I don't
feel comfortable using it. Ref counting is the official and most
common form of memory management on the iPhone.
Somewhere there are official specs on how many resources are provided
to your app. I can't find them now, but they seemed quite reasonable
for a phone.
On Sun, Feb 22, 2009 at 5:19 PM, Isaac Dupree
Rick R wrote:
I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria.
1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold.
In what way is "garbage collection mostly disallowed"? Is there a technical restriction (rather than just documentation saying "we don't want you to use garbage collectors")? Is the issue the one you mention in the next sentence ("Program size and memory must fit below a threshold") in that most garbage collectors are complicated?
-Isaac
-- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein
On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote:
I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria.
1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold.
Hmm.. interesting. What compiler is XCode based on? If it is a gcc derivitive, I don't see any reason this wouldn't work. It is actually quite easy to compile programs for OSX or windows with jhc if you have something like IMCROSS[1] installed. you just do jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe I was able to compile programs for the iPhone the same way, but I had a jailbroken phone so didn't need to conform to their other standards. I am not sure what they could mean by 'no GC', is it simply because they require C/C++ or ObjC? I mean, when you write a C program, clearly you need to write in some mechanism to deal with garbage. Hmm.. you might want to ask them whether it is okay to link against the boehm gc. although not ideal (very not ideal speed-wise), jhc works with that, but if they allow it, then I imagine the more advanced gc options will be okay too.
2. Separately, to perform Naive Bayes computation across huge datasets. What is required is function inlining as well as use of SIMD instructions. I would provide the inlined functions via .h's and compile them in with gcc.
How huge of a dataset? Are you working on a better song recommendation wizard? Something you might want to look into is that I am pretty sure the iPhone has sqlite as standard equipment, I think you can extend it with your own operations, perhaps a bayes computation operation or something. hmm... but the sqlite overhead might kill you. hard to say.
I see that jhc see offers a way to specify unboxed values and tuples. And I'm sure there is a way to manage large native arrays as well. Is there a way to pass that data directly to an inline C function that would be compiled in by gcc? (i.e. not loaded from a library through FFI)
When you import something via the FFI, say something like foreigin import ccall foo :: CInt -> CInt then nothing special happens other than calls to foo(x) will appear in the source. now, you can provide that function however you want, via a library, or via direct linking against the C code, jhc doesn't really care. Hmm.. if you want to actually have them be inlined functions, I will probably have to give you a way to specify that the definition actually might appear in the header file, not just a prototype (since prototypes arn't needed in general) so a pragma might be in order to say "I really need this file #included.". It should be easy to implement. When you come across the issue post it on the list and we can figure out what the best solution is. A trivial workaround would be to just postprocess the c code produced by jhc itself until a built in mechanism is created.
I've looked through most of the jhc mailing list archives and haven't found any such discussions. Would this be something that would be achievable somewhere in the jhc roadmap, or at least conceivable with a few hacks?
Nothing sounds like a showstopper. jhc is great at cross compiling, so embedded targets like phones are a natural match with it. John -- John Meacham - ⑆repetae.net⑆john⑈
Thanks for that info. The iPhone app and the bayes stuff are separate.
I will likely use jhc for for the bayes stuff. Once I get to the
point where I'd like tight C++ integration, I'll be sure to yell.
However, for the iPhone, Pre-Scheme fits my needs almost perfectly.
Since Apple can (and does) reject apps for any reason, I would like to
make my apps as conformant as possible. Which building C/Obj-C start
to finish within X-code, only statically linking, and only using their
libs.
Dynamically linking is expressly forbidden, and GC is a gray area in
which I'd rather not tread.
On Mon, Feb 23, 2009 at 6:44 PM, John Meacham
On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote:
I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria.
1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold.
Hmm.. interesting. What compiler is XCode based on? If it is a gcc derivitive, I don't see any reason this wouldn't work. It is actually quite easy to compile programs for OSX or windows with jhc if you have something like IMCROSS[1] installed. you just do
jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe
I was able to compile programs for the iPhone the same way, but I had a jailbroken phone so didn't need to conform to their other standards.
I am not sure what they could mean by 'no GC', is it simply because they require C/C++ or ObjC? I mean, when you write a C program, clearly you need to write in some mechanism to deal with garbage.
Hmm.. you might want to ask them whether it is okay to link against the boehm gc. although not ideal (very not ideal speed-wise), jhc works with that, but if they allow it, then I imagine the more advanced gc options will be okay too.
2. Separately, to perform Naive Bayes computation across huge datasets. What is required is function inlining as well as use of SIMD instructions. I would provide the inlined functions via .h's and compile them in with gcc.
How huge of a dataset? Are you working on a better song recommendation wizard? Something you might want to look into is that I am pretty sure the iPhone has sqlite as standard equipment, I think you can extend it with your own operations, perhaps a bayes computation operation or something. hmm... but the sqlite overhead might kill you. hard to say.
I see that jhc see offers a way to specify unboxed values and tuples. And I'm sure there is a way to manage large native arrays as well. Is there a way to pass that data directly to an inline C function that would be compiled in by gcc? (i.e. not loaded from a library through FFI)
When you import something via the FFI, say something like
foreigin import ccall foo :: CInt -> CInt
then nothing special happens other than calls to foo(x) will appear in the source. now, you can provide that function however you want, via a library, or via direct linking against the C code, jhc doesn't really care.
Hmm.. if you want to actually have them be inlined functions, I will probably have to give you a way to specify that the definition actually might appear in the header file, not just a prototype (since prototypes arn't needed in general) so a pragma might be in order to say "I really need this file #included.". It should be easy to implement. When you come across the issue post it on the list and we can figure out what the best solution is. A trivial workaround would be to just postprocess the c code produced by jhc itself until a built in mechanism is created.
I've looked through most of the jhc mailing list archives and haven't found any such discussions. Would this be something that would be achievable somewhere in the jhc roadmap, or at least conceivable with a few hacks?
Nothing sounds like a showstopper. jhc is great at cross compiling, so embedded targets like phones are a natural match with it.
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc
-- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein
participants (3)
-
Isaac Dupree -
John Meacham -
Rick R