6 ms·

Interesting... The Lua community has found that bytecode is actually slower to load than it is to generate from source: The extra latency of loading the (large

Interesting... The Lua community has found that bytecode is actually slower to load than it is to generate from source: The extra latency of loading the (larger) bytecode from disk/ssd/flash, exceeds the cpu time to lex/parse.

ploxiln 11y ago
On the other hand, Lua syntax is much simpler (slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...)
- daurnimator 11y ago
  > slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par... Ouch.... Perhaps a lesson in making your language's grammar too complex: if you do, you'll eventually have to pre-compile.
  - TheLoneWolfling 11y ago
    So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem? I know Perl is in that category.
    - chrisseaton 11y ago
      > So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem? No I don't think anyone has suggested that, have they?
    - vidarh 11y ago
      I don't think so. There are a few things that looks distinctly iffy in that respect on the surface, but they are resolved. e.g. is "foo" a method call or an instance variable? You can't know in isolation, but it doesn't matter at parse time, as if it's part of a larger construct that is only valid as a method call, such as if there's an argument list after "foo", it is parsed as a method call. E.g: foo = 1 foo(42) will result in: test.rb:4:in `<main>': undefined method `foo' for main:Object (NoMethodError) I think all of the potential cases that might have otherwise made Ruby impossible to formally parse are resolved in similar ways. Now, there are certainly layering violations. The aforementioned example of "foo" by itself can only be resolved by determining whether or not "foo" is in scope as a local variable at the point it is referenced, for example, but you can opt to defer the decision until after parsing.
    - ploxiln 11y ago
      ruby has a parse.y yacc grammar source file (linked to from the post I linked), and yes it can be parsed separately from being executed. However, IIRC, no one has been able to re-implement parse.y; jruby and the other ruby re-implementations copied it and made what adaptations were necessary.
- mst 11y ago
  I've seen similar results with perl bytecode. Our syntax probably isn't simpler :)
haberman 11y ago
I wrote a benchmark that measures just CPU impacts, and it finds that loading source code takes 25x longer: http://blog.reverberate.org/2014/10/the-speed-of-python-ruby-and-luas.html http://blog.reverberate.org/2014/10/the-speed-of-python-ruby...
- daurnimator 11y ago
  A few things: - you don't drop the disk cache; so you're loading from RAM (echo 3 > /proc/sys/vm/drop_caches) - you don't have very complex code - you timing includes starting/loading the intepreter itself.
  - haberman 11y ago
    > you don't drop the disk cache Yes that is why I said the benchmark measures "just CPU impacts." I don't think dropping cache alone would be sufficient to simulate loading of a large project -- I think the benchmark would also need to split the input across many files to recreate the seek time effects. > you don't have very complex code Given what I know about parsers, I highly doubt that the performance profile of parsing real code differs from my benchmark very much (ie. >30%). But I'm happy to be proven wrong on this, if anyone wants to try. > you timing includes starting/loading the intepreter itself That is why the benchmark makes the files pretty big, so the constant interpreter startup overhead is not a significant factor. Again, I don't think that you're going to be able to significantly change the shape of the results by adjusting for this.

ploxiln 11y ago

On the other hand, Lua syntax is much simpler (slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par...)

daurnimator 11y ago
> slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-parse-ruby http://programmingisterrible.com/post/42432568185/how-to-par... Ouch.... Perhaps a lesson in making your language's grammar too complex: if you do, you'll eventually have to pre-compile.
- TheLoneWolfling 11y ago
  So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem? I know Perl is in that category.
  - chrisseaton 11y ago
    > So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem? No I don't think anyone has suggested that, have they?
  - vidarh 11y ago
    I don't think so. There are a few things that looks distinctly iffy in that respect on the surface, but they are resolved. e.g. is "foo" a method call or an instance variable? You can't know in isolation, but it doesn't matter at parse time, as if it's part of a larger construct that is only valid as a method call, such as if there's an argument list after "foo", it is parsed as a method call. E.g: foo = 1 foo(42) will result in: test.rb:4:in `<main>': undefined method `foo' for main:Object (NoMethodError) I think all of the potential cases that might have otherwise made Ruby impossible to formally parse are resolved in similar ways. Now, there are certainly layering violations. The aforementioned example of "foo" by itself can only be resolved by determining whether or not "foo" is in scope as a local variable at the point it is referenced, for example, but you can opt to defer the decision until after parsing.
  - ploxiln 11y ago
    ruby has a parse.y yacc grammar source file (linked to from the post I linked), and yes it can be parsed separately from being executed. However, IIRC, no one has been able to re-implement parse.y; jruby and the other ruby re-implementations copied it and made what adaptations were necessary.
mst 11y ago
I've seen similar results with perl bytecode. Our syntax probably isn't simpler :)

haberman 11y ago

I wrote a benchmark that measures just CPU impacts, and it finds that loading source code takes 25x longer: http://blog.reverberate.org/2014/10/the-speed-of-python-ruby-and-luas.html http://blog.reverberate.org/2014/10/the-speed-of-python-ruby...

daurnimator 11y ago
A few things: - you don't drop the disk cache; so you're loading from RAM (echo 3 > /proc/sys/vm/drop_caches) - you don't have very complex code - you timing includes starting/loading the intepreter itself.
- haberman 11y ago
  > you don't drop the disk cache Yes that is why I said the benchmark measures "just CPU impacts." I don't think dropping cache alone would be sufficient to simulate loading of a large project -- I think the benchmark would also need to split the input across many files to recreate the seek time effects. > you don't have very complex code Given what I know about parsers, I highly doubt that the performance profile of parsing real code differs from my benchmark very much (ie. >30%). But I'm happy to be proven wrong on this, if anyone wants to try. > you timing includes starting/loading the intepreter itself That is why the benchmark makes the files pretty big, so the constant interpreter startup overhead is not a significant factor. Again, I don't think that you're going to be able to significantly change the shape of the results by adjusting for this.