From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: Guile OpenGL bindings Date: Fri, 01 Feb 2013 10:10:10 -0500 Message-ID: <87obg4dq99.fsf@tines.lan> References: <871ud0p6u0.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1359731436 3176 80.91.229.3 (1 Feb 2013 15:10:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Feb 2013 15:10:36 +0000 (UTC) Cc: guile-user To: Daniel Hartwig Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Feb 01 16:10:56 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U1IGW-0002XN-9F for guile-user@m.gmane.org; Fri, 01 Feb 2013 16:10:56 +0100 Original-Received: from localhost ([::1]:45932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1IGE-00022j-1A for guile-user@m.gmane.org; Fri, 01 Feb 2013 10:10:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1IG7-000223-Ne for guile-user@gnu.org; Fri, 01 Feb 2013 10:10:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1IG2-0004OB-Hv for guile-user@gnu.org; Fri, 01 Feb 2013 10:10:31 -0500 Original-Received: from world.peace.net ([96.39.62.75]:60368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1IG2-0004No-DK for guile-user@gnu.org; Fri, 01 Feb 2013 10:10:26 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U1IFv-0006d7-1y; Fri, 01 Feb 2013 10:10:19 -0500 In-Reply-To: (Daniel Hartwig's message of "Fri, 1 Feb 2013 21:29:36 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9975 Archived-At: Javier Sancho writes: > Someone mentioned performance issues when using FFI, too. That was me, and I regret emphasizing that. In a couple of years, when Guile has native compilation, it is likely that the FFI will be as fast as C wrappers, maybe even a bit faster. Anyway, as Knuth wrote, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil", and he was absolutely right. Countless projects have been ruined by premature optimization. It's far more important to write the cleanest, simplest code that will get the job done. Only after determining the hotspots (by profiling) should you optimize those bits. Plus, as Daniel Hartwig wrote: > For modern GL programming without glBegin/End, Vertex/Color/Normal, > etc. the performance impact of FFI should be negligable. There are > few GL calls compared to the volume of data that is passed. > > The real critical part will be how the user manipulates their vertex > data, if this is done frequently on the scheme side. Mapping (typed) > bytevectors, or srfi-4 to gl arrays will help with that, and avoiding > the implicit type conversions that some other bindings perform. Regards, Mark