caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Markus Mottl" <markus.mottl@gmail.com>
To: ocaml <caml-list@inria.fr>
Subject: Severe loss of performance due to new signal handling
Date: Fri, 17 Mar 2006 13:39:52 -0500	[thread overview]
Message-ID: <f8560b80603171039o2a49a4du561a5726e34016bf@mail.gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --]

Hi,

this report has also been posted to the OCaml bug tracker, but since it is a
surprising observation, it may be good if people on the list know that it
exists without having to search the bug tracker archive.  Maybe some
assembler guru can repeat this result and explain to us what's going on...

----------

It seems that changes to signal handling between OCaml 3.08.4 and 3.09.1 can
lead to a very significant loss of performance (up to several orders of
magnitude!) in code that uses threads and performs I/O (tested on Linux).

The attached file (slow.ml) demonstrates this: it prints a character to
stdout in a for-loop. The uploaded version will take approximately 600ms in
native code to complete this test when redirecting output to /dev/null.  If
you comment out the line containing "module X = Thread" and compile without
thread support, then the test suddenly only takes around 1.5ms, i.e. it runs
400 times faster.

Profiling using oprofile revealed that the function
"caml_process_pending_signals" seems to be responsible for that.  Annotated
assembler output showed that the code was sampled an astonishing number of
times in the instruction "test %eax,%eax" as obviously generated for "if
(async_action != NULL)" in this function. This is really weird, because
everything else seems to be sampled a sensible number of times, but it would
surely explain the timings.

OCaml-3.08.4 does not exhibit any problems of that kind.

----------

Best regards,
Markus

--
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 1937 bytes --]

[-- Attachment #2: slow.ml --]
[-- Type: application/octet-stream, Size: 195 bytes --]

open Unix
open Printf

module X = Thread

let () =
  let t1 = gettimeofday () in
  for i = 1 to 100000 do
    print_char '.';
  done;
  let t2 = gettimeofday () in
  eprintf "%f\n" (t2 -. t1);



             reply	other threads:[~2006-03-17 18:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-17 18:39 Markus Mottl [this message]
2006-03-17 19:10 ` [Caml-list] " Christophe TROESTLER
2006-03-20  9:29 ` Xavier Leroy
2006-03-20 10:39   ` Oliver Bandel
2006-03-20 12:37     ` Gerd Stolpmann
2006-03-20 13:13       ` Oliver Bandel
2006-03-20 15:54       ` Xavier Leroy
2006-03-20 16:15   ` Markus Mottl
2006-03-20 16:24     ` Will Farr
2006-03-21  1:33   ` Robert Roessler
2006-03-21  3:11     ` Markus Mottl
2006-03-21  4:04       ` Brian Hurt
2006-03-21 12:54       ` Robert Roessler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f8560b80603171039o2a49a4du561a5726e34016bf@mail.gmail.com \
    --to=markus.mottl@gmail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).