From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: operation can be dispatching in only one type Date: Tue, 1 Dec 2015 09:46:00 +0100 Organization: cbb software GmbH Message-ID: <6y03ogx0fsk8$.n0ldd6cud931$.dlg@40tude.net> References: <04eb6626-644b-4b16-a329-c35659a9fbe2@googlegroups.com> <1ephv5ugr5mib$.9ehadf3dddct$.dlg@40tude.net> <1nf8wc05tjtvf$.1ctjb9hsr0qsp.dlg@40tude.net> <8132c558-aec2-41f4-8024-4a75a2d497ae@googlegroups.com> <17c8a7kqoxvff.aa1raqev6xlu$.dlg@40tude.net> <75a4c7be-391d-4e5d-9e6e-23607132c943@googlegroups.com> <343b78d1-c1ba-40d3-af80-e18de45f2e3d@googlegroups.com> <11das66l3vhic$.1stkau3dqp6ld.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: bqgfK7NL3xTHnr0WRaLl4g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:28609 Date: 2015-12-01T09:46:00+01:00 List-Id: On Mon, 30 Nov 2015 16:22:12 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:11das66l3vhic$.1stkau3dqp6ld.dlg@40tude.net... > ... >> 2. What makes you think that the compiler always knows better how to >> control raw memory? > > Because it's true?? :-) > > In an ideal world (with an ideal programming language), the compiler always > knows far more than the programmer about the target, In most cases yes. But note you focused on the hardware here. Even with hardware, the compiler knows nothing about the layout of a packet from some I/O protocol. Countless requests here in c.l.a. concerning instructing the compiler to do it right is a proof. But when it becomes the problem space the compiler knows absolutely nothing about handling proxy objects located in the memory. A row of a DB record result set is a record for which the compiler has no slightest idea how to map it (onto the DB environment, connection, cursor). > To the extent that there is information that the compiler doesn't > have, the focus should be on giving it that information, not on telling it > what to do. (For instance, it is better to tell a compiler which subprograms > are "hot" than to tell it that it must inline certain subprograms -- > inlining is just one possibly way of improving the performance and the > compiler is in a better position to juggle the trade-offs than any > programmer could be. That's one of the reasons that just-in-time compilation > produces better performance than one would imagine just based on > traditionally compiling individual subprograms.) Not exactly. It is true when we talk about non-functional requirements and wrong for the functional ones. The example with inlining works because it is non-functional. > In the real world, of course, there are limitations on compilation time, > execution information, and so on, but it still is the case that it is rare > that a programmer can really do better at these things (especially at the > "raw memory" level) than a decent compiler. That's why it's unfortunate that > most programming languages (and Ada is no exception) focus too much on > features that can be implemented easily and less on improving abstraction. There is no contradiction in providing simple building blocks for higher level abstractions. There is no reason why indexing or record member access should be less efficient when a user-defined implementation allowed, but not actually used. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de