From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA08834; Wed, 31 Jul 2002 04:30:00 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA08856 for ; Wed, 31 Jul 2002 04:29:59 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from execpc.com (d172.as10.nwbl0.wi.voyager.net [169.207.133.46]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6V2Ttj27788 for ; Wed, 31 Jul 2002 04:29:55 +0200 (MET DST) Received: (from travis@localhost) by execpc.com (8.9.3/8.9.3) id VAA00818; Tue, 30 Jul 2002 21:29:41 -0400 Date: Tue, 30 Jul 2002 21:29:41 -0400 From: Travis Bemann To: "Gurr, David (MED, self)" Cc: caml-list@inria.fr Subject: Re: ocaml, simd, & fftwgel RE: [Caml-list] Caml productivity. Message-ID: <20020730212941.A765@execpc.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from David.Gurr@med.ge.com on Tue, Jul 30, 2002 at 12:58:02PM -0500 X-Security: Consider encrypting or at least authenticating your email Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2002 at 12:58:02PM -0500, Gurr, David (MED, self) wrote: >=20 >=20 >=20 > > From: Travis Bemann: > > On Mon, Jul 29, 2002 at 10:13:24AM +0200, Nicolas Cannasse wrote: > > > > I agree that the C interface is pretty nice. However, > > > > how do would you use SIMD math instructions on the > > > > x86? Would you always call C-routines just to make use > > > > of SIMD or multimedia-instructions? What is the > > > > overhead for calling a function that is executing a > > > > few assembly instructions? Is it even possible to > > > > create a solid division line between "low-level" and > > > > "high-level" code? > > > > > > Yes it is. > > > Actually if you need to perform alot of SIMD instructions each frame > > > (involving zounds of C calls), you can try to group them in=20 > > one-C-call that > > > will do the job in one time. That's matter of architecture=20 > > and choices... > > > not always obvious :) > >=20 > > Note that most C or C++ compilers won't do this either, with the > > exception of some specialized vector parallelizing compilers (such as > > those used to compile code on vector supercomputers). If you really > > need SIMD instructions, you'd probably need to hand-code it in > > assembly, no matter what language you're using. >=20 > About memory allocation, real time code should not be doing memory > allocation in the real time section. For many things that you need > to do in realtime, the ocaml code does not allocate so allocation > is not issue. If you need allocation control, write a C allocator. > You lose some of the safety of ocaml but it is better than writting > the whole thing in C. And there is the possiblity of GC-free functional > programming as done in MLKit4. This is SML not ocaml. I would imagine > that the technique could be used in ocaml. Note that there is no such thing as a C allocator in OCaml, even though you can have "custom blocks" that have custom C finalization code (and which are also not looked inside by OCaml itself). In OCaml there's three classes of allocated data structures - small blocks, large blocks, and custom blocks, all of which are handled differently by the OCaml garbage collector; also note that custom blocks have data on non-heap resources which is used to influence the garbage collector in how often it garbage collects such blocks. Note that overall, the OCaml garbage collector is a incremental generational garbage collector, with only *two* generations - new blocks and old blocks. The garbage collector only tries to aggressively garbage collect new blocks, and does not necessarily try to do all garbage collection at once, which is useful for realtime performance. However, there is one thing that particularly disturbs me about OCaml - the way that it handles floating point values. In OCaml a floating point value is always 64 bit, and because only values that are always the size of a machine word internally are not allocated, floating point values in OCaml are ALWAYS allocated on the heap!! Even though benchmarks of OCaml seem to say that it is pretty damn fast, this particular aspect keeps me up at night. I at least hope OCaml has something like a specialized internal heap for ONLY floating point values that would keep floating point computations from being horridly slow... --=20 Yes, I know my enemies. They're the teachers who tell me to fight me. Compromise, conformity, assimilation, submission, ignorance, hypocrisy, brutality, the elite. All of which are American dreams. - Rage Against The Machine --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.9 (GNU/Linux) Comment: For info see http://www.gnupg.org owF9V8+PHEcVtpMgoYWRCBeuz3uxHfcsk40ThUlsaxg7jsFrA14l8rG6u3q6vNVV 7arqGU/EFQnlgDhwIVKkHHP0nSs3/gNyBSHgyJEL36vqnp5dR9jWeneq3q/vfd+r t7+fvH75tTfXv/z7n/UnL393+S//Dpdu3b/1m6U1QZowPd22ck5Bvgg/brVQ5gMq auG8DLc6PxW+UGpyMNy9q3xrvQrKmjkpo5WR4+GpE8ZX0k3vmcKWyqzm9LyzQZbT 1ikTRK5xeXLw2NBpJzP6WafpnVlGx7PZMYlAbx/P331/Pjv+xQlNZ+/OcHK/cy6j u2KtSrp2cu9uRl7q6jptHLzOJwe3bx3PLnyl2/SRs82ckMxaefqpbIQx83SCyCfW pMjHP9mLPJu//c78+ObihG7MjjnyI1VYLTwtYSy8l2NISn8fkFg5KSnUsA+1pCXg CNJVopCEuK2TIWzJqEIe0cd2I9fSZaN5bTdUWtrYTpe0tR11iPHkwcldakSo4coH 1xUMsydrOMBo++L99+7QpztLoTdi66kQWtNy6mwX0BRPzzqPxCz8nUn2PtrbKkWy jppOB9XIUonpfki457JQxrnAFjXUUpRUwZTjocUkqOpMNEtYwEi+kAVngcPRuJIb YiSbXG/pfLAHnlQgIGQI5PIKPEHmo2nhpAgSkbzVYEKp0FiOx+yjXIaNhOWhtpup hhN9SMKUo/VhrVb1cAJeyjv92XDlqYzxlT8aPlkUoUN5yLOKEBspS8ayRX+tawC5 DTsYz/VKiqKmyolmB9s1ZdZWrxmNz2xnSs+Gywifv55F94UAdm7LEVboX8uoN/C7 Y7Q1crqcxg4zxoPrjcIHYBHT75nNYcE3iTt6RKe4eNUzncBKjilcUasgUZqTO89A Cmq3YKk/OtrVb1BeTyubr5XtPM2vx8Od4SPIITW8sSDaktm0vHEDADet0tJ5cNtc DSk95oRClhDzBv+PrJIvCtlG7iBBbxtJvpWFElp9BsTXSBZuW+FQucRnDOIY4Jrv ALbwyVWorY9Ej53qb8V+s4B6V75DC/msAyj++hHRg9RhMAz9Tp5it19pbWzV1RLC trlgDg+kqIHhNMZhEpke157pGbAcerBhtLQwq06sZPTmOGEUdTSOr0UOAVMjGwtC ICdbCA6fxQxja1NNvo4DgDuVS6DM0CQr9jIaMimYH6O5l7Eg1P4RTwBhttwhs/Kp nQPf2Q2qQ//gga3ZOIu+4LrRKY3SQjyJLjEi3Nu96OxEpQvK+06OgEf09tIs8IY4 q0EQp6LWl8OpdZGXT2GkucWRJqALZ+JFJTFl8VPKKQd2Uco8FhhzlGSiSx5HsSRY bWrLE4aL5uKWyGoBHTBBZT/0hkGkkvf7y2nF034YdUKzL1BhBak3cdJ5YAHxwd/J w5+rcBNOT5n4+Pfk5GGEIObIEPRzXzViFR/Q2+MzAoHWRj3vuM18J+85zdqO5vyC juLb5QyaRTmkqpDNOQTZ/PES5lkcs/+aHEAu3arejZ9arCUdFngzbEM5rM78YYoQ T/qDJVXKsDj75kYKXOMZsqkVaxG5CA0GcLXa2rOYuFe4lW9TAmhPfMMZhj4nTgZV XGXgGeRCs3rinBxYhaEvAuZ/VCPml6cp+YbnYcoVL6sWDqrqf0xzbb+ajH2xyzFT Fq5m16rC0oIFhgdAvo1tSLmuhMtZq9gFdBwgH+zK6/E/FyNhxZlODkBpY80Uz2UL 9XjbOYzYPjjaNcwpZSrdSVPIGPWVeJMDNI53BVthw2JqX7jiU9dT/Avc4OcaRWf/ ryDORSALPLENEGBer6SBXWL5qwb9BLcGE/CtsLFv0Xifu2LkBiAmOLgJljmcsmNB fEuNyVdwCvjwqy9WWKwgPrzX24u32f25Hu/mj5HA1wunoi80Ms0ubvoFHzxtGB2A np1rSIWtkDebYdhNDvr3XuBqxHbY40bZxfc2Si5CjqcqqKIDF5FGqTy4muMNhiri WO/pPk1TSGz7jSn0VPRUaSvi4tRioAdaC5DD70mFt63+CrIb78Q2pgf7vZuUq5DQ yWUheLGMCCdnKeQ/k1LZIKqPPB7cKDg8CFgTUNXGujKttCauQmyxP+jL7NtT8btZ E00WDz9dPH2yJ+S0zRIL48oVonu89aVhBN5ACXUj3FkUf3LiJXYhNNPvwTXu16Vo DFXChyyuGchk1wEMwZYpcyZlG3uAxQrmBttgiEOYX2MJUwisHQRS8zrBL0xqqlZn ce/cW0oGSGIFkS+PHz18eqFzk4N9tNO05zwuNjitIr14KseTRPJpbZ1TJc8jj7U2 bmagzTTuCFhXM2R/ZjAWmi1BfQ2kgxtQ15ZXivSMoI1xC6uxgEmooOGdGvMb1eP7 l0f8a1uDF6xRHjrA88tMx3OX8e6iGqX7vcN3Oa74+L1aGetYDZi39ba1hVMeBrlD DTracmxsaoH1srg4cBeNdIpfmxISa9K4onN/pvQrVupiJXj1ivPiJPHxt3de/85l /q11+DX2zdc+/PDSHy+XV77/jx998eUn3zx+/uvnb3zvWf75Hy599fmNxRvf/Ok/ P/j6zg//+vK/fyv1d+VX/wM= =a0ZJ -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- ------------------- 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