From: "David McClain" <dmcclain1@mindspring.com>
To: "Brandon J. Van Every" <vanevery@indiegamedesign.com>,
"caml" <caml-list@inria.fr>
Subject: Re: [Caml-list] Bigarray is a pig
Date: Fri, 23 Jul 2004 14:45:56 -0700 [thread overview]
Message-ID: <003a01c470fe$72ba90d0$0201a8c0@dylan> (raw)
In-Reply-To: <OOEALCJCKEBJBIJHCNJDIEIOHFAB.vanevery@indiegamedesign.com>
I hesitate to tell you this, but have a look at my Foreign Arrays code and
you will see direct access at all times from OCaml. However, in order to
achieve this you have to commit to some very dangerous practices!
For example, OCaml only knows natively how to access unboxed contiguous
arrays of double precision. So when you need to see a foreign array directly
from OCaml it must first be converted to this format. That's okay, not
dangerous, just a potentially massive overhead on the first reference.
Secondly, the dangerous part comes in accessing the so-called Arena of the
array to direct and unsafe access from OCaml. No bounds checking here. No
function calls to each element either. The array can't move on you during GC
because it is foreign. (recent updates in my possession now conform to the
more modern Custom_tag blocks, up from the older Finalization blocks. So
these are now directly compare'able, hashable, and streamable, in addition
to being finalizable.)
With honorable respect to Xavier and the INRIA team, I did this purely for
myself, while breaking a ton of other OCaml cherished ideals as well. It
works well for me in my numerical modeling language, but the language is
explicitly unsafe. It never bombs out, mind you, but it does accept and
compile statements of utter nonsense that produce runtime errors on the
console, asking you to repeat what you said, but in a different manner...
As one respondent put it, a call is quick, and a cache miss is horrible by
comparison. You will actually generate quite a few cache misses if your
array has any significant size to it.
Cheers,
David McClain
Senior Corporate Scientist
Avisere, Inc.
+1.520.390.7738 (USA)
david.mcclain@avisere.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2004-07-23 21:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 20:36 Brandon J. Van Every
2004-07-23 21:05 ` Brian Hurt
2004-07-24 9:49 ` Brandon J. Van Every
2004-07-23 21:05 ` Olivier Andrieu
2004-07-24 9:07 ` Brandon J. Van Every
2004-07-24 9:59 ` Marcin 'Qrczak' Kowalczyk
2004-07-25 9:09 ` David McClain
2004-07-24 10:39 ` Markus Mottl
2004-07-23 21:45 ` David McClain [this message]
2004-07-23 22:01 ` David McClain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003a01c470fe$72ba90d0$0201a8c0@dylan' \
--to=dmcclain1@mindspring.com \
--cc=caml-list@inria.fr \
--cc=vanevery@indiegamedesign.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox