no wait

so, me and a few people on the lualand server were talking about how fast you can make a program. we decided to use
term.redirect(term.native) and realised something: it prints instantly, and needs no yield.
i tried this:

term.redirect(term.native)
i = 1
while true do
  print(i)
  i = i + 1
  if i == 10000 then
	sleep(0)
  end
end

gets around 229101 messages without erroring, then it says i must yeild. the interesting thing is tho: it printed about 10 messages after it errored!
edit: without term.redirect(term.native()) got about 85533 messages…
edit2: just did it again, got 99999 messages. it seems rly random

Interesting, so basically redirecting gives you a higher refresh rate? Or am I reading this wrong?

redirecting to native, on an advanced computer, bypasses the window api (which is not being used on basic computers in the first place). This is faster, as has been observed many times.

This has no impact whatsoever on needing to yield, you would just be able to print more before you were flagged for failure to yield because it's faster than writing through the window api redirect.

oh, very cool. I'll have to use this in some of my projects :D/>

its not rly useful except of terminal stuff, but, say your making a game(like i am) and you need to load a world…you could speed up the process a TON

In terms of no yielding if you really want to see a computer not yield. Code running in pullEventRaw doesn't error out or crash if handled correctly and pullEventRaw doesn't yield (if it did ever try to yield the computer would stop entirely). I don't suggest actually doing this or trying to figure out how you could do this as you may make people mad but it is an interesting concept if we are talking about no waits.

As for the window API I wonder why it isn't implemented in a way that only initializes if windows are actually being used if it is affecting the performance so much

Uh, what? The os.pullEventRaw function most certainly yields.

HDeffo, on 22 March 2015 - 11:14 PM said:

As for the window API I wonder why it isn't implemented in a way that only initializes if windows are actually being used if it is affecting the performance so much

If multishell didn't use windows all the time, then if you added a tab and switched to it, you'd lose the content of your original display. You can't retro-actively dump stuff into a window, it's got to be there from the word "go".

Lyqyd, on 22 March 2015 - 11:18 PM said:

Uh, what? The os.pullEventRaw function most certainly yields.

Try it redefine the function and have it do something recursive that will make it run itself again you will freeze up all other ComputerCraft computers and long as whatever you put into it isn't too intensive it usually won't error or crash your computer running this recursive non yielding function.

I understand I worded the above post very poorly. I was trying to make the comment on it's ability to not yield as cryptic as possible because I wasn't sure at what point a post is considered 'malicious'. Yes it will cause a yield when the pullEvent is used correctly but the physical passing of events doesn't result in any yield is what I meant.

Bomb Bloke, on 22 March 2015 - 11:59 PM said:

-snip-

What I meant by this is there are some buffer APIs which don't present this slowdown issue the windows API has. Until there is more than one window or window size is changed all it has to do is act similar to a buffer and just store the content changes as they're written instead of changing how it actually writes them. I am sure this would make the back end of the code a thousand times more complicated however the fact we have nearly instantaneous running buffers shows it is possible as these are very similar concepts

HDeffo, on 23 March 2015 - 11:54 AM said:

Lyqyd, on 22 March 2015 - 11:18 PM said:

Uh, what? The os.pullEventRaw function most certainly yields.

Try it redefine the function and have it do something recursive that will make it run itself again you will freeze up all other ComputerCraft computers and long as whatever you put into it isn't too intensive it usually won't error or crash your computer running this recursive non yielding function.

.. . well, obviously, if you override os.pullEventRaw with something that doesnt yield, it wont yield anymore. overriding os.pullEventRaw with almost anything will produce the same results.

I think what he's trying to say is that if you rig os.pullEventRaw() so that it doesn't yield, it won't cause the computer to crash, but will somehow keep it alive as a sort of "zombie" system that halts all other CC operations on the server indefinitely.

Beats me where that idea's coming from, though.

Well if it won't yeld for 10 sec problem will solve itself via timeout.

wojbie, on 23 March 2015 - 12:30 PM said:

Well if it won't yeld for 10 sec problem will solve itself via timeout.

It doesn't time itself out thus no sleep and completely no wait on printing as nothing else runs at all. That's where that idea is coming from…


Of course if we were trying to just (for no apparent reason) see how much we can push out per second wouldn't write be better than print? As it's lower level on the software stack so fewer function calls. Or am I mistaken on this? I believe I read somewhere in the rom where print is just defined as write adding a new line character to the end.

Didn't computercraft turn off computer if it did not yield for 10 sec? "Too long without yielding error"

wojbie, on 23 March 2015 - 12:59 PM said:

Didn't computercraft turn off computer if it did not yield for 10 sec? "Too long without yielding error"

It terminates the currently running program. However I believe either the code is written in a way that ignores the absolute lowest level functions like pullEventRaw or it just only checks if there's a running program for some reason.


EDIT: by program running I mean one that's run after the shell and for some reason it isn't counting the shell.

Well, both, really. Once the initial yielding timer threshold is crossed, it attempts to terminate the currently running program, and if that's not possible, it shuts the computer down completely. It makes this choice by waiting for the system to run a function it can "interrupt", and if that doesn't happen within a few seconds, then the entire computer gets killed and has to be manually restarted.

That is to say, you'll either see an error appear ("too long without yielding") and be booted back to the shell, or the system's screen will go black and you'll need to exit the interface and re-enter it in order to reboot the computer.

Either way, code that doesn't yield gets halted.

Messing around with the code on single player it didn't turn the computer off but I haven't messed around with that since 1.6 so dunno if that's changed recently.