Hi Simon.
On Mon, Jul 30, 2012 at 12:00 PM, Simon Marlow marlo...@gmail.com wrote:
(...)
Is it possible that the String you are passing to uLog contains unevaluated
calls to uLog itself, which would thereby create a deadlock as uLog tries to
take the MVar that is already being held by the same
Hi.
I'm having a problem calling logM from hsLogger inside
unsafePerformIO. I have described the problem in Haskell-cafe, so
I'll avoid repeating it here:
http://www.haskell.org/pipermail/haskell-cafe/2012-July/102545.html
I've had this problem both with GHC 7.4.1 and 7.4.2. Do you have any
On 30/07/2012 15:30, Marco Túlio Gontijo e Silva wrote:
Hi.
I'm having a problem calling logM from hsLogger inside
unsafePerformIO. I have described the problem in Haskell-cafe, so
I'll avoid repeating it here:
http://www.haskell.org/pipermail/haskell-cafe/2012-July/102545.html
I've had
On 07/04/2011 13:51, Björn Peemöller wrote:
Simon Marlow schrieb:
Incidentally this will be faster with GHC 7.2, because we implemented
chunked stacks, so unsafePerformIO never has to traverse more than 32k
of stack (you can tweak the chunk size with an RTS option). This is
still quite a lot
Simon Marlow schrieb:
Incidentally this will be faster with GHC 7.2, because we implemented
chunked stacks, so unsafePerformIO never has to traverse more than 32k
of stack (you can tweak the chunk size with an RTS option). This is
still quite a lot of overhead, but at least it is bounded
2011/3/25 Thomas Schilling nomin...@googlemail.com:
unsafePerformIO traverses the stack to perform blackholing. It could
be that your code uses a deep stack and unsafePerformIO is repeatedly
traversing it. Just a guess, though.
Sounds reasonable. Here is a variant of the program without
On 25/03/2011 08:56, Sebastian Fischer wrote:
2011/3/25 Thomas Schillingnomin...@googlemail.com:
unsafePerformIO traverses the stack to perform blackholing. It could
be that your code uses a deep stack and unsafePerformIO is repeatedly
traversing it. Just a guess, though.
Sounds reasonable
Hello,
we have a strange performance behaviour when we use unsafePerformIO, at
least with GHC 6.12.3 and 7.0.1.
Please consider the example program following at the end of this post.
Running the original code the execution time is about 26 seconds, while
uncommenting one (or both
unsafePerformIO traverses the stack to perform blackholing. It could
be that your code uses a deep stack and unsafePerformIO is repeatedly
traversing it. Just a guess, though.
2011/3/24 Björn Peemöller b...@informatik.uni-kiel.de:
Hello,
we have a strange performance behaviour when we use
On 30/06/2010 18:13, Yitzchak Gale wrote:
Henning Thielemann wrote on Haskell Cafe:
Attached is a program with a space leak...
I have coded a simple 'map' function, once using unsafePerformIO and
once without. UnsafePerformIO has a space leak in some circumstances.
In the main program I
Henning Thielemann wrote on Haskell Cafe:
Attached is a program with a space leak...
I have coded a simple 'map' function, once using unsafePerformIO and
once without. UnsafePerformIO has a space leak in some circumstances.
In the main program I demonstrate cases with and without space leak
Simon Marlow wrote:
Perhaps there are some trivial examples of
unshared thunks that we could spot, though.
The sharing analysis in the interpreter is also very simple and
inexpensive. But the gain is frequent. Maybe giving it a try would be
worthwhile.
Thanks again for all your answers!
Bernd
removes them leaving you with O(1) stack again. The problem with
unsafePerformIO was that the duplication-protection was interfering with
stack squeezing.
Regarding sharing analysis, we did used to have an update analyser in GHC,
but it was expensive to run and rarely gave worthwhile benefits, so
I have got around the problem by defining my unsafe actions by the
foreign function interface. But I still think there is a bug concerning
stack use in unsafePerformIO in ghc. And I also think that this bug
potentially concerns every use of unsafe. Or did I just not get the
point of your argument
x) --no stack overflow
badStack x = unsafePerformIO (return x) --stack overflow
fromJust (Just x) = x
goodStack == id, and GHC even with no optimisation will transform it
into id, and inline it into sim. So with goodStack, sim ends up being
tail-recursive. With badStack, sim
Simon Marlow wrote:
So the upshot is: you can use unsafeDupablePerformIO right now, or you
can wait until I've tested and committed this patch to get
tail-recursion with unsafePerformIO.
Wow, thank you for the detailed answer! That was really interesting.
I've no idea how it works in Hugs
There is another point that makes me wonder now. If the update frame for
the recursive call is the problem then my solution with foreign C
functions would produce a bad stack also. But this is not the case.
The code looks now like this:
sim [] = True
sim (_:xs) = yags (sim xs)
ref =
Bernd Brassel wrote:
Consider the following program:
module Stack where
import System.IO.Unsafe
main = print (sim (replicate 1299959 ()))
sim [] = True
sim (_:xs) = goodStack (sim xs)
goodStack x = fromJust (Just x) --no stack overflow
badStack x = unsafePerformIO (return x
) --no stack overflow
badStack x = unsafePerformIO (return x) --stack overflow
fromJust (Just x) = x
goodStack == id, and GHC even with no optimisation will transform it
into id, and inline it into sim. So with goodStack, sim ends up being
tail-recursive. With badStack, sim is no longer tail
Consider the following program:
module Stack where
import System.IO.Unsafe
main = print (sim (replicate 1299959 ()))
sim [] = True
sim (_:xs) = goodStack (sim xs)
goodStack x = fromJust (Just x) --no stack overflow
badStack x = unsafePerformIO (return x) --stack overflow
Hello to all who have given me hints an suggestions about this topic
whether directly by mail or over the mailing list. I do now have a much
more concrete idea of how to optimize my programs.
Thanks for your time!
Bernd
___
Glasgow-haskell-users mailing
Hi Stefan!
Thanks for your answer.
Stefan O'Rear wrote:
Might I suggest, that the problem is your use of unsafePerformIO?
Yes you might. And you are surely right. But not using it in this way is
not an alternative.
why do you want to do this unsafely,
instead of just using 'length
Hi David,
thank you! This is really useful information!
I think it's the let floating (out) together with common subexpression
elimination:
ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs
[1 of 1] Compiling Main ( curry.hs, curry.o )
Linking curry-no-cse ...
On 10/17/07, Bernd Brassel [EMAIL PROTECTED] wrote:
why do you want to do this unsafely,
instead of just using 'length'? unsafePerformIO is a very slow
function, remember)
The big picture is that we generate programs like this example in order
to compile the functional logic language
Hi Bernd,
Bernd Brassel wrote:
Hi David,
thank you! This is really useful information!
I think it's the let floating (out) together with common subexpression
elimination:
ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs
[1 of 1] Compiling Main ( curry.hs,
I think you'll find it useful to be explicit about what you are relying on.
For example I think that if your program contains two calls
unsafePerformIO e1
unsafePerformIO e2
then
* You don't care about the *order* in which these are performed
* You do care that they are both
of the programs can run in a monad. This approach
should be more robust than relying on unsafePerformIO. It is also very
much in the spirit of your slogan.
Thank you for the suggestion. We were thinking along the lines of
identifying the purely functional parts and compile them directly to
pure
I think you'll find it useful to be explicit about what you are relying on.
Yes, good point.
For example I think that if your program contains two calls
unsafePerformIO e1
unsafePerformIO e2
then
* You don't care about the *order* in which these are performed
Right
Bernd Brassel wrote:
* I'm not sure if you care whether they are performed once or
many times. E.g.
f = \x. x + unsafePerformIO (h z)
If the (h z) doesn't mention 'x', GHC will transform this to
v = unsafePerformIO (h z)
f = \x. x+v
So now
part
---
(?) :: Bool' - Bool' - Bool'
x ? y = Or (unsafeNextOrRef ()) [x,y]
globalCounter :: IORef Int
globalCounter = unsafePerformIO (newIORef 0)
unsafeNextOrRef :: () - Int
unsafeNextOrRef _ = unsafePerformIO $ do
r - readIORef globalCounter
writeIORef globalCounter (r+1
Neil Mitchell schrieb:
It varies by each piece of code, can you post a code fragment that
gets optimised in the wrong way?
Sorry for posting this twice! I have added the code to the other thread.
Thanks!
Bernd
___
Glasgow-haskell-users mailing list
Hi,
I think it's the let floating (out) together with common subexpression
elimination:
ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs
[1 of 1] Compiling Main ( curry.hs, curry.o )
Linking curry-no-cse ...
ghc --make -O2 -no-recomp -fno-full-laziness -o
of unsafePerformIO? If
you use unsafePerformIO in accordance with the rules listed in the
specification (which happens to be the FFI addendum), -O options will
have no effect. (Not that what you are trying to do is achievable with
correct use of unsafePerformIO; why do you want to do this unsafely
Hello,
I am writing a compiler from the functional logic language Curry to
Haskell. As the result is a real extension of Haskell, there has to be
SOME side effect involved. Unfortunately, this seems to prevent me from
using any of ghc's optimizations on the resulting code. I have tried for
some
Neil Mitchell wrote:
Hi
Thanks to dcoutts, I have now come up with an answer. I don't
understand why it works now, but not before. I do remember than
browsing either Core or STG is not a fun thing to do...
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO $ getCharIO h
Hi Simon,
This is clearly a misuse of unsafePerformIO (as I'm sure you're aware). Just
out of interest - what's the context?
I am writing an optimiser for Yhc, doing whole-program optimisation,
with the intention of keeping it fast and high performance. Since
writing out Yhc bytecode would
Data.Word
import Debug.Trace
main = p_System_IO_hGetChar 1 `seq` p_System_IO_hGetChar 2 `seq` putStrLn done
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
foreign import ccall stdio.h getchar getchar :: IO Word8
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace
Hello Neil,
Wednesday, May 2, 2007, 7:00:05 PM, you wrote:
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
-fno-cse ? it's usual company for unsafePerformIO+NOINLINE :)
--
Best regards,
Bulatmailto:[EMAIL PROTECTED
Hi Bulat,
Wednesday, May 2, 2007, 7:00:05 PM, you wrote:
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
-fno-cse ? it's usual company for unsafePerformIO+NOINLINE :)
No luck, alas. A slightly tweaked version, which is slightly simpler
and still gives the same behaviour
Hi
Thanks to dcoutts, I have now come up with an answer. I don't
understand why it works now, but not before. I do remember than
browsing either Core or STG is not a fun thing to do...
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO $ getCharIO h
{-# NOINLINE getCharIO
that p_System_IO_hGetChar 1 is a constant) the
real problem is here:
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO $
getchar = \c -
print c
return (if c == (-1) then 0 else chr_ c)
You've tried to trick ghc into always calling
I wouldn't like if unsafePerformIO could never be inlined, sometimes
you want it inlined for performance.
And not all uses are hacky, it's just that when I use it, then burden
is on me to convince myself that it is safe.
On Mar 6, 2007, at 23:56 , Neil Mitchell wrote:
Hi
On 3/6/07
Lennart Augustsson wrote:
I wouldn't like if unsafePerformIO could never be inlined, sometimes you
want it inlined for performance.
And not all uses are hacky, it's just that when I use it, then burden is
on me to convince myself that it is safe.
unsafePerformIO is currently not inlined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Marlow wrote:
You're right that sometimes you really want it to be inlined - this is
why there's a function called inlinePerformIO in Data.ByteString.Base,
for example. You'd better really know what you're doing before using
that one,
I've noticed quite a few pages referencing constructs such as:
var :: MVar ([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
new MVars instead of all sharing one.
Having a reliable way to create a piece of global state would
On Tue, 06 Mar 2007 12:03:05 -0800
David Brown [EMAIL PROTECTED] wrote:
I've noticed quite a few pages referencing constructs such as:
var :: MVar ([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
new MVars instead
Seth Kurtzberg wrote:
On Tue, 06 Mar 2007 12:03:05 -0800
David Brown [EMAIL PROTECTED] wrote:
I've noticed quite a few pages referencing constructs such as:
var :: MVar ([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Brown wrote:
I've noticed quite a few pages referencing constructs such as:
var :: MVar ([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
new MVars instead of all
([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
new MVars instead of all sharing one.
Having a reliable way to create a piece of global state would be
very
convenient.
This operation is unsafe by definition. I use
Hi
On 3/6/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe.
Couldn't GHC bake in knowledge about unsafePerformIO, and never inline
it? It is a slightly hacky solution, but since unsafePerformIO is
pretty much only used
Neil Mitchell wrote:
On 3/6/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe.
Couldn't GHC bake in knowledge about unsafePerformIO, and never inline
it? It is a slightly hacky solution, but since unsafePerformIO is
pretty
[Redirecting to GHC users]
A crash is bad, and the HEAD reports an error in a civilised way. It is
indeed illegal to use atomically inside an unsafePerformIO.
I've also committed a fix to the documentation of atomically to mention
this point. In general, the documentation of STM is very thin
Am Dienstag, 13. September 2005 16:13 schrieb David Sabel:
Hi,
Hi!
I want to analyse the laziness of a data structure. To check how many
nodes are constructed I use a global counter.
counter :: IORef Int
counter = unsafePerformIO (newIORef 0)
This counter is increased every
Hello,
http://haskell.org/ghc/docs/latest/html/libraries/base/
System.IO.Unsafe.html#v%3AunsafePerformIO
talks about what optimizations you should disable if you apply unsafePerformIO
to an action which contains side effects. These are:
* inlining of functions which call
Hello All,
I think I've read somewhere that STM doesn't like unsafePerformIO.
However, I would like to use a global STM variable. Something like this:
*module* Main *where*
import GHC.Conc
import System.IO.Unsafe
tSid = unsafePerformIO (atomically (newTVar 0))
tickSessionID :: STM Int
Never mind, I can probably use an MVar to work around this...
Robert
Robert van Herk wrote:
Hello All,
I think I've read somewhere that STM doesn't like unsafePerformIO.
However, I would like to use a global STM variable. Something like this:
module Main where
import GHC.Conc
import
On Wed, Aug 03, 2005 at 12:50:54PM +0200, Robert van Herk wrote:
Hello All,
I think I've read somewhere that STM doesn't like unsafePerformIO.
However, I would like to use a global STM variable. Something like this:
module Main where
import GHC.Conc
import System.IO.Unsafe
tSid
On 03 August 2005 11:51, Robert van Herk wrote:
I think I've read somewhere that STM doesn't like unsafePerformIO.
However, I would like to use a global STM variable. Something like
this:
*module* Main *where*
import GHC.Conc
import System.IO.Unsafe
tSid = unsafePerformIO (atomically
Oh I see! Your sollutions are indeed a lot better than implementating
all my code using MVars :-).
Thanks,
Robert
Remi Turk wrote:
On Wed, Aug 03, 2005 at 12:50:54PM +0200, Robert van Herk wrote:
Hello All,
I think I've read somewhere that STM doesn't like unsafePerformIO.
However, I
Sven Panne wrote:
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pragma for clever compilers you can simulate something like a global
variable in Haskell. Here an excerpt from the GLUT menu handling module:
{-# NOINLINE theMenuTable #-}
theMenuTable
Hal Daume III wrote:
You can't. [...]
Well, you can, but only for CAFs. This idiom/hack is used
quite happily throughout GHC, HOpenGL, H/Direct, ...
I think quite happily is a bit strong ;-) We'd much rather have a
safe way to do what is really quite a reasonable thing.
Cheers,
I want to write something like
type State a = IORef a
newState :: a - State a
newState v = unsafePerformIO (newIORef v)
But I don't want the compileer to inline this nor to inline any
application of this.
{#NOINLINE newState#}
But how can I stop this function to be inlined when applied
:-)
global :: a - IORef a
global a = unsafePerformIO (newIORef a)
#define GLOBAL_VAR(name,value,ty) \
name :: IORef (ty) ; \
name = global (value) ; \
{-# NOINLINE name #-}
-- examples
]% grep global ghc/compiler/utils/Util.lhs
, global
global :: a - IORef a
global a = unsafePerformIO (newIORef a)
[233]%
ghc/compiler/HsVersions.h:
[...]
#ifdef __GLASGOW_HASKELL__
#define GLOBAL_VAR(name,value,ty) \
name = Util.global (value) :: IORef (ty); \
{-# NOINLINE name #-}
#endif
- Original Message -
From: Albert Lai [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 30, 2002 7:35 AM
Subject: Re: Optimisation and unsafePerformIO
David Sabel [EMAIL PROTECTED] writes:
{-# NOINLINE b #-}
b x = if even x then unsafePerformIO getChar else
David Sabel [EMAIL PROTECTED] writes:
{-# NOINLINE b #-}
b x = if even x then unsafePerformIO getChar else bot
bot = bot
main = do
putChar (b 4)
putChar (b 6)
I am not a compiler implementer (or lawyer, for that matter :)
But I propose this guess. First, both even
Consider the following program:
-
{-# NOINLINE b #-}
b x = if even x then unsafePerformIO getChar else bot
bot = bot
main = do
putChar (b 4)
putChar (b 6)
-
when you compile the programm
Of course, I used unsafePerformIO in an unsafe way!
I'm thinking about a way to make unsafePerformIO safe.
Therefore the compiler can't do any transformation the ghc does and I want
to locate these transformations.
- Original Message -
From: Simon Marlow [EMAIL PROTECTED]
To: David Sabel
Consider the following program:
-
{-# NOINLINE b #-}
b x = if even x then unsafePerformIO getChar else bot
bot = bot
main = do
putChar (b 4)
putChar (b 6)
-
when you compile the programm with the options: -O0
- Original Message -
From: Simon Marlow [EMAIL PROTECTED]
Sent: Tuesday, September 24, 2002 2:58 PM
Subject: RE: unsafePerformIO
[...]
As for sharing, we currently don't provide any guarnatees, although we
should. It is currently the case that if you write
a = unsafePerformIO
The actions performed by unsafePerformIO are simply done at some
entirely unpredictable time, perhaps interleaved with actions on the
main execution path.
The formal semantics in the notes doesn't have a good way to express
that because the purely-functional part is given a denotational
Simon Peyton-Jones wrote:
| The actions performed by unsafePerformIO are simply
| done at some entirely unpredictable time, perhaps
| interleaved with actions on the main execution path.
But it is a fact that many of us have at least some idea of
what happens under the hood when we use
But it is a fact that many of us have at least some idea of
what happens under the hood when we use unsafePerformIO.
This is also described in your paper Stretching the storage
manager: weak pointers and stable names in Haskell.
However, I for example have no idea what happens when
Koen
Based on this info, how would you like to write the notes you would like
to see on unsafePerformIO? The starting point is at
http://haskell.cs.yale.edu/ghc/docs/latest/html/base/GHC.IOBase.html#uns
afePerformIO
If you write the notes, we'll check their veracity and add them. We'll
do
different behaviour between Hugs and GHC when using
unsafePerformIO with threads and exceptions. The Hugs version of
unsafePerformIO isn't intended to receive as much abuse as the GHC
version whereas the GHC version has been (ab)used by large numbers of
people.
--
Alastair
In read your paper Tackling the Awkward Squad: monadic input / output,
concurrency, exceptions, and foreign-language calls in Haskell, and have
a question about unsafePerformIO.
In your operational semantic of the IO-Monad you tell nothing about, how
'unsafe' IO actions are performed
I'm not sure of a reference, the basic idea is this:
IO a is represented by the pair (RealWorld, a) (unboxed, really
but whatever)
When an IO action is run (via main), a RealWorld state is provided
by the compiler and passes it around.
When you do unsafePerformIO, the compiler
Hal Daume [EMAIL PROTECTED] writes:
I'm curious exactly what is safe and what is unsafe to wrap
unsafePerformIO around when it comes to FFI calls.
Here's a simple test:
Could you imagine an alternative implementation of the same API in
pure Haskell? (Don't consider efficiency
That's a nice succinct way to describe it. Another way, which boils
down to the same thing but which is a little more concrete, is to
ask:
- Does the function's result depend only on the values of its
arguments?
I have two problems with this alternative test:
1) It is sometimes
a function which uses some temporary
allocation on the C heap as safe to use from unsafePerformIO. But its
side effect is visible from the IO monad by inspecting the C heap
pointer.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL
I'm curious exactly what is safe and what is unsafe to wrap
unsafePerformIO around when it comes to FFI calls. If there's a general
discussion of this somewhere and someone could send me a pointer that
would be another acceptable solution. I googled for unsafePerformIO
FFI but nothing relevant
Hal Daume [EMAIL PROTECTED] writes:
I'm curious exactly what is safe and what is unsafe to wrap
unsafePerformIO around when it comes to FFI calls.
Here's a simple test:
Could you imagine an alternative implementation of the same API in
pure Haskell? (Don't consider efficiency or effort
What's the difference between unIO and unsafePerformIO? And why is the
former safe? (I would like to apply the same questions to
unsafeIOToST and ioToST)
unIO is an internal function used in GHC's libraries, it is not for
external consumption. GHC represents the IO type using newtype
What's the difference between unIO and unsafePerformIO? And why is the
former safe? (I would like to apply the same questions to unsafeIOToST and
ioToST)
Thanks,
-- Andre
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org
84 matches
Mail list logo
