Jump to content




ComputerCraft Beta Versions - Download and Discussion (1.74pr37, released June 22nd)


525 replies to this topic

#481 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 10 April 2015 - 01:52 PM

Thought I might do some speed tests - it seems that window-based rendering is faster, but unfortunately not by much. It's difficult to measure the difference. Benchmark rendering scores go something like this on my system:

1.73 - Text: 10.45, Color: 29.95, Advanced: 19.45
1.73 (no multishell) - Text: 1.95, Color: 2.05, Advanced: 3.6
1.74pr20 - Text: 9.55, Color: 30.95, Advanced: 15.2
1.74pr20 (no multishell) - Text: 1.95, Color: 2.1, Advanced: 3.65

Bearing in mind that the numbers deviate a little bit with each run (typically less than ~0.5), the most obvious change is that the "advanced" score is down four points (bearing in mind that "low" is supposed to mean "good").

Under general use (eg writing a whole line with unchanging text / background colours), term.write() and term.blit() operate at very nearly the same speed - running a few tests, I found the winner to be quite random. On the other hand, if you want to print a string while quickly switching between colours (eg a unique text / background colour for every character in your line), blit offers a dramatic speed boost. For example, it's about ten times faster with an eight character string... and the difference would increase as the string got longer.

Windows naturally make use of term.blit() now (for the purpose of redrawing lines), but you really won't see much of a speed difference there unless there are multiple colours in use on the same line. The aforementioned benchmark script never creates such a scenario, so that happens to be mostly useless for the purpose of demonstrating the change.

#482 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 10 April 2015 - 01:59 PM

View PostElvishJerricco, on 10 April 2015 - 01:40 PM, said:

View Postdan200, on 10 April 2015 - 12:36 PM, said:

Lua 5.2 has environments, you just can't change them after the function is created. You set them either using the 4th parameter to load (when compiling a function from code), or using the _ENV pattern I showed in the previous post (when declaring a new function). Everyone concerned they're losing something they absolutely need would do well to read what the lua manual has to say on the topic: http://www.lua.org/m...manual.html#2.2

I know very well how to use environments with 5.2. The issue is definitely minor and very niche, I'm not arguing against that. I'm merely pointing out that minor and niche is non-zero, and I have personally found several uses for setting environments on non-top-level-functions. Again, it's not major, so moving to 5.2 isn't the end of the world or anything. But it does take some justification.

again: you can create non-top-level-functions with custom environments using _ENV

View PostBomb Bloke, on 10 April 2015 - 01:52 PM, said:

Thought I might do some speed tests - it seems that window-based rendering is faster, but unfortunately not by much. It's difficult to measure the difference. Benchmark rendering scores go something like this on my system:

1.73 - Text: 10.45, Color: 29.95, Advanced: 19.45
1.73 (no multishell) - Text: 1.95, Color: 2.05, Advanced: 3.6
1.74pr20 - Text: 9.55, Color: 30.95, Advanced: 15.2
1.74pr20 (no multishell) - Text: 1.95, Color: 2.1, Advanced: 3.65

Bearing in mind that the numbers deviate a little bit with each run (typically less than ~0.5), the most obvious change is that the "advanced" score is down four points (bearing in mind that "low" is supposed to mean "good").

Under general use (eg writing a whole line with unchanging text / background colours), term.write() and term.blit() operate at very nearly the same speed - running a few tests, I found the winner to be quite random. On the other hand, if you want to print a string while quickly switching between colours (eg a unique text / background colour for every character in your line), blit offers a dramatic speed boost. For example, it's about ten times faster with an eight character string... and the difference would increase as the string got longer.

Windows naturally make use of term.blit() now (for the purpose of redrawing lines), but you really won't see much of a speed difference there unless there are multiple colours in use on the same line. The aforementioned benchmark script never creates such a scenario, so that happens to be mostly useless for the purpose of demonstrating the change.

Thanks for this. I guess i still need to optimise window.write/window.blit!

#483 Tag365

  • Members
  • 109 posts

Posted 10 April 2015 - 02:06 PM

Would you like to merge my version of the edit script with the official version of it? I have the source for my version. Below is my version with more features.
Spoiler

Edited by Lyqyd, 10 April 2015 - 03:05 PM.


#484 ElvishJerricco

  • Members
  • 803 posts

Posted 10 April 2015 - 02:08 PM

View Postdan200, on 10 April 2015 - 01:56 PM, said:

again: you can create non-top-level-functions with custom environments using _ENV

That's not really the same. I mean, functionally, it has the same effect. But the reason you actually call setfenv on non-top-level-functions is because you for some reason don't have access to its local scope. For example, LuaLua creates instance methods with their environments set to a special table. The functions are provided by the programmer, not anything the runtime has access to. So the runtime can't change or control the _ENV upvalue for these functions, meaning it relies strongly on the 5.1 environment model.

All in all we're not arguing anything important. You could update to 5.2 and I'd happily find another way around the problems that the 5.1 environment model can solve. It's just that it's not exceedingly rare to abuse the 5.1 model.

View PostTag365, on 10 April 2015 - 02:06 PM, said:

- snip -

Dude use a spoiler tag. That's a lot of text =P

Edited by ElvishJerricco, 10 April 2015 - 02:08 PM.


#485 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 10 April 2015 - 03:28 PM

View Postdan200, on 10 April 2015 - 01:59 PM, said:

Thanks for this. I guess i still need to optimise window.write/window.blit!

I'm not sure there's that much left to improve... For what it's worth, I gave it a go but didn't have much luck.

Spoiler

Yeah, it's faster, but not by all that much - 8.5/30.5/14.5 on average.

Edit: Actually that code was broken. Fixed it... for what it's worth.

Edited by Bomb Bloke, 14 April 2015 - 12:55 AM.


#486 Lignum

  • Members
  • 558 posts

Posted 10 April 2015 - 04:46 PM

Perhaps instead of using two strings to store the terminal display, it should use an array instead? Blitting would be way less complex that way and as a consequence probably also faster.

#487 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 10 April 2015 - 04:55 PM

View PostLignum, on 10 April 2015 - 04:46 PM, said:

Perhaps instead of using two strings to store the terminal display, it should use an array instead? Blitting would be way less complex that way and as a consequence probably also faster.

Also Strings are immutable and so have to be reallocated every time a draw occurs. I don't know how great the performance increase would be (if any) if it was changed though.

#488 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 11 April 2015 - 12:47 AM

"Two strings"?

Dividing line contents across a table would make it more complex, and I reckon the extra function calls required to do the spreading (and the recombining of the results) would do more to hurt matters than to help.

#489 Lignum

  • Members
  • 558 posts

Posted 11 April 2015 - 12:59 AM

View PostBomb Bloke, on 11 April 2015 - 12:47 AM, said:

"Two strings"?

Dividing line contents across a table would make it more complex, and I reckon the extra function calls required to do the spreading (and the recombining of the results) would do more to hurt matters than to help.

I'm not talking about term.blit, I'm talking about how ComputerCraft stores the display internally. Currently it's done with two strings, one stores the text along with its colour, the other stores the background colours. Because of this the blit function is just a huge mess of string manipulation, which lead me to think that perhaps using an array could simplify it and thus eventually increase performance. But maybe that's just because I often (wrongly) associate messy code with bad performance.

#490 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 11 April 2015 - 01:33 AM

Ah.

We'd been talking about getting the window API to operate at a speed closer to term.native(), so unfortunately Java-side changes won't help there.

I suppose something like the ".no_disk_startup" file check could be implemented, only to toggle multishell instead? That'd make the point moot, for those who care.

#491 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 13 April 2015 - 02:22 PM

If your program needs native performance (and you're ok with being incompatible with multishell and other windowing based OSes), you can just redirect to term.native()

#492 Phoenix323

  • Members
  • 30 posts
  • LocationAustralia

Posted 18 April 2015 - 09:30 PM

When will ComputerCraft update to forge 1.8

#493 Creator

    Mad Dash Victor

  • Members
  • 2,168 posts
  • LocationYou will never find me, muhahahahahaha

Posted 18 April 2015 - 09:42 PM

That would be really great. Oh and dan200 I want to thank you for making such a great mod. I thought me a lot of skills: lua and iron logic (very strong logic). I really think it is the best mod available ;)

#494 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 19 April 2015 - 03:45 AM

Source for which part of it?

The Java-side of things is closed source.

But much of the code you get to play with - the majority of the APIs, shell, and so on - are written in plain Lua, and can be found within the assets folder of the mod archive itself.

#495 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 19 April 2015 - 05:47 PM

In case the above post isn't clear, ComputerCraft is closed-source, so the source is not available anywhere. You could decompile the mod, but you cannot distribute modified versions of it.

#496 Phoenix323

  • Members
  • 30 posts
  • LocationAustralia

Posted 20 April 2015 - 07:24 AM

ok thanks

#497 JoeNoIce

  • Members
  • 17 posts

Posted 23 April 2015 - 09:26 PM

not to be a bother but when will 1.8 version of the mod be out?

#498 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

Posted 23 April 2015 - 11:07 PM

View Post10xephos01, on 23 April 2015 - 09:26 PM, said:

not to be a bother but when will 1.8 version of the mod be out?
Whenever it's out.

#499 JoeNoIce

  • Members
  • 17 posts

Posted 24 April 2015 - 06:15 AM

View PostCranium, on 23 April 2015 - 11:07 PM, said:

View Post10xephos01, on 23 April 2015 - 09:26 PM, said:

not to be a bother but when will 1.8 version of the mod be out?
Whenever it's out.

1 lol
and 2 when did you get moderator rank on this forum?

#500 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 24 April 2015 - 07:19 AM

View Post10xephos01, on 24 April 2015 - 06:15 AM, said:

when did you get moderator rank on this forum?

Believe it or not, that's actually documented.

Edited by Bomb Bloke, 24 April 2015 - 07:20 AM.






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users