n = print numCapabilities
```
when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof
+RTS -N` prints `2` on my machine. When the same program is compiled with `ghc
-threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N` it
prints `1`.
When an argument
lag (without argument) with the profiling runtime
> seems inconsistent compared to the behavior without profiling. The following
> program
>
> ```
> module Main where
>
> import GHC.Conc
>
> main :: IO ()
> main = print numCapabilities
> ```
>
> when compiled wit
Hi,
The behavior of the -N flag (without argument) with the profiling runtime seems
inconsistent compared to the behavior without profiling. The following program
```
module Main where
import GHC.Conc
main :: IO ()
main = print numCapabilities
```
when compiled with `ghc -threaded -fforce
t/2013/02/06/performance-problems-with-threaded/
> but they depend on network which makes it a little difficult to move into
> nofib.
> I'm working on other scheduler changes that may help you guys out; we
> should keep each other updated.
>
That would be great :)
>
> I noticed
OK. I think it is high priority for us to get some latency benchmarks
into nofib so that GHC devs (including me) can start measuring changes
off them. I know Edsko has some benchmarks here:
http://www.edsko.net/2013/02/06/performance-problems-with-threaded/
but they depend on network which makes
> >
> > Simon
> >
> > From: parallel-hask...@googlegroups.com [mailto:
> parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy
> > Sent: 06 February 2013 14:28
> > To: watson.timo...@gmail.com
> > Cc: kosti...@gmail.com; parallel-haskell;
> glas
legroups.com
> [mailto:parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy
> Sent: 06 February 2013 14:28
> To: watson.timo...@gmail.com
> Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@haskell.org
> Subject: Re: Cloud Haskell and network latency issues wit
-hask...@googlegroups.com
[mailto:parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy
Sent: 06 February 2013 14:28
To: watson.timo...@gmail.com
Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@haskell.org
Subject: Re: Cloud Haskell and network latency issues with -threaded
addressed all of the issues listed there in
> Network.Transport.TCP, with the exception of the first (the -threaded
> issue). As Tim points out, this is not a Cloud Haskell specific issue; I
> have written this up as a short blog post at
> http://www.edsko.net/2013/02/06/perform
Hi Kostirya,
I'm putting the parallel-haskell and ghc-users lists on cc, just in case other
(better informed) folks want to chip in here.
First of all, I'm assuming you're talking about network latency when compiling
with -threaded - if not I apologise for misunderstan
On 23/01/2012 14:54, John Lato wrote:
I agree the OS scheduler is likely to contribute to our different
observations. I'll try to test with ghc-7.4-rc1 tonight to see if I
get similar results to 7.2.1.
If you want to see some code I'll post it, although I doubt it's
necessary. I would apprecia
I agree the OS scheduler is likely to contribute to our different
observations. I'll try to test with ghc-7.4-rc1 tonight to see if I
get similar results to 7.2.1.
If you want to see some code I'll post it, although I doubt it's
necessary. I would appreciate it if you (or someone else in the kno
On Monday 23 January 2012, 14:26:13, Simon Marlow wrote:
> Another possibility is a difference in OS scheduling behaviour between
> yours and Daniel Fischer's setup. In microbenchmarks like this, it's
> easy for a difference in OS scheduling behaviour to make a large
> difference in performance
d this with GHC-7.2.1, however Daniel Fischer reported that,
with ghc-7.2.2, he observed different behavior (which matches your
explanation AFAICT). Is it possible that the scheduling of callbacks
into Haskell changed between those versions?
Thanks,
John L.
From: Simon Marlow
Subject: Re: Runti
ime performance degradation for multi-threaded C FFI
> callback
> To: Sanket Agrawal
> Cc: glasgow-haskell-users
> Message-ID: <4f1d2f4d.9050...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 21/01/2012 15:35, Sanket Agrawal wrot
is enabled in C
code
> (even when total number of function calls to Haskell remain
same). In my
> test, I called a Haskell function 5M times using two scenarios
(GHC 7.0.4,
> RHEL5, 12-core box):
>
>
>- Single-threaded C function: call back
lti-threading is enabled in C code
> > (even when total number of function calls to Haskell remain same). In my
> > test, I called a Haskell function 5M times using two scenarios (GHC
> 7.0.4,
> > RHEL5, 12-core box):
> >
> >
> >- Single-threaded C function:
est, I called a Haskell function 5M times using two scenarios (GHC 7.0.4,
> RHEL5, 12-core box):
>
>
>- Single-threaded C function: call back Haskell function 5M times -
>Total time 1.32s
>- 5 threads in C function: each thread calls back the Haskell function 1M
>time
eading is enabled in C code
> (even when total number of function calls to Haskell remain same). In my
> test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4,
> RHEL5, 12-core box):
>
>
>- Single-threaded C function: call back Haskell function 5M times
Haskell function 5M times using two scenarios (GHC 7.0.4,
RHEL5, 12-core box):
- Single-threaded C function: call back Haskell function 5M times -
Total time 1.32s
- 5 threads in C function: each thread calls back the Haskell function 1M
times - so, total is still 5M - Total time 7.79s
I just noticed that I/O performane on Windows without -threaded is
pretty terrible. The following program:
main = getConetnts >>= putStr
tested with a 1MB file:
$ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs
$ ./cat <1M >/dev/null +RTS -s
Total time0.28s ( 0.49s elapsed)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/29/10 18:36 , Bryan O'Sullivan wrote:
> On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton <mailto:w...@freegeek.org>> wrote:
>
> So I've just started playing around with STM and -threaded programs and
>
On 11/30/10 11:05 AM, Simon Marlow wrote:
On 30/11/10 05:49, wren ng thornton wrote:
I'll see if I can make a workaround with that, but as I said: Simon's
already confirmed that this is a bug, I'm just looking for a ticket
number or a version where it's fixed.
And fix it I did:
Wed Jan 27 11:
On 30/11/10 05:49, wren ng thornton wrote:
On 11/29/10 6:36 PM, Bryan O'Sullivan wrote:
On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton
wrote:
So I've just started playing around with STM and -threaded programs and
I've run into a bug. The bug is similar to [1] except t
On Mon, Nov 29, 2010 at 9:49 PM, wren ng thornton wrote:
> Isn't that pretty normal?
>>
>
> The blocking for someone to open the other end is perfectly normal. The
> fact that compiling with -threaded takes a perfectly working program and
> makes it consistently cra
On 11/29/10 6:36 PM, Bryan O'Sullivan wrote:
On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton wrote:
So I've just started playing around with STM and -threaded programs and
I've run into a bug. The bug is similar to [1] except that the file in
question is a Posix FIFO instead
On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton wrote:
> So I've just started playing around with STM and -threaded programs and
> I've run into a bug. The bug is similar to [1] except that the file in
> question is a Posix FIFO instead of a Bluetooth device. Same behavi
So I've just started playing around with STM and -threaded programs and
I've run into a bug. The bug is similar to [1] except that the file in
question is a Posix FIFO instead of a Bluetooth device. Same behavior:
always errors with -threaded, but expected behavior when not -thre
Oh, there's quite a simple fix for this: don't have the FFI call
handle the SIGINT; only handle a signal the RTS generates. I guess
we should do a little more legwork to make sure interruptible(?) user threads
don't see signals.
Edward
___
Glasgow-haske
On 12/11/2010 17:25, Donn Cave wrote:
Quoth Simon Marlow,
...
Is there anything that we could do in GHC to improve the situation? I
suppose we could have a dedicated OS thread who's job it was to sit
around and run the signal handler every Nth of a second.
Since the -threade
Quoth Simon Marlow ,
...
> Is there anything that we could do in GHC to improve the situation? I
> suppose we could have a dedicated OS thread who's job it was to sit
> around and run the signal handler every Nth of a second.
Since the -threaded RTS automatically spawns a coup
On Fri, Nov 12, 2010 at 8:07 AM, Simon Marlow wrote:
> Is there anything that we could do in GHC to improve the situation? I
> suppose we could have a dedicated OS thread who's job it was to sit around
> and run the signal handler every Nth of a second.
>
Maybe that would work, or masking out R
On 11/11/2010 22:41, Bryan O'Sullivan wrote:
On Thu, Nov 11, 2010 at 2:32 PM, Edward Z. Yang mailto:ezy...@mit.edu>> wrote:
I was under the impression we fixed this:
http://hackage.haskell.org/trac/ghc/ticket/850
That is, we should be using SIGVTALRM, not SIGALRM, these days, excep
Quoth Simon Hengel ,
>> > ghc --make -threaded -lcurses Main.hs
>>
>> I bet, if you switch off the barrage of thread scheduling SIGALRMs,
>> +RTS -V0 -RTS , it will work like it's supposed to.
>
> That helped, thanks!
Great, but, beware - I am not full
On Thu, Nov 11, 2010 at 2:32 PM, Edward Z. Yang wrote:
> I was under the impression we fixed this:
>
>http://hackage.haskell.org/trac/ghc/ticket/850
>
> That is, we should be using SIGVTALRM, not SIGALRM, these days, except
> under certain conditions when your operating system doesn't support
Excerpts from Donn Cave's message of Thu Nov 11 17:07:20 -0500 2010:
> > ghc: 6.12.1
> > linux: 2.6.32
> > ncurses: 5.7
>
> Someone probably should. It's tempting to conclude that the bug
> is in ncurses, and perhaps it is, and maybe there's nothing to be
> done about it anyway, but a langu
> > ghc --make -threaded -lcurses Main.hs
>
> I bet, if you switch off the barrage of thread scheduling SIGALRMs,
> +RTS -V0 -RTS , it will work like it's supposed to.
That helped, thanks!
Cheers,
Simon
___
Glasgow-haskel
Quoth Simon Hengel ,
...
> This works just fine if I do not use the threaded RTS, say:
>
> ghc --make -lcurses Main.hs
>
> However, with
>
> ghc --make -threaded -lcurses Main.hs
I bet, if you switch off the barrage of thread scheduling SIGALRMs,
+RTS -V0 -RTS , i
getch
endwin
print c
This works just fine if I do not use the threaded RTS, say:
ghc --make -lcurses Main.hs
However, with
ghc --make -threaded -lcurses Main.hs
it prints -1 immediately without awaiting the 3 seconds.
Is that considered a bug? Should I open a ticket?
ghc: 6.12.1
Relatedly, it seems that it takes a nontrivial amount of time for
the multithreaded RTS to "realize" that a thread has emitted a
signal. I wonder if there's a more direct way an FFI call can say
"when I get back to Haskell, immediately start propagating an exception."
Edward
_
I've been poking the bad behavior Brian described here:
http://blog.ezyang.com/2010/08/interrupting-ghc/comment-page-1/#comment-1334
and in the process noticed something kind of interesting about
thread scheduling in non-multithreaded mode (i.e. without -threaded).
When the single-thr
-> Int
fib n
| n< 1 = error "n< 1"
| n == 1= 1
| n == 2= 1
| otherwise = fib (n-1) + fib(n-2)
fibs = parMap rdeepseq fib $ [1..100]
main = do
mapM_ (putStrLn . show) $ zip [1..] fibs
ghc -fllvm -threaded -rtsopts -O2 Prog.hs
./Prog -- runs slowly
n == 1= 1
| n == 2= 1
| otherwise = fib (n-1) + fib(n-2)
fibs = parMap rdeepseq fib $ [1..100]
main = do
mapM_ (putStrLn . show) $ zip [1..] fibs
ghc -fllvm -threaded -rtsopts -O2 Prog.hs
./Prog -- runs slowly through 1..100 [OK]
./Prog +RTS -N2 -RTS -- requests all available m
Quoth Simon Marlow ,
>> ... Does the wrapper rts_lock() account
>> for everything, or do threads need some initial setup I need to
>> account for?
>
> Nope, as long as the RTS is initialised properly via hs_init() you
> should be able to make callbacks from any OS thread.
Thanks - I'm sorry to
On 13/03/2010 22:54, Donn Cave wrote:
Quoth Simon Marlow,
...
So it was surprising when this turned out to be incompatible
with the -threaded link option. With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return from the callback
Quoth Simon Marlow ,
...
>> So it was surprising when this turned out to be incompatible
>> with the -threaded link option. With that option, I get one
>> callback from a non-main thread, and then that native thread
>> will die, shortly after return from the callback.
>
that thread.
So it was surprising when this turned out to be incompatible
with the -threaded link option. With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return from the callback.
You'll need to elaborate a little. When you sa
this turned out to be incompatible
with the -threaded link option. With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return from the callback.
Results without -threaded are not really so good either (the
application may run and work
On 18/12/2009 17:40, Mitar wrote:
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd<- openFd "/dev/rfcomm0" ReadWrite Nothing
Hi!
On Fri, Dec 18, 2009 at 7:15 PM, Donn Cave wrote:
> setSignalMask fullSignalSet
> fd <- openFd ...
> setSignalMask emptySignalSet
Thanks! This did it. At the end it is enough to block just
virtualTimerExpired signal and it works. Probably it is something RTS
is using int
;- openFd ...
setSignalMask emptySignalSet
I'm not in a position to try it in exactly the same situation, but
I see that when I run with all signals blocked as above, after a while
I have a SIGALRM pending (with -threaded or not), so I reckon that might
be the signal used by the runtime thread manager.
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd <- openFd "/dev/rfcomm0" ReadWrite Nothing OpenFileFlags { append =
False, noctty = Tr
anted parallelism,
and for that you need multiple CPUs, and hence multiple OS threads.
Well, I'm interested in getting an absolute speedup. If the threaded
performance on a single core is slightly slower than the non-threaded
performance on a single core, that would be OK provided that the
threaded p
lelism,
> and for that you need multiple CPUs, and hence multiple OS threads.
Well, I'm interested in getting an absolute speedup. If the threaded
performance on a single core is slightly slower than the non-threaded
performance on a single core, that would be OK provided that the
threaded p
Malcolm Wallace wrote:
Simon Marlow wrote:
Malcolm Wallace wrote:
For the only application I tried, using the threaded RTS imposes a
100% performance penalty - i.e. computation time doubles, compared
to the non-threaded RTS. This was with ghc-6.8.2, and maybe the
overhead has improved since
Simon Marlow wrote:
> Malcolm Wallace wrote:
> >
> > For the only application I tried, using the threaded RTS imposes a
> > 100% performance penalty - i.e. computation time doubles, compared
> > to the non-threaded RTS. This was with ghc-6.8.2, and maybe the
>
Simon Marlow wrote:
>> I would also add: does the threaded RTS support all platforms? For
>> instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't
>> run there, but GHC does. If you drop the non-threaded RTS, does that
>> mean that GHC doesn'
l.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break forkProcess entirely,
these bindings would have to do something different. The issue: users
of the FUSE C api will get daemonized using daemon(2); it'd be
nice if GHC fuse programs could behave similarly.
I also use f
n/hackage-scripts/package/HFuse
>>> http://code.haskell.org/hfuse/System/Fuse.hsc
>>>
>>> If removing the non-threaded RTS would break forkProcess entirely,
>>> these bindings would have to do something different. The issue: users
>>> of the FUSE C api will
e non-threaded RTS would break forkProcess entirely,
these bindings would have to do something different. The issue: users
of the FUSE C api will get daemonized using daemon(2); it'd be
nice if GHC fuse programs could behave similarly.
I also use forkProcess extensively: in HSH, for instance, whi
Brian B wrote:
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would
Malcolm Wallace wrote:
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amou
Brian B wrote:
> Hi Bulat,
>
> My contribution to the survey: I've used forkProcess to daemonize
> a ghc program inside the haskell fuse bindings:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
> http://code.haskell.org/hfuse/System/Fuse.hsc
>
>
> > Had you deprecated the non-threaded RTS, we would probably have no
> > problems described in ticket #2848 :-/
>
> > I think you'll have to deprecate it anyway, because it will be more
> > and more difficult to maintain two versions of code,
>
> we may c
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break forkPr
Hello Tomasz,
Saturday, December 6, 2008, 10:52:39 PM, you wrote:
> Had you deprecated the non-threaded RTS, we would probably have no problems
> described in ticket #2848 :-/
> I think you'll have to deprecate it anyway, because it will be more
> and more difficult
> to m
On Thu, Mar 1, 2007 at 5:21 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
> In fact you should think of the non-threaded RTS as deprecated. It isn't
> Haskell'-compliant, for one thing (assuming that Haskell' will probably
> require non-blocking foreign calls)
Yitzchak Gale wrote:
Judah Jacobson wrote:
I'm writing a program that reads input from the user but should also
handle a ctrl-c...
It works fine compiled without -threaded, but with -threaded
it blocks forever after a ctrl-c.
Simon Marlow wrote:
Ah, this is a consequence of the chan
Judah Jacobson wrote:
>> I'm writing a program that reads input from the user but should also
>> handle a ctrl-c...
>> It works fine compiled without -threaded, but with -threaded
>> it blocks forever after a ctrl-c.
Simon Marlow wrote:
> Ah, this is a consequenc
Brandon S. Allbery KF8NH wrote:
On 2008 Jun 11, at 0:43, Simon Marlow wrote:
Unix semantics just isn't the right thing when it comes to
non-blocking I/O. If only there were non-blocking read()/write()
system calls, we'd be fine.
Have you considered using aio_read() and company?
aio is n
On 2008 Jun 11, at 0:43, Simon Marlow wrote:
Unix semantics just isn't the right thing when it comes to non-
blocking I/O. If only there were non-blocking read()/write() system
calls, we'd be fine.
Have you considered using aio_read() and company?
--
brandon s. allbery [solaris,freebsd,p
Judah Jacobson wrote:
Hi all,
I'm writing a program that reads input from the user but should also
handle a ctrl-c. My attempt is below; the program forks a thread to
read one character of input, and kills that thread upon receiving a
sigINT. It works fine compiled without -threaded, but
Hi all,
I'm writing a program that reads input from the user but should also
handle a ctrl-c. My attempt is below; the program forks a thread to
read one character of input, and kills that thread upon receiving a
sigINT. It works fine compiled without -threaded, but with -threaded
it b
2008/2/11 John Vogel <[EMAIL PROTECTED]>:
> The only issue now is that terminateProcess doesn't always terminate
> netstat.exe in the cmd.exe so I don't get an exit condition.
A simple way is to use runInteractiveProcess instead of
runInteractiveCommand. The former doesn't start a new cmd.exe but
John Vogel wrote:
Thankyou both Don Stewart and Simon Marlow for your responses.
By adding yield and threadDelay in certain spots I have at least prevented
some of the threads from being starved of CPU time.
The only issue now is that terminateProcess doesn't always terminate
netstat.exe
>
> Thankyou both Don Stewart and Simon Marlow for your responses.
By adding yield and threadDelay in certain spots I have at least prevented
some of the threads from being starved of CPU time.
The only issue now is that terminateProcess doesn't always terminate
netstat.exe in the cmd.exe so I
John Vogel wrote:
I am running my program in WinXP with ghc 2.6.8
If you install netstat and change the parameters it should still work in
linux.
Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?
I can't use the sleep function in Syste
jpvogel1:
>I am running my program in WinXP with ghc 2.6.8
>
>If you install netstat and change the parameters it should still work in
>linux.
>
>Why does thread # 3 dominate over the over threads int the output?
>Why does thread # 4 never seem to run?
>
>I can't use the
I am running my program in WinXP with ghc 2.6.8
If you install netstat and change the parameters it should still work in
linux.
Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?
I can't use the sleep function in System.Process.Win32 since
H Shelarcy,
Thanks for your reply.
I have removed the -threaded when building the library and now
everything builds correctly and the examples are all working. However, I
would like to explore porting the library to use a small FFI library
which will allow exporting flattened data parallel
then installed
> the NDP library from the tar ball. Following the build instructions in
> the README I got to building the library which resulted in the following
> error being reported:
>
>
> ghc-6-6.1: combination not supported: Threaded/Profiling
>
>This seems to be do
I got to building the library which resulted in the following
error being reported:
ghc-6-6.1: combination not supported: Threaded/Profiling
This seems to be down to the fact that -prof and -threaded have been
specified on a particular build line, although I emit not to be
completely sure
From: Ian Lynagh <[EMAIL PROTECTED]>
Subject: Re: ForeignPtr and -threaded
Date: Mon, 23 Jul 2007 09:22:01 +0100
> That's a documentation bug. In the HEAD it says:
>
> newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a)
> -- ^Turns a plain memory referenc
On Mon, Jul 23, 2007 at 11:07:40AM +0900, PHO wrote:
>
> same. The documentations of both Foreign.ForeignPtr (*1) and
> Foreign.Concurrent (*2) say "The only guarantee is that the finalizer
> runs before the program terminates."
That's a documentation bug. In the HEAD it says:
newForeignPtr :: F
From: Bulat Ziganshin <[EMAIL PROTECTED]>
Subject: Re: ForeignPtr and -threaded
Date: Sun, 22 Jul 2007 17:48:05 +0400
> try to add performGC at end - this should force collecting garbage and
> therefore printing of string. otherwise, it's ok - there is no guarantee
> that GC w
Hello PHO,
Sunday, July 22, 2007, 5:36:27 PM, you wrote:
> [2] Foreign.ForeignPtr
> The following code prints nothing when it isn't linked with -threaded
> RTS, but when it is, it *sometimes* prints "called" but not always.
> import Foreign.Marshal.Alloc
&g
Hi,
I have encountered a weird behavior of ForeignPtr. I want to know how
to work around this. I am using GHC 6.6.1 on Darwin.
[1] Foreign.Concurrent
The following code prints "called" when it is linked with -threaded
RTS, but it prints nothing when it isn't.
import Foreig
Bryan O'Sullivan wrote:
Stefan O'Rear wrote:
I don't beleive the GHC team would be interested in receiving any
patches to the non-threaded RTS, since it is scheduled for removal in
6.8 IIRC (leaving only threaded).
But the threaded RTS calls select, too, only from Haskell ins
Stefan O'Rear wrote:
I don't beleive the GHC team would be interested in receiving any
patches to the non-threaded RTS, since it is scheduled for removal in
6.8 IIRC (leaving only threaded).
But the threaded RTS calls select, too, only from Haskell instead of C.
So the probl
On Wed, May 30, 2007 at 09:21:36PM -0700, Bryan O'Sullivan wrote:
> I notice that select is a bit of a bottleneck in the non-threaded RTS
> once lots of sockets are in play. Between kernel and userspace, many a
> cycle are wasted once we go past a few hundred clients. On som
I notice that select is a bit of a bottleneck in the non-threaded RTS
once lots of sockets are in play. Between kernel and userspace, many a
cycle are wasted once we go past a few hundred clients. On some
operating systems, the fixed nature of fd_set imposes a surprisingly low
ceiling on the
y due my ignorance :) my program anyway uses
-threaded and forkOS in order to run several C threads si,ultaneously
and i don't performed tests in any other conditions
so, one thread may read data from file, another thread write data and
one more make compression using C routine. in 6.4, t
John Goerzen wrote:
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
>From reading the docs, it sounds like forkIO keeps everything in a
single OS thread/process. Doesn't this mean that a program that uses
forkIO instead of forkOS loses out on SMP machines?
You can use e.g. +RTS -N2
(and it is usually better to use
> forkIO).
it may be entirely due my ignorance :) my program anyway uses
-threaded and forkOS in order to run several C threads si,ultaneously
and i don't performed tests in any other conditions
so, one thread may read data from file, another thread write d
On Mon, Mar 05, 2007 at 10:23:53AM -0600, John Goerzen wrote:
> On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
> > > >From reading the docs, it sounds like forkIO keeps everything in a
> > > single OS thread/process. Doesn't this mean that a program that uses
> > > forkIO instead of f
John Goerzen wrote:
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
>From reading the docs, it sounds like forkIO keeps everything in a
single OS thread/process. Doesn't this mean that a program that uses
forkIO instead of forkOS loses out on SMP machines?
You can use e.g. +RTS -N2
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
> > >From reading the docs, it sounds like forkIO keeps everything in a
> > single OS thread/process. Doesn't this mean that a program that uses
> > forkIO instead of forkOS loses out on SMP machines?
>
> You can use e.g. +RTS -N2 to use
Ian Lynagh wrote:
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote:
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
There seems to be a common misconception that forkOS is necessary to get
certain kinds of concurrency, and forkIO won't do. I don't know where this
com
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote:
> On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
> > There seems to be a common misconception that forkOS is necessary to get
> > certain kinds of concurrency, and forkIO won't do. I don't know where this
> > comes from
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
> There seems to be a common misconception that forkOS is necessary to get
> certain kinds of concurrency, and forkIO won't do. I don't know where this
> comes from: the documentation does seem to be quite clear to me. The only
> re
1 - 100 of 179 matches
Mail list logo
