
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>Copying around 64 bytes per stat call is never going to be the bottleneck.<BR>I am not 100% sure, but I believe every stat call is a<BR>kernel call. Data already has to be copied between<BR>kernel and user mode, and some i/o, possibly cached,<BR>has to occur.<BR>Maybe if someone stats a bunch of files, and then<BR>stats them many times afterward.<BR>

<BR>I'm all for thin (zero thickness) wrappers, keeping things fast, but header cloning really bugs me.<BR>

<BR>If you really want to stat a lot of files, at some<BR>point you'll win by using something like opendir/readdir<BR>to just get all the data -- given some readdir that<BR>returns the needed stat information.<BR>On Windows this is simply FindFirstFile/FindNextFile.<BR>

(and yes I realize I'm partly rearranging deck chairs -- the readdir has to return<BR>

some struct with the same issues as stat, however maybe there'd be knowledge<BR>

of it operating on larger data and less tendency to slow it down)<BR>

<BR>> generic posix directory to speed ports<BR>

<BR>Sounds like a good compromise.<BR>And existing ports could even try it and measure the difference maybe.<BR>

<BR>> swig vs. my compiler-based idea vs. generating some other<BR>> way only what is needed<BR>

<BR>Good point. I did some stuff for Cygwin along these lines<BR>that may be close to just right.<BR>

<BR>Fairly simple C code that prints out the Modula-3.<BR>Again, what you could do, is in the build, optionally<BR>recompile/rerun the C and assert the output is unchanged.<BR>

<BR>This is super easy for constants and chosing the right<BR>integer type for record fields.<BR>It is easy enough for getting the record fields in the right<BR>order, and asserting that you didn't miss any (no holes), though<BR>I didn't do that (yet).<BR>

<BR>Perhaps I should try that?<BR>Come up with reasonably simple very very portable C (probably<BR>c++, with specific reasons) code that prints out..well..<BR>some set of .i3 files that bother me.<BR>I guess it is fairly scientific, which .i3 files describe<BR>C and which Modula-3.<BR>It is presence of <* external *>, the types they take and return.<BR>Constants, harder to identify mechanically.<BR>

<BR>I also made a large stab to determine exactly what is needed<BR>and no or very little more. The Cygwin stuff should be a good<BR>basis for determing this, except it doesn't use pthreads.<BR>

 <BR>

Another problem here not yet addressed is picking out function<BR>signatures. I think some simple uses of C++ templates might<BR>work here, but I have to experiment.<BR>

 <BR>

There would still be much duplicity, but I guess generated<BR>(and still checked in, and often regenerated), is better than<BR>hand written once and then not checked through time.<BR>Granted, if you get Ustat.i3 wrong, you do tend to find and<BR>fix the bugs fairly fast, but I'd like "static" checking<BR>to get this stuff right.<BR>

<BR>I'm not going to do much of anything here for now,<BR>but maybe I'll get around to it. It depends what bugs me most. :)<BR>

<BR> - Jay<BR><BR><BR><BR><BR><BR>


<HR id=stopSpelling>

<BR>

> Date: Fri, 25 Apr 2008 08:19:05 +0200<BR>> From: wagner@elegosoft.com<BR>> To: jayk123@hotmail.com<BR>> CC: hosking@cs.purdue.edu; m3devel@elegosoft.com<BR>> Subject: RE: [M3devel] naming conventions for split/composed interfaces?<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > What cost are you willing to pay?<BR>> > It is EASY to write one simple Ustat.i3 and UstatC.c that is correct <BR>> > for all platforms, totally portable, simple, efficient enough etc. <BR>> > The cost of avoiding the wrapper is pain, uncertainty, much higher <BR>> > risk of the implementation being wrong or becoming silently wrong, <BR>> > though...<BR>> <BR>> In case of stat, copying the structure may lead to performance bottle-<BR>> necks in I/O intensive programs (like build systmes etc.). Build<BR>> systems for example may start by stat-ing ten thousands of files in<BR>> their first phase.<BR>> <BR>> I'd not object to adding something like a generic posix subdir,<BR>> which could be used for fast porting, but I wouldn't want this<BR>> to be used for current plaforms if it has performance impacts.<BR>> <BR>> > Well, how about this suggestion?<BR>> > How about we start writing some C code that asserts the correctness <BR>> > of the .i3 files?Or even having the compiler output such C code? <BR>> > Just make sure it compiles?<BR>> <BR>> This sounds more than what I'd like to do. I think we need to<BR>> analyze what exactly M3 really needs from the underlying target<BR>> platform, and automate a way of generating the correct interfaces for<BR>> that. Something configure-like that will only be used for porting<BR>> (or checking the correctness of existing interfaces).<BR>> <BR>> > Ustat.i3 would get some directive LIKE:<BR>> ><BR>> > <* PRAGMA C-derived "#include sys/stat.h", "struct stat" *><BR>> > struct_stat = RECORD ... END<BR>> ><BR>> > The second parameter is the type that the record should "match".<BR>> ><BR>> > This would generate and a compile a file something like:<BR>> > #include <sys/stat.h><BR>> > #define size(a,b,c) (sizeof((a)(a*)0)->b == c)<BR>> > #define field(a,b) ((a*)0)->b)<BR>> > #define offset(a,b) ((size_t)a)<BR>> ><BR>> > type_size_size(struct stat, 0x123)<BR>> > size(struct stat, st_dev, 8)<BR>> > size(field(struct stat, st_dev), 8)<BR>> > size(field(struct stat, st_ino), 8)<BR>> > offset(field(struct stat, st_dev), 0)<BR>> > offset(field(struct stat, st_ino), 8)<BR>> > etc.<BR>> ><BR>> > where all the numbers on the right are what the compiler computes.<BR>> ><BR>> > This way, the transcription of C into Modula-3 is checked for correctness.<BR>> ><BR>> > It can be optional -- like for cross builds that might have a C <BR>> > compiler or headers/libs.<BR>> > I have to admit, there is an aspect of avoiding C that I really like <BR>> > -- the idea of building one tool for all targets, all in one, no <BR>> > need to get a cross compiler or headers/libs. To me that is a <BR>> > potential big upside to avoiding wrappers.<BR>> > I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.<BR>> > dtoa.c was very very gnarly last I looked. Could be they dropped <BR>> > support for IBM/Cray/VAX and it's simpler now, I don't know. While I <BR>> > like the idea, I would be reluctant because I don't understand the <BR>> > code much.<BR>> > hand.c though, I strongly suspect can be written in perfectly <BR>> > portable efficient Modula-3.<BR>> <BR>> There have been some discussions in the past about updating or<BR>> replacing dtoa.h in M3. Have a look at the mailing list archives<BR>> before spending too much time on it.<BR>> <BR>> > It may or MIGHT not compiler down as efficiently, just if the <BR>> > compiler doesn't do a good job, but I don't think, like, "there any <BR>> > layers in the model" that prevent it, like you wouldn't have to do <BR>> > extra heap allocs or copies. You might get some extra array bounds <BR>> > checks, that would be good to avoid introducing.<BR>> ><BR>> > Well, I'm too busy right now, but:<BR>> ><BR>> > 1) I'll maybe the errno wrapper in NT386. As long as you avoid the <BR>> > thread-unsafe library, this area has been stable forever.<BR>> > And building in a dependency on thread safety is a good thing.<BR>> ><BR>> > 2) I'll see about rewriting hand.c in Modula-3 and see if I can <BR>> > convince myself there's no perf loss.<BR>> ><BR>> > 3) I look at gtoa.c to confirm it is still way to gnarly to consider <BR>> > changing.<BR>> ><BR>> > 4) Eventually see about building in this checking. It removes the <BR>> > upside of not having a compiler/headers, that's why optional.<BR>> ><BR>> > 5) Wonder about automating generation of the Modula-3 in the first <BR>> > place? Something like SWIG? I don't know.<BR>> > Problem with #4 and #5 is special cases. Coming up with some <BR>> > mechanized translation that actually exists and works.<BR>> <BR>> SWIG has already been tried at least twice for M3, and found to be<BR>> somewhat unhandy and insufficient. It does not really speed up the<BR>> process of getting correct M3 interfaces for C headers IIRC.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>

</html>