Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.eiffel Subject: Re: Mosaic Benchmark on other platforms Message-ID: <54007@microsoft.UUCP> Date: 9 Apr 90 19:17:01 GMT References: <2110@kiwi.mpr.ca> <276@eiffel.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 27 In article kim@helios.enea.se (Kim Wald`n) writes: > >The only reason to turn off all assertion checking when running benchmarks >against C++ should be to get more comparable figures. > >As we all know, there is no such thing as a thoroughly tested software >system, and the resulting safety is well worth the extra cpy cycles. I believe there is a contradiction in these two statements. Timing comparisons should be representative of final executable code as delivered to customers. If Eiffel code is to be delivered with assertions in the code, and C++ code is not [typically] delivered with assertions in the code, then the relative timings between the languages should reflect this fact. If the cost in Eiffel of the assertions is worthwhile, then you should be able to successfully argue for these costs, even if they make Eiffel code bigger and slower. Speed and size is only two [but important] measures of a language. Typically one pays for the features of a language. Timings and code sizes let a user decide if he/she considers the costs of the features represent a good value for that user. Alternately, show size and timings for code both with and without assertion checking. Then users can decide if they agree with your assessment that runtime checking is worth the cost. Don't "cook" comparisons to make them unrepresentative of how people actually use languages. Comparisons should be representative.