Re: detecting memory size?
Joachim Durchholz [EMAIL PROTECTED] writes: What I really want is the amount of memory my application can allocate and excercise lively without causing thrashing. On my Linux computer, that amounts more or less to the installed, physical RAM, minus a bit, so I'll settle for that. :-) An easier way would be to make this a configuration option at installation time - the justification being that users probably have a better idea of how much RAM should be allowed to the program. Actually, there is currently a parameter to use at run-time. The problem is that it is a time/space trade-off; if this parameter is set too conservatively, the program will be unnecessarily slow, if too liberal, the program will thrash, giving you on average about 5% CPU. In this case, it's better to crash early with OOM. (And the optimal setting depends on the data -- not just data size.) So the point of this excercise is to attempt to automatically determine a reasonable default. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: detecting memory size?
On Thu, Jan 29, 2004 at 01:13:28PM +0100, Ketil Malde wrote:
My aplogies for being unclear! What I really want is the amount of
memory my application can allocate and excercise lively without
causing thrashing. On my Linux computer, that amounts more or less to
the installed, physical RAM, minus a bit, so I'll settle for that. :-)
(After browsing various information, it seems I'm after the minimum of
physical RAM and getrlimit(RLIMIT_DATA)).
I use the following with ghc. You don't really want to do this in haskell,
since there's no way to set the RTS values from haskell anyways.
#include Rts.h
#include RtsFlags.h
#include unistd.h
void defaultsHook (void) {
RtsFlags.GcFlags.maxStkSize = 8*102 / sizeof(W_); /* 8M */
#ifdef _SC_PHYS_PAGES
unsigned long long pagesize = sysconf(_SC_PAGESIZE);
unsigned long long numpages = sysconf(_SC_PHYS_PAGES);
unsigned long long mhs = 2*numpages*pagesize;
RtsFlags.GcFlags.maxHeapSize = 1ULL+mhs/BLOCK_SIZE_W;
#endif
}
--
David Roundy
http://civet.berkeley.edu/droundy/
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problem with ghc on Windows ME
In released software, I'm using only system so far, so won't be affected negatively. But I still haven't managed to work around the works in win98/fails in winXP problem I mentioned, and have so far avoided trying rawSystem because of the version problem. If you can offer a workaroung to the version problem, I'll try whether rawSystem is any help in my case. I've attached a standalone rawSystem implementation that works on both 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want 6.0.1 support for Unix too you'll need an extra .c file). I'd be interested to know if this helps with your win98/winXP problem; at the least it should free you from having to think about one layer of quoting. Generally, it'd be great if working code would less often break with new releases (oh, and a portable popen2, while we're at it!-). We try our best! Remember that patchlevel releases only fix bugs, never change interfaces, so working code should never break when moving to a new patchlevel release. Major releases can change interfaces. We also do a great deal of testing on every release, but bugs inevitably creep in, especially on platforms other than our main development platform (Linux). Which is why we're grateful for any help we can get from the community... Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problem with ghc on Windows ME
[ file actually attached this time... ] In released software, I'm using only system so far, so won't be affected negatively. But I still haven't managed to work around the works in win98/fails in winXP problem I mentioned, and have so far avoided trying rawSystem because of the version problem. If you can offer a workaroung to the version problem, I'll try whether rawSystem is any help in my case. I've attached a standalone rawSystem implementation that works on both 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want 6.0.1 support for Unix too you'll need an extra .c file). I'd be interested to know if this helps with your win98/winXP problem; at the least it should free you from having to think about one layer of quoting. Generally, it'd be great if working code would less often break with new releases (oh, and a portable popen2, while we're at it!-). We try our best! Remember that patchlevel releases only fix bugs, never change interfaces, so working code should never break when moving to a new patchlevel release. Major releases can change interfaces. We also do a great deal of testing on every release, but bugs inevitably creep in, especially on platforms other than our main development platform (Linux). Which is why we're grateful for any help we can get from the community... Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users RawSystem.hs Description: RawSystem.hs ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with ghc on Windows ME
Simon Peyton-Jones ([EMAIL PROTECTED]) wrote:
Simon and I spent an hour getting to the bottom of Gour's problem.
Thank you very much for taking the issue. It's very much appreciated.
Simon M sent round a source patch yesterday. It'd be great if someone
could confirm that it really works.
I applied your patch to my 6.2 source tree in my attempt to build 6.2 from
source in MSYS/MinGW environment and so far - it looks good. I can invoke
ghc-inplace and get:
$ /ghc/ghc-6.2/ghc/compiler/stage1/ghc-inplace
Glasgow Haskell Compiler, Version 6.2, for Haskell 98, compiled by GHC version 6.0.1
Using package config file: c:\ghc\ghc-6.2\ghc\driver\package.conf.inplace
Packages
Package
{name = rts,
auto = False,
import_dirs = [],
source_dirs = [],
library_dirs =
[c:/ghc/ghc-6.2/ghc/rts, c:/ghc/ghc-6.2/ghc/rts/gmp],
hs_libraries = [HSrts],
extra_libraries = [m, gmp, wsock32, mingwex],
include_dirs = [c:/ghc/ghc-6.2/ghc/includes],
c_includes = [Stg.h],
package_deps = [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts =
[-u,
_GHCziStable_StablePtr_con_info,
-u,
_GHCziBase_False_closure,
-u,
_GHCziBase_True_closure,
-u,
_GHCziPack_unpackCString_closure,
-u,
_GHCziIOBase_stackOverflow_closure,
-u,
_GHCziIOBase_heapOverflow_closure,
-u,
_GHCziIOBase_NonTermination_closure,
-u,
_GHCziIOBase_BlockedOnDeadMVar_closure,
-u,
_GHCziIOBase_Deadlock_closure,
-u,
_GHCziWeak_runFinalizzerBatch_closure,
-u,
___stginit_Prelude],
framework_dirs = [],
extra_frameworks = []}
Hsc static flags: -static
*** Deleting temp files
Deleting:
c:\ghc\ghc-6.2\ghc\compiler\stage1\ghc.exe: no input files
Usage: For basic information, try the `--help' option.
(I don't have cygwin installed so I'm waiting for a new *.msi to test more
thoroughly.)
However, I hit another problem in my build problem - pls. see MSYS build
thread in cvs-ghc.
Sincerely,
Gour
--
Gour
[EMAIL PROTECTED]
Registered Linux User #278493
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: linking problems after switching from GHC5 to GHC6
Volker Wysk wrote: I've put together a minimal program which reproduces the problem. Save the three attachments in a new directroy and type make. I'ts just as described earlier. The trivial program compiles with GHC5, but not GHC6. [...] Hmmm, it looks like GHC is reversing the order of files in the linking step. Mentioning liba.a *before* Main.o in the linking step is a workaround... Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: linking problems after switching from GHC5 to GHC6
This is a 6.x bug; I fixed it in HEAD a while back, http://haskell.org/pipermail/cvs-ghc/2003-October/018991.html but the change wasn't merged for some reason. --sigbjorn - Original Message - From: Sven Panne [EMAIL PROTECTED] To: Volker Wysk [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 30, 2004 08:28 Subject: Re: linking problems after switching from GHC5 to GHC6 Volker Wysk wrote: I've put together a minimal program which reproduces the problem. Save the three attachments in a new directroy and type make. I'ts just as described earlier. The trivial program compiles with GHC5, but not GHC6. [...] Hmmm, it looks like GHC is reversing the order of files in the linking step. Mentioning liba.a *before* Main.o in the linking step is a workaround... Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
