Re: semi-timely interrupt
- From: Andy <andrew_nuss@xxxxxxxxx>
- Date: 27 May 2007 14:32:40 -0700
Well put. And I forgot to mention that this language is targeted for
I'm building a virtual machine for a scripting engine and I want to
check the flag on every RTS, LOOP, BREAK instruction. If I lock
there's the challenge of doing the check infrequently enough to not
slow things down and then the question is how infrequently relative to
the speed at which an "instr" executes, such as RTS.
In other words, you don't yet know whether you need this optimization.
Platform-specific optimizations should be one of your last resorts to
solve a proven performance problem.
The optimization sounds perfectly sensible in this situation. Taking
and releasing a lock on every RTS, LOOP and BREAK would indeed have a
measurable performance impact on code with tight loops (unless the
interpreter is very slow!) Many language implementations use exactly
this technique to implement interrupts.
processing complex regexes against very large streams. Not only do I
want to insinuate an interrupt flag check into RTS, LOOP, and BREAK
instrs to be able to interrupt long running functions written in the
scripting language, but I also want my automata engine (after every
new char buffer read, 32 chars) to look at the flag. The reason is
that commonly scripts would be executing automata for several seconds
at a time (large streams). Conclusion: in all of the important long
running tasks that a script can do, we need to check an interrupt
flag, but it would be a disaster to take and release a lock in this
check. Or at the very least, it would be much harder to design the
code to check frequently enough to satisfy the intent of the
interrupt, but infrequently enough not to have a performance impact on
the interpreter and the automata engine.
.
- Follow-Ups:
- Re: semi-timely interrupt
- From: David Hopwood
- Re: semi-timely interrupt
- References:
- semi-timely interrupt
- From: Andy
- Re: semi-timely interrupt
- From: Steve Watt
- Re: semi-timely interrupt
- From: Andy
- Re: semi-timely interrupt
- From: Eric Sosman
- Re: semi-timely interrupt
- From: Andy
- Re: semi-timely interrupt
- From: David Schwartz
- Re: semi-timely interrupt
- From: David Hopwood
- semi-timely interrupt
- Prev by Date: Re: semi-timely interrupt
- Next by Date: Re: Strong vs. Normal Thread Safety.
- Previous by thread: Re: semi-timely interrupt
- Next by thread: Re: semi-timely interrupt
- Index(es):
Relevant Pages
|
Loading