[Caml-list] ocamlopt and Windows DLL

[Caml-list] ocamlopt and Windows DLL

[Dmitry Bely]

I am trying to build COM component written in ocaml using ocamlopt
compiler. To achive that I have slightly modified camlidldll script from
camlidl distribution. Now it builds DLL without a problem, but resulting
DLL never executes "let _ = ..." (_*_entry) constructs! After a short
investigation I have found the following code that seems to be causing the
problem:

[--- cfactory.cpp ---]
/* DLL entry point */

BOOL APIENTRY DllMain(HANDLE module, DWORD reason, void *reserved)
{
  char * argv[1];

  switch(reason) {
  case DLL_PROCESS_ATTACH:
    argv[0] = NULL;
    camlidl_module_handle = (HMODULE) module;
#if 0
    int fd = open("d:\\work\\camllog", O_RDWR|O_TRUNC|O_CREAT, _S_IWRITE|_S_IREAD);
    dup2(fd, 1);
    dup2(fd, 2);
    close(fd);
#endif
    caml_startup(argv);
    break;
  /* TODO: free all memory when DLL detached */
  }
  return TRUE;
}
[--- cfactory.cpp ---]

caml_startup() is called here with the empty argv list (no surprise, that's
DLL). Manual says that this is not acceptable for proper initialization of
the caml runtime library.

Does this mean that it's absolutely impossible to build DLL using ocamlopt?
Maybe there is a workaround?

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Obsessed by speed

[Mattias Waldau]

In the FAQ, I can read an estimation on how expensive different operations
in ocamlopt are.

I have some further questions:
1. If I define Array.iter + a function that uses it,
   will ocamlopt combine these two functions two one?
   (I looked in the assembler code, but it seemed as
    ocamlopt didn't combine them)
2. Do we need special Pentium-4 adaptions to utilize
   its very good float performance?
3. Would ocamlopt benefit from a peephole optimizer of
   the assembler code? Or is the assembler code already
   optimal?
4. What is unboxed and what isn't?
   I have noticed that there is a
   continuos work to unbox more.
5. How do you make sense of gprof-output? Any suggestions?

--
Mattias Waldau, http://www.abc.se/~m10217/

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Obsessed by speed

[Chris Hecker]

>3. Would ocamlopt benefit from a peephole optimizer of
>   the assembler code? Or is the assembler code already
>   optimal?

I have seen lots of cases where a peephole optimizer (or a very special case ocamlopt optimizer that recognizes certain idioms) would help.  For example, lots of loops seem to keep any integers tagged even if they are only used inside the loop, and the asm untags them every time they're used.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Obsessed by speed

[William Chesters]

Mattias Waldau writes:
 > In the FAQ, I can read an estimation on how expensive different operations
 > in ocamlopt are.
 > 
 > I have some further questions:
 > 1. If I define Array.iter + a function that uses it,
 >    will ocamlopt combine these two functions two one?
 >    (I looked in the assembler code, but it seemed as
 >     ocamlopt didn't combine them)

That's been my experience too---definitely it would be nice to have!

 > 3. Would ocamlopt benefit from a peephole optimizer of
 >    the assembler code? Or is the assembler code already
 >    optimal?

I have generally found the backend to be very good indeed at the
assembler level.  Sometimes it gets things handed down to it from the
intermediate level (e.g. less-than-100% unboxing) which it couldn't
reasonably be expected to fix.  It's so much better than backends like
JDK, ghc, ... it isn't funny.

 > 4. What is unboxed and what isn't?

Integers are always unboxed anyway (they are tagged with a low 1 and
the arithmetic done on them is warped to accomodate it!).

Floats seem to be unboxed very well within an expression.  Float loop
variables in for-loops (sadly not tail-recursive expressions) stay
unboxed and indeed in registers, _provided_ that they are stored in
monomorphic records that are known at a high level to be
float-only---so not float ref (!!!).  Define e.g. type floatref = {
it: float }, works much better.

To a reasonable extent, whole objects are "unboxed" too, i.e. tuples
and records which are simply passed to functions which immediately
deconstruct them are elided and the components become available for
storing in registers.  I don't know to what extent this happens in
other situations but it is very helpful.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Obsessed by speed

[Xavier Leroy]

> 1. If I define Array.iter + a function that uses it,
>    will ocamlopt combine these two functions two one?
>    (I looked in the assembler code, but it seemed as
>     ocamlopt didn't combine them)

You're right, the function inlining pass in ocamlopt is rather
conservative and doesn't inline and beta-reduce function arguments to
higher-order functions.  Inlining is a delicate trade-off between too
little and too much (e.g. code size and compile time explosion), and
OCaml errs on the conservative side.

> 2. Do we need special Pentium-4 adaptions to utilize
>    its very good float performance?

I'm not familiar with the P4 micro-architecture, so I don't know.
ocamlopt uses the standard IA32 stack-based model for floating-point
code.  Apparently, the P4 can now do 64-bit float arithmetic between
true registers (the SSE2 model), and ocamlopt could generate better
(and simpler!) floating-point code for this model.  Don't know how
much of a performance difference that would make, though.  

At any rate, the ocamlopt port for AMD's x86-64 architecture will use
the SSE2 model.

> 3. Would ocamlopt benefit from a peephole optimizer of
>    the assembler code? Or is the assembler code already
>    optimal?

No assembly code is ever optimal, especially if machine-generated :-)
A peephole optimizer could remove some cosmetic inefficiencies, but I
doubt this would make a significant speed difference.  Today's
processors have enough instruction-level parallelism and dynamic
instruction scheduling that a few redundant integer operations here
and there don't really hurt.  

Other higher-level optimizations not currently performed could improve
performance more, e.g. common subexpression elimination on memory loads.

> 4. What is unboxed and what isn't?
>    I have noticed that there is a
>    continuos work to unbox more.

Very briefly:

Always unboxed:
  int, char, bool, constant constructors of datatypes.
Locally unboxed (in expressions and let...in): 
  float, int32, nativeint (and int64 on 64-bit processors)
Unboxed inside arrays:
  float
Unboxed inside big arrays:
  all numerical types
Always boxed:
  everything else (records, non-constant datatype constructors,
  tuples, arrays, etc)

> 5. How do you make sense of gprof-output? Any suggestions?

The "info" docs for gprof contain a tutorial.
The function names that appear are of the form Modulename_functionname_NNN
where NNN is a unique integer.
Be careful with the call graph reported by gprof: it is totally
inaccurate for higher-order functions.

Hope this answers your questions.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 589 bytes --]


This report describes adjustments of the ocaml
compiler to support better optimization of arrays for
numerical computing.

http://www.cs.cornell.edu/Courses/cs612/2001SP/projects/ocaml-arrays/OCaml.pdf

Is this something that is considered to be included in
future versions of ocaml?

Best Regards,
Peter Rönnquist


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 589 bytes --]


This report describes adjustments of the ocaml
compiler to support better optimization of arrays for
numerical computing.

http://www.cs.cornell.edu/Courses/cs612/2001SP/projects/ocaml-arrays/OCaml.pdf

Is this something that is considered to be included in
future versions of ocaml?

Best Regards,
Peter Rönnquist


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Brian Rogoff]

On Thu, 31 May 2001, Peter Ronnquist wrote:
> This report describes adjustments of the ocaml
> compiler to support better optimization of arrays for
> numerical computing.
> 
> http://www.cs.cornell.edu/Courses/cs612/2001SP/projects/ocaml-arrays/OCaml.pdf
> 
> Is this something that is considered to be included in
> future versions of ocaml?

Wow, the paper is dated May 7, 2001 and you already want to know if it is 
going to be in a future version. At this rate, INRIA will need a time
machine to peer into the future for developments!

Seriously, I remember reading that the implementors are looking a lot more
at making OCaml a better vehicle for scientific computing, so I suppose we 
can expect more in the future. I've been looking a little bit at SAC
lately (http://www.informatik.uni-kiel.de/~sacbase/), it is a strict
language based on C with some high level array constructs. It's very
interesting, and maybe when I get some more free time I'll hack up a 
SAC like interface to Bigarrays using P4. Yes, I know that the efficiency 
will not be good since SAC relies on optimizations of its "with-loop" 
construct to match C/Fortran performance, but the experiment would be to 
determine how comfortable SAC-in-OCaml really is. 

I think it's great that all of these scientific computing folks are coming
to Caml, as this will really strengthen the community by adding a new set 
of perspectives. When I was in gradual school it seemed that the numerics 
folks and the language theory folks didn't communicate, and that was a
shame. OCaml should be the premier scientific computing language in addition
to being the premier symbolic processing language!

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] report describing optimization of numerical computingof the ocaml compiler.

[John Max Skaller]

Brian Rogoff wrote:
> 
> On Thu, 31 May 2001, Peter Ronnquist wrote:
> > This report describes adjustments of the ocaml
> > compiler to support better optimization of arrays for
> > numerical computing.
> >
> > http://www.cs.cornell.edu/Courses/cs612/2001SP/projects/ocaml-arrays/OCaml.pdf
> >
> > Is this something that is considered to be included in
> > future versions of ocaml?
> 
> Wow, the paper is dated May 7, 2001 and you already want to know if it is
> going to be in a future version. At this rate, INRIA will need a time
> machine to peer into the future for developments!

	Please don't disabuse me. I though they already had one.
[But it isn't being released because the licence is GPL]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Tom _]

> Seriously, I remember reading that the implementors
> are looking a lot more
> at making OCaml a better vehicle for scientific
> computing, so I suppose we 
> can expect more in the future. I've been looking a
> little bit at SAC

I'd recommend also taking a look at SISAL
(http://www.llnl.gov/sisal/).

I think both SAC and SISAL are important
not only because they are functional languages,
but also because they define a syntax that is
quite natural for numerical applications without
sacrificing their functional foundations.

Tom.


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Niall Dalton]

> I'd recommend also taking a look at SISAL
> (http://www.llnl.gov/sisal/).
http://sourceforge.net/projects/sisal/ is a sourceforge project
with some recent developments on Sisal, headed by one of the original
developers.

Niall

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] SISAL (Was: report describing optimization of numerical computing...)

[Florian Hars]

On Thu, May 31, 2001 at 09:10:24PM -0700, Tom _ wrote:
> I'd recommend also taking a look at SISAL
> (http://www.llnl.gov/sisal/).

I think SISAL is *the* premiere example of why scientific computing
is still avoiding modern languages and favors FORTRAN instead:

| While trying to retrieve the URL: 
| http://redhook.llnl.gov/iscr/projects/crg/sisal.tutorial/
|
| The following error was encountered:
| Unable to determine IP address from host name for redhook.llnl.gov 

| While trying to retrieve the URL: 
| ftp://sisal.llnl.gov/pub/sisal/Small.Sisal.Interpreter.dir
|
| The following error was encountered:
| Unable to determine IP address from host name for sisal.llnl.gov

It was a one shot project with no long term perspective, even the
code is gone and none of the official distribution sites do exist
any more. The lifetime of the language didn't even span the
lifetime of a typical high energy physics experiment.  A physicist who
had bet his professional success on SISAL would be turning burgers
at McDonalds by now.

Yours, Florian Hars.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] SISAL (Was: report describing optimization of numerical computing...)

[Tom _]

SISAL was is experiment in language design.  To
replace something like Fortran, you need a bit
more resources than a project at a government
lab.  The SISAL project didn't have the resources
to create the libraries and tools necessary to
replace Fortran, and that was clear to everybody.
It took more than 20 years to come out with Fortran90,
and even it hasn't replaced Fortran77 a decade later.
Many other excellent projects at government
labs have languished for lack of funding.

The ideas that went into the language should
be judged on their own.

Tom.

PS: I was not associated with the SISAL project
other than as an occaional user of their software.

--- Florian Hars <hars@bik-gmbh.de> wrote:
> On Thu, May 31, 2001 at 09:10:24PM -0700, Tom _
> wrote:
> > I'd recommend also taking a look at SISAL
> > (http://www.llnl.gov/sisal/).
> 
> I think SISAL is *the* premiere example of why
> scientific computing
> is still avoiding modern languages and favors
> FORTRAN instead:
> 
> | While trying to retrieve the URL: 
> |
>
http://redhook.llnl.gov/iscr/projects/crg/sisal.tutorial/
> |
> | The following error was encountered:
> | Unable to determine IP address from host name for
> redhook.llnl.gov 
> 
> | While trying to retrieve the URL: 
> |
>
ftp://sisal.llnl.gov/pub/sisal/Small.Sisal.Interpreter.dir
> |
> | The following error was encountered:
> | Unable to determine IP address from host name for
> sisal.llnl.gov
> 
> It was a one shot project with no long term
> perspective, even the
> code is gone and none of the official distribution
> sites do exist
> any more. The lifetime of the language didn't even
> span the
> lifetime of a typical high energy physics
> experiment.  A physicist who
> had bet his professional success on SISAL would be
> turning burgers
> at McDonalds by now.
> 
> Yours, Florian Hars.
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr. 
> Archives: http://caml.inria.fr

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] report describing optimization of numerical computing of the ocaml compiler.

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 589 bytes --]


This report describes adjustments of the ocaml
compiler to support better optimization of arrays for
numerical computing.

http://www.cs.cornell.edu/Courses/cs612/2001SP/projects/ocaml-arrays/OCaml.pdf

Is this something that is considered to be included in
future versions of ocaml?

Best Regards,
Peter Rönnquist


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocamlopt and Windows DLL

[Dmitry Bely]

Dmitry Bely <dbely@mail.ru> writes:

> I am trying to build COM component written in ocaml using ocamlopt
> compiler. To achive that I have slightly modified camlidldll script from
> camlidl distribution. Now it builds DLL without a problem, but resulting
> DLL never executes "let _ = ..." (_*_entry) constructs! After a short
> investigation I have found the following code that seems to be causing the
> problem:

[...]

I've found out finally that it was just my fault (missed .cmx when building
caml-obj), so where is no problem with using ocamlopt for creating Windows
DLL. Sorry for wasting your time :-)

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocamlopt and Windows DLL

[Dmitry Bely]

1. Just another problem with ocamlopt and DLL: if unhandled exception occuirs
in my COM method, ocaml code terminanes inside callbackN_exn() with
"Fatal error: uncaught exception" instead of returning the appropriate
result indicating the exception (as byte compiled code does):

[--- cut ---]
HRESULT STDMETHODCALLTYPE camlidl_config_IConfig_load_callback(
	struct IConfig * this,
	/* in */ char *file)
{
  value _varg[2] = { 0, 0, };
  value _vres;
  static value _vlabel = 0;
  HRESULT _res;
  Begin_roots_block(_varg, 2)
    _varg[0] = ((struct camlidl_intf *) this)->caml_object;
    _varg[1] = copy_string(file);
    if (_vlabel == 0) _vlabel = camlidl_lookup_method("load");
  End_roots();
  _vres = callbackN_exn(Lookup(_varg[0], _vlabel), 2, _varg);
          ^^^^ in case of exception dies inside
  if (Is_exception_result(_vres))
    return camlidl_result_exception("config.IConfig::load", Extract_exception(_vres));
  _res = S_OK;
  return _res;
}
[--- cut ---]

Is this the expected behavior or just a bug?

2. (camlidl related question) I cannot create method returning the string
value. I've tried 

[--- cut ---]
[
	object,
	pointer_default(ref)
]
interface ITest: IUnknown
{
    HRESULT getString( [out] int* len, [out,length_is(*len)] char* val  );
}
[--- cut ---]

but camlidl says

[--- cut ---]
test.idl
test.idl, function ITest::getString: Out parameter `val' must be a pointer
[--- cut ---]

Looks like just another camlidl bug. I even tried 
HRESULT getString( [out,length_is(32)] char* val  );
-- exactly the same result.

BTW, whom should I inform about camlidl problems/bugs? Is there any
bug-tracking database or so?

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocamlopt and Windows DLL

[Xavier Leroy]

> BTW, whom should I inform about camlidl problems/bugs? Is there any
> bug-tracking database or so?

Please do NOT send bug reports to caml-list.  You're just annoying 500
subscribers.  For CamlIDL as for any Caml-related stuff that we do
here at INRIA, use the Caml bug-tracking system at
        http://caml.inria.fr/bin/caml-bugs
or e-mail to caml-bugs@inria.fr.

Thanks,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr