* Re: [Caml-list] Obsessed by speed
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
@ 2001-05-21 16:44 ` Chris Hecker
2001-05-21 19:12 ` William Chesters
` (4 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Chris Hecker @ 2001-05-21 16:44 UTC (permalink / raw)
To: Mattias Waldau, caml-list
>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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Caml-list] Obsessed by speed
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
2001-05-21 16:44 ` Chris Hecker
@ 2001-05-21 19:12 ` William Chesters
2001-05-27 8:47 ` Xavier Leroy
` (3 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: William Chesters @ 2001-05-21 19:12 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] Obsessed by speed
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
2001-05-21 16:44 ` Chris Hecker
2001-05-21 19:12 ` William Chesters
@ 2001-05-27 8:47 ` Xavier Leroy
2001-05-31 15:13 ` [Caml-list] report describing optimization of numerical computing of the ocaml compiler Peter Ronnquist
` (2 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Xavier Leroy @ 2001-05-27 8:47 UTC (permalink / raw)
To: Mattias Waldau; +Cc: caml-list
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
` (2 preceding siblings ...)
2001-05-27 8:47 ` Xavier Leroy
@ 2001-05-31 15:13 ` Peter Ronnquist
2001-05-31 15:15 ` Peter Ronnquist
2001-05-31 15:15 ` [Caml-list] report describing optimization of numerical computing of the ocaml compiler Peter Ronnquist
5 siblings, 0 replies; 17+ messages in thread
From: Peter Ronnquist @ 2001-05-31 15:13 UTC (permalink / raw)
To: caml-list
[-- 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
` (3 preceding siblings ...)
2001-05-31 15:13 ` [Caml-list] report describing optimization of numerical computing of the ocaml compiler Peter Ronnquist
@ 2001-05-31 15:15 ` Peter Ronnquist
2001-05-31 16:12 ` Brian Rogoff
2001-05-31 15:15 ` [Caml-list] report describing optimization of numerical computing of the ocaml compiler Peter Ronnquist
5 siblings, 1 reply; 17+ messages in thread
From: Peter Ronnquist @ 2001-05-31 15:15 UTC (permalink / raw)
To: caml-list
[-- 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-05-31 15:15 ` Peter Ronnquist
@ 2001-05-31 16:12 ` Brian Rogoff
2001-06-01 2:30 ` [Caml-list] report describing optimization of numerical computingof " John Max Skaller
2001-06-01 4:10 ` [Caml-list] report describing optimization of numerical computing of " Tom _
0 siblings, 2 replies; 17+ messages in thread
From: Brian Rogoff @ 2001-05-31 16:12 UTC (permalink / raw)
To: Peter Ronnquist; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] report describing optimization of numerical computingof the ocaml compiler.
2001-05-31 16:12 ` Brian Rogoff
@ 2001-06-01 2:30 ` John Max Skaller
2001-06-01 4:10 ` [Caml-list] report describing optimization of numerical computing of " Tom _
1 sibling, 0 replies; 17+ messages in thread
From: John Max Skaller @ 2001-06-01 2:30 UTC (permalink / raw)
To: Brian Rogoff; +Cc: Peter Ronnquist, caml-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-05-31 16:12 ` Brian Rogoff
2001-06-01 2:30 ` [Caml-list] report describing optimization of numerical computingof " John Max Skaller
@ 2001-06-01 4:10 ` Tom _
2001-06-01 4:20 ` Niall Dalton
2001-06-01 6:33 ` [Caml-list] SISAL (Was: report describing optimization of numerical computing...) Florian Hars
1 sibling, 2 replies; 17+ messages in thread
From: Tom _ @ 2001-06-01 4:10 UTC (permalink / raw)
To: Brian Rogoff, Peter Ronnquist; +Cc: caml-list
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-06-01 4:10 ` [Caml-list] report describing optimization of numerical computing of " Tom _
@ 2001-06-01 4:20 ` Niall Dalton
2001-06-01 6:33 ` [Caml-list] SISAL (Was: report describing optimization of numerical computing...) Florian Hars
1 sibling, 0 replies; 17+ messages in thread
From: Niall Dalton @ 2001-06-01 4:20 UTC (permalink / raw)
To: Tom _; +Cc: Brian Rogoff, Peter Ronnquist, caml-list
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Caml-list] SISAL (Was: report describing optimization of numerical computing...)
2001-06-01 4:10 ` [Caml-list] report describing optimization of numerical computing of " Tom _
2001-06-01 4:20 ` Niall Dalton
@ 2001-06-01 6:33 ` Florian Hars
2001-06-01 22:22 ` Tom _
1 sibling, 1 reply; 17+ messages in thread
From: Florian Hars @ 2001-06-01 6:33 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Caml-list] SISAL (Was: report describing optimization of numerical computing...)
2001-06-01 6:33 ` [Caml-list] SISAL (Was: report describing optimization of numerical computing...) Florian Hars
@ 2001-06-01 22:22 ` Tom _
0 siblings, 0 replies; 17+ messages in thread
From: Tom _ @ 2001-06-01 22:22 UTC (permalink / raw)
To: Florian Hars, caml-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Caml-list] report describing optimization of numerical computing of the ocaml compiler.
2001-05-18 19:51 ` [Caml-list] Obsessed by speed Mattias Waldau
` (4 preceding siblings ...)
2001-05-31 15:15 ` Peter Ronnquist
@ 2001-05-31 15:15 ` Peter Ronnquist
5 siblings, 0 replies; 17+ messages in thread
From: Peter Ronnquist @ 2001-05-31 15:15 UTC (permalink / raw)
To: caml-list
[-- 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
^ permalink raw reply [flat|nested] 17+ messages in thread