Re: [racket-dev] Embedded racket is much slower in thread 'heavy' programs

2012-12-14 Thread Matthew Flatt
At Thu, 13 Dec 2012 22:57:54 -0800, Eric Dobson wrote:
 I have a program which is thread 'heavy' and runs much slower in embedded
 racket (vim) than it does in pure racket. [...]
 
 If I don't do in in a separate thread, then vim is comparable because it is
 using the racket scheduler, and not calling scheme_check_threads. Vim calls
 scheme_check_threads every bit (I think 10 times a second), but it looks
 like not much progress is made on each of these steps. I can understand if
 it was slightly slower, but a factor of over 50k is a bit too much. Is it
 possible for scheme_check_threads to do more work on each invocation in a
 scenario like this?

Yes, I think it would make sense for scheme_check_threads() to loop
with its current body until either one thread quantum (10ms) has passed
or check_sleep() returns 1 to indicate that no threads are ready to
run.

Does the variant below help?



void scheme_check_threads(void)
{
  double start, now;

  start = scheme_get_inexact_milliseconds();
  
  while (1) {
scheme_current_thread-suspend_break++;
scheme_thread_block((float)0);
--scheme_current_thread-suspend_break;

if (check_sleep(have_activity, 0))
  break;

now = scheme_get_inexact_milliseconds();
if (((now - start) * 1000)  MZ_THREAD_QUANTUM_USEC)
  break;
  }
}

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Embedded racket is much slower in thread 'heavy' programs

2012-12-14 Thread Eric Dobson
That fixed it. It is still a bit slower but it is now much closer and good
enough for me.
(0.945068359375 1.10400390625 0.961181640625)


On Fri, Dec 14, 2012 at 5:28 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Thu, 13 Dec 2012 22:57:54 -0800, Eric Dobson wrote:
  I have a program which is thread 'heavy' and runs much slower in embedded
  racket (vim) than it does in pure racket. [...]
 
  If I don't do in in a separate thread, then vim is comparable because it
 is
  using the racket scheduler, and not calling scheme_check_threads. Vim
 calls
  scheme_check_threads every bit (I think 10 times a second), but it looks
  like not much progress is made on each of these steps. I can understand
 if
  it was slightly slower, but a factor of over 50k is a bit too much. Is it
  possible for scheme_check_threads to do more work on each invocation in a
  scenario like this?

 Yes, I think it would make sense for scheme_check_threads() to loop
 with its current body until either one thread quantum (10ms) has passed
 or check_sleep() returns 1 to indicate that no threads are ready to
 run.

 Does the variant below help?

 

 void scheme_check_threads(void)
 {
   double start, now;

   start = scheme_get_inexact_milliseconds();

   while (1) {
 scheme_current_thread-suspend_break++;
 scheme_thread_block((float)0);
 --scheme_current_thread-suspend_break;

 if (check_sleep(have_activity, 0))
   break;

 now = scheme_get_inexact_milliseconds();
 if (((now - start) * 1000)  MZ_THREAD_QUANTUM_USEC)
   break;
   }
 }


_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Embedded racket is much slower in thread 'heavy' programs

2012-12-13 Thread Eric Dobson
I have a program which is thread 'heavy' and runs much slower in embedded
racket (vim) than it does in pure racket.

The program: (note no #lang, as I'm doing this in the repl)

(require racket/async-channel)

(define (make-passer in)
  (define chan (make-async-channel))
  (thread (lambda ()
(async-channel-put chan (sync in
  chan)

(define (run-passers num)
  (define input (make-async-channel))
  (define output
(for/fold ((chan input)) ((i num))
  (make-passer chan)))
  (define start-time (current-inexact-milliseconds))
  (async-channel-put input #f)
  (sync output)
  (define end-time (current-inexact-milliseconds))
  (- end-time start-time))

(define times '())

(thread
 (lambda ()
   (collect-garbage)
   (set! times (cons (run-passers 3) times))
   (collect-garbage)
   (set! times (cons (run-passers 3) times))
   (collect-garbage)
   (set! times (cons (run-passers 3) times


If you examine the times variable after sufficient time you get the
following:
In racket: (0.14501953125 0.134765625 0.619873046875)
In vim: (10706.1171875 10999.6611328125 9998.8330078125)

If I don't do in in a separate thread, then vim is comparable because it is
using the racket scheduler, and not calling scheme_check_threads. Vim calls
scheme_check_threads every bit (I think 10 times a second), but it looks
like not much progress is made on each of these steps. I can understand if
it was slightly slower, but a factor of over 50k is a bit too much. Is it
possible for scheme_check_threads to do more work on each invocation in a
scenario like this?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev