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 TAA10479; Wed, 6 Feb 2002 19:01:53 +0100 (MET) 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 TAA10185 for ; Wed, 6 Feb 2002 19:01:52 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g16I1pn14496; Wed, 6 Feb 2002 19:01:51 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA10208; Wed, 6 Feb 2002 19:01:51 +0100 (MET) Date: Wed, 6 Feb 2002 19:01:51 +0100 From: Xavier Leroy To: Berke Durak Cc: caml-list@inria.fr Subject: Re: [Caml-list] Suggestion for Int32.rotate Message-ID: <20020206190151.A9371@pauillac.inria.fr> References: <20020205000643.A31440@gogol.zorgol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020205000643.A31440@gogol.zorgol>; from berke@altern.org on Tue, Feb 05, 2002 at 12:06:43AM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 2) A syntax extension (or extension to the standard syntax) for > entering Int32 and Int64 constants. This has been on my to do list for a while. The main issue is finding a decent syntax... (All discussions on this list seem to converge on syntax these days, that's awful :-) We have three "big integer" types: int32, nativeint and int64. A C-style syntax would be 12345L for int32 and 123456789LL for int64; what about nativeint? 12345N ? Anything nicer? > 3) A hack into Printf to remove the need to use Int32.format Printf support was added in 3.04: "%ld", "%nd", "%Ld" for int32, nativeint and int64 respectively. > I.e. better support for int32's. I understand that the Caml team does > not want people to use int32's (or int64's) by default. It's not that we object to this, just that these types are boxed and this impacts performance to some extent, so you're advised to use them only when you need them (as you obviously do). > However a lot > of coding/crypto stuff, deserving to be ported to Caml, works with > 32-bit ints and it would be good to be able to use them at full speed. > For example, the MD5 routine used in Digest.string could be efficiently > rewritten in Caml. I played with a Caml reimplementation of MD5 a while ago, and even with various source-level tweaks, ocamlopt isn't clever enough to eliminate all boxing and unboxing. The result is about 2-3 times slower than hand-optimized C. More generally speaking, I don't think basic ciphers and hash functions really benefit from being rewritten in Caml. C is extremely painful as a general-purpose language, but OK for some things: bytecode interpreters, memory managers, device drivers, crypto primitives, ... MD5 written in Caml isn't noticeably nicer / safer / less buggy than MD5 in C. So, why not just interface with existing C implementations -- with the additional benefits that someone else already debugged and performance-tweaked them? Don't get me wrong: as soon as we move up from the crypto basic blocks into real cryptographic protocols and applications, the benefits of Caml (or other high-level languages) become obvious. (I shudder at the idea of implementing a public-key infrastructure in C.) It's just that basic blocks like MD5 or DES are, well, just basic blocks -- just like integer addition; who cares how they are implemented as long as they work? - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr