[racket] Efficiency of tight loops in Racket

On Thu, Jan 13, 2011 at 8:31 PM, Harry Spier <vasishtha.spier at gmail.com>wrote:

> Dear list members,
>
> Thank you for this.  3 x C should be efficient enough.
>
>
Just to be sure I was clear: 3x C is something I've done only for certain
loops (a 1d convolution, in fact); I think that there are other loops that
can do that, but you should try to find some core loop to try it out
yourself.


> I am thinking that Racket would be an ideal choice for the OCR application
> for the following reasons:
> 1) 3 x C efficiency for tight loops should be good enough (far better than
> Ruby)
> 2) interface to ImageMagick (which I use to create my binary page
> representation)
> 3) I've already done a fair bit of development of the application in Ruby
> (but its far too slow). But the constructs in Ruby that made it attractive
> are (I've been told) functional programming constructs or copied from lisp
> type languages.
> 4) Since I'm new to lisp like languages,  I'm enjoying learning a new
> programming paradigm.
>
> My only concern now is about "backward compatability" as Racket develops.
> I.e. if I develop my software package now, do I have to worry that as time
> goes on my program will no longer be compatable with the new versions of
> Racket?


We do our best to maintain backwards compatibility (especially for core
language features).

Robby


> Thanks again,
> Harry Spier
>
>
> On Thu, Jan 13, 2011 at 5:55 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:
>
>>
>> And it is easy to drop down to the C level with Eli's FFI.
>>
>>
>> On Jan 13, 2011, at 5:54 PM, Robby Findler wrote:
>>
>> > It is going to be hard to beat C. My experience is that on tight
>> > nested loops like that where the loop body is simple and you write the
>> > loop carefully you can get with 3x of C (or 2x since Matthew has
>> > improved things since I last tried) but it is difficult to get to that
>> > point.
>> >
>> > Of course, if you want to actually write a real program around your
>> > loop, then Racket is definitely a good choice. Also, if your loop is
>> > parallelizable, you might want to try using futures.
>> >
>> > In any case, a lot of these little core loops don't take too much time
>> > to write, so you might try writing it a few times in a few languages
>> > to see what you see.
>> >
>> > Robby
>> >
>> > On Thu, Jan 13, 2011 at 4:07 PM, Harry Spier <harryspier at hotmail.com>
>> wrote:
>> >> Dear list members,
>> >>
>> >> I am developing an OCR application.  If written in an imperative
>> language (
>> >> C for example) it would spend most of its time traversing a 2
>> dimensional
>> >> array. (I'm representing a black and white page of text as a rectangle
>> of
>> >> 0's and 1's).  My first idea was to prototype in Ruby and then convert
>> to C
>> >> or to develop in Ruby with C extensions, but I'm wondering if I could
>> do the
>> >> whole development in Racket.  I've seen somewhere (though I can't
>> remember
>> >> where) that Racket can be in the same order of efficiency as C .
>> >>
>> >> But the crux issue is the efficiency of traversing the 2 dimensional
>> array.
>> >> I've noticed in the Racket Guide section 18.7  "Unchecked, Unsafe
>> >> Operations" where it says "For tight loops that use these functions,
>> >> avoiding checks can sometimes speed the computation, though the
>> benefits
>> >> vary for different unchecked functions and different contexts."
>> >>
>> >> Have any list members ever compared the efficiency of nested C loops
>> and how
>> >> you would traverse a 2 dimensional array in Racket.
>> >>
>> >> Thanks in advance,
>> >> Harry Spier
>> >>
>> >>
>> >> _________________________________________________
>> >>  For list-related administrative tasks:
>> >>  http://lists.racket-lang.org/listinfo/users
>> >>
>> > _________________________________________________
>> >  For list-related administrative tasks:
>> >  http://lists.racket-lang.org/listinfo/users
>>
>>
>                                                    <#12d825de65ac2e0c_>
> <#12d825de65ac2e0c_>             <#12d825de65ac2e0c_>       <#12d825de65ac2e0c_>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110113/5e2e513f/attachment.html>