[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Symbolics/Intellicorp Announcement Symbolics/Intellicorp Announcement



    Date: Thu, 16 Mar 89 12:36:01 EST
    From: MILLER@vax.cam.nbs.gov

	    Date: Tue, 14 Mar 89 18:23 EST
	    From: barmar@Think.COM (Barry Margolin)

	    Does KEE do anything hardware specific that makes it less than trivial
	    to port it to Ivory?  ...                                   what's the
	    significance of the XL400 side of the agreement?
    
	KEE is a large complex product.  It would be silly for a company like
	Intellicorp to simply compile KEE for the MacIvory or XL400, and then ship
	it to customers without doing any performance tuning or software QA.  For a
	product like KEE, the job of porting it to a new platform like the XL400 is
	has a large component of testing and QA.
    
	See below.
    
	    ----------------
	    Date: Tue, 14 Mar 89 17:38 EST
	    From: MILLER@vax.cam.nbs.gov (Bruce)
    
	    I hate to be a killjoy but I keep hearing `You only have to recompile.'
    
	You do only have to recompile to get a working version on the XL400 or
	MacIvory.  However, it is naive to presume that the performance of any
	complex software product is going to be the same on an Ivory-based machine
	as it is on a 36xx, and naive to presume that an embedded system is going
	to have the same performance as an unembedded system.
    
	Some things on an Ivory-based platform will run faster than on the 3600,
	some things might run slower; code which has been carefully optimized for
	the 3600 might prove to be slower than one wants on the Ivory.  After all,
	the architectures are quite different.
    
    Excellent reply, Scott.  However, my point was that in the past the
    tone has been something like `You only have to recompile.  Oh... you *might*
    want to tune a bit.'  I have always assumed that, in the end, I would be doing more
    than just a bit of tuning.  But the implication of the annoucement ---
    that this tuning is of a magnitude that warrants a joint development agreement ---
    and certainly the tone of the reply seems to be `... If you are at all concerned
    with performance you almost  certainly will want to tune a lot.'  
    From the technical point of view, this doesn't surprise me (or even bother me) 
    all that much; but from the business point of view it seems to be a slight 
    change of tune. No?

[Disclaimer: I am speaking as an individual here, *not* as a deputized
spokesman for Symbolics.]

I am not qualified to answer the "change of tune" question.  But it's
true; you "*might* want to tune a bit".  It depends on the application.
>From the business point of view, the significant thing about this
agreement is that Symbolics and Intellicorp have agreed to work together
to do what is necessary to produce a high-quality product (KEE) for the
Ivory-based machines.  It is not a statement of how much technical work
is involved, just a statement of cooperation.

It is not far-fetched to speculate that porting a large system like KEE
will turn up performance problems in the XL400/MacIvory which Symbolics
will fix in its own software, benefitting all customer applications.

    This leads me to the following tangent; I know that defsystem, et.al., is
    supposed to help keep track of BIN & IBIN files.  Now I wonder: Will it help
    us much in keeping track of separately tuned sources?   

I don't understand.  The per-machine tuning will probably be inside
#+3600 or #+IMach clauses, no?  Right now, SCT is not too hot at
maintaining completely different sets of source files which are meant to
represent the same system on different platforms, but you can at least
use #+3600/#+IMach in the 1defsystem0 form as a stopgap, as we do.  This
is more the job of a real source (version) control system.

    I should point out that much our work involves a number of relatively small
    (1-2 dozen files) systems used for research that are generally developed by
    one person and used on only a handfull of sites/machines.   Performance usually
    is an issue.  I couldn't live without defsystem, but a lot of its power is a
    bit heavy; obviously designed for really large systems with many developers.