> -----Original Message----- > From: Kurt at DBC [mailto:[EMAIL PROTECTED] > Sent: 13 October 2003 4:50 pm > To: Multiple recipients of list delphi > Subject: Re: [DUG]: [DUG-OFF-TOPIC]: octane > > > Steven Knight wrote: > > > Assuming everyone has done there jobs correctly then: > > > > - Well written machine specific machine code will be fastest. > > Good compilers often come close to this. > > Well, for various values of 'well written'. I'd be picking a > compiler has far more ability to optimise than I do, given > honking great > L1 & L2 caches, pre-fetch queues and them frickin 20 instruction > pipelines. In fact I'd even guess that it would only be possible to > optimise one path through an application : a compiler would thrash you > as soon as the cpu started predicting which of the branches > you'd take.
Yes we agree. It would be a good use of resources if this happened at programme creation time. Rathur than every time it is executed. I said "machine specific machine code" ie. the sort of stuff that comes from a compiler. I was not advocating writing in binary. > > > > > - Interpreters have a constant overhead and, for most work, > are a lot > > slower. > > For the right task ie when you'd use one, an interpreter would be > an order of magnitude faster. On a 1 Gig box, if you save 1,000,000 > instructions, you've saved yourself a second. If your interpreter > cuts down on the time taken by an hour it saved 3600 seconds. > > Which by no means implies that Perl is fun or even pleasant, but > still... > You make a good point. There are a number of interpreted environments that make development easier. VB is one. (Don't know if VB .NET qualifies as interpreted in development environment.) (I am not advocating VB by the way) But I believe the development time benifit comes from the language not how it is executed. > > > > - virtual machines are essentialy well optimised interpreters. > > A vm is a compile target, it doesn't matter when compilation occurs. Yes once again. You get a highly optimised intermediate code which is not processor specific (possibly lowest common denominator). This is then interpreted each time it is run. Hopefully the intermediate was designed with more than one processor in mind so it can be reasonably efficient on current and future machines. Think we have been here once before with RISC. > > > M$ methodology ;-) (note: this is my speculation) > > M$ operates at a level no different from any other (product-based) > business, identifying markets they can make a profit in and targetting > them. None of what you speculate relates specifically to their > anti-competitive or monopolistic behaviour. They are also probably one > of the *least* buzzword abusing company in software (unless you'd > consider Spreadsheet, Word Processor and E-mail to be buzzwords). Yes. Just like any snake oil salesmen. > Their problem is in using new words in a context which they have no > commonly understood definition. > Yes. Whole hartedly agree. > Cheers, Kurt. :-) Steven > > -------------------------------------------------------------- > ------------- > New Zealand Delphi Users group - Delphi List - > [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > Visit us online at http://www.ecan.govt.nz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. The contents of this email and any attachments are not formal policy of Environment Canterbury, unless otherwise stated. ********************************************************************** --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
