Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Lossless Decoder in Coffeescript

github.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Apple Lossless Decoder in Coffeescript

#11

Post by jbanon »

devongovett wrote: post #10
tlrobinson wrote: post #8

devongovett/jensnockert: what was your experience with using CoffeeScript for such low level code? Did you need to consciously avoid certain CoffeeScript features that could negatively impact performance?

Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is…

This is the difference in compiled output for those examples:

  var i;
  
  for (i = 0; i
http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...

Re: Apple Lossless Decoder in Coffeescript

#12

Post by devongovett »

jbanon wrote: post #11
devongovett wrote: post #10

Earlier quoted context omitted.

Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is…

This is the difference in compiled output for those examples: var i; for (i = 0; i http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...

Oops, I should have written it using a variable instead... i.e.

  for i in [0...test]
    doSomething()

  for i in [0...test] by 1
    doSomething()
compiles to:

  var i;

  for (i = 0; 0  test; 0
the latter one being much faster because it isn't testing the direction the counter should be going all the time.

Re: Apple Lossless Decoder in Coffeescript

#13

Post by jashkenas »

devongovett wrote: post #12
jbanon wrote: post #11

Earlier quoted context omitted.

This is the difference in compiled output for those examples: var i; for (i = 0; i http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...

Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 test; 0 the latter one being much faster because it isn't testing the direction the counter should be going all the time.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

Re: Apple Lossless Decoder in Coffeescript

#14

Post by devongovett »

jashkenas wrote: post #13
devongovett wrote: post #12

Earlier quoted context omitted.

Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 test; 0 the latter one being much faster because it isn't testing the direction the counter should be going all the time.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

Hmmm, well I think it's better if they can go in any direction by default otherwise people will be confused. The `by 1` should be considered an optimization IMO.

Re: Apple Lossless Decoder in Coffeescript

#16

Post by nitrogen »

jashkenas wrote: post #13
devongovett wrote: post #12

Earlier quoted context omitted.

Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 test; 0 the latter one being much faster because it isn't testing the direction the counter should be going all the time.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

What if you compiled it something like this:

  for i in [a...b]
becomes

  if(a  b; i--) {
          // Code again
      }
  }
Or otherwise moved the extra conditions outside the loop so they only get computed once?

Re: Apple Lossless Decoder in Coffeescript

#17

Post by jashkenas »

nitrogen wrote: post #16
jashkenas wrote: post #13

Earlier quoted context omitted.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

What if you compiled it something like this: for i in [a...b] becomes if(a b; i--) { // Code again } } Or otherwise moved the extra conditions outside the loop so they only get computed once?

Unfortunately, that requires repeating the entire body of the loop, and so isn't workable/acceptable for our purposes. If you'd like to see the original conversation that led to the current compilation, it's all available on the GitHub issues.

Re: Apple Lossless Decoder in Coffeescript

#19

Post by repsilat »

jashkenas wrote: post #17
nitrogen wrote: post #16

Earlier quoted context omitted.

What if you compiled it something like this: for i in [a...b] becomes if(a b; i--) { // Code again } } Or otherwise moved the extra conditions outside the loop so they only get computed once?

Unfortunately, that requires repeating the entire body of the loop, and so isn't workable/acceptable for our purposes. If you'd like to see the original conversation that led to the current compilation, it's all available on the GitHub issues.

I'll have a look for the discussion. Any idea if the branches are more expensive than some multiplies?

    step = (a
I guess if the branch predictor is any good it could be slower with multiplies, but I have no idea what to expect in a dynamic language.

Re: Apple Lossless Decoder in Coffeescript

#20

Post by ditoa »

Perhaps I am missing something obvious here (very possible as I do not work with audio decoding) but the demo at http://codecs.ofmlabs.org/ appears to playback the MP3 (not tested the ALAC file yet) too quickly. The site reports the MP3 as lasting 4:25 whereas manually downloading the track from the above website Winamp says the track is 5:14 long and playback is noticeably slower.

Is this by design or a bug in the code (or a bug in Chrome (16-stable) that I used to check out the demo site)?

Post reply on HN