On Dec 22, 12:57 am, "William Stein" <[EMAIL PROTECTED]> wrote: > > Well, that is how you see Sage, but having a local development > > environment is something I would see happening sooner or later. Sage > > should work in a way the users wants it to and for many people that > > means a local install. I never use the notebook since I don't like to > > use web applications for any serious work. Many people disagree with > > me on that one, but I don't care ;) > > I'm certainly not saying a web interface is the only one for sage; just > that it is a very important one. I use the notebook and command line > about equally, personally.
Sure, many people are perfectly happy with it and there is more than one way to skin a cat [that idiom is slightly disturbing, and it really says "cat" - for more info see http://www.worldwidewords.org/qa/qa-mor1.htm ] > > Sure, it works today, but I think virtualization on PCs is still an in- > > mature technology. > > It's been heavily developed for over 10 years. I don't think it is any > more immature than a lot of other technologies out there. Most things > in computing are immature. Well, but IBM got it right for their mainframes. Everybody else is still catching up 20 years later. > > It has a pretty big performance impact (a non-issue > > for the casual user), but certainly an issue for people like John when > > he is using the Lab on the weekend and nights to do computations. > > Disk performance is slow, but that's not an issue for John's calculation. > For CPU bound work, the performance impact is not that large, at least > with modern > intel processors. In fact, often performance is *better* in vmware > than native, > since Linux is a better OS performance wise than Linux and OSX. > > Here's a typical example of what happens in practice: > > On OS X Xeon 2.6Ghz native: > sage: time n=factorial(10^6) > CPU times: user 1.87 s, sys: 0.11 s, total: 1.99 s > Wall time: 2.01 > > In a VMware image running on the same machine (64-bit debian): > time n=factorisage: time n=factorial(10^6) > CPU times: user 1.01 s, sys: 0.10 s, total: 1.10 s > Wall time: 1.12 > > Using 32-bit Debian in VMware on the same machine: > sage: time n=factorial(10^6) > CPU times: user 1.83 s, sys: 0.18 s, total: 2.01 s > Wall time: 2.04 The benchmarks above are a single CPU bound process on an unloaded box, so not interesting in my book. Some of the issues I refer to are "TLB trashing" and the fact that the memory used by a VMWare machine cannot be altered dynamically and is gone from the system. But this isn't the list to discuss the finer point of nested TLBs and such. Until earlier this year I used a VMWare image on quite a beefy box to do Windows development of some code using Qt and let me just say that it *sucked*. And it didn't matter whether I used Linux or Windows as a host. And the test of time is running a VMWare session over time with a bunch of users, even Windows 95 was good enough for a single user as long as you rebooted every couple hours. This isn't a fair comparison, but I have had my fair share of experience with VMWare and I would be certain that you wouldn't doubt my admin skills in that regard. I spend endless hours trying to figure out what is wrong before giving up. It just wasn't worth the effort. > The reason that the second is so fast is that the above benchmark > takes advantage of GMP being > built 64-bit in that case. There is a 1% performance penalty above > with both running 64-bit. > I see this sort of thing all the time -- frequently for CPU-bound > computations, running > Linux in a virtual machine, even 32-bit, is as good or even _better_ > than running the > same computation natively under OSX, and presumably under Windows. The > reasons > probably involve developers optimizing every level of the toolchain > more for Linux > than Windows or OSX. A good example of this sort of thing is MAgma, > which is often > literally hundreds of thousands of times slower running natively on > OSX as on Linux... Well, then their port on OSX must suck. I would help them out, but since I don't have the source I cannot really help. They can always hire me, my rates are reasonable and I am usually less offensive to people who pay me. I always wanted to visit Australia. *ducks* > Anyway, people using Windows as their main computing platform > are probably not worrying about small performance penalties. Windows is not as slow as you make it out to be. It has the whole thread vs. process expense issue, but Windows isn't magically slower on a grand scale than Linux. > > But a lot of people do not have the expertise to get the VMware image to > > run, while they certainly can click on some installer and run it. > > Anybody who can point and click can install the vmware image. It is not > that hard. You install vmware -- which is trivial standard point and click. > You extract a zip file. Then you double click on the blue sage icon. That's > it. > And you get something that won't mess up your computer, that can be > paused at any time, copied/moved to another computer, etc. I see those as advantages, too. > > I see the VMWare image as another delivery vehicle for Sage on Windows, > > but I don't think it satisfies the needs of 99% of potential Sage on > > Windows users out there. > > I definitely don't think the current version does either. But I think the > main reason has more to do with Sage itself not satisfying the needs of 99% > of potential users. Sure, but that issue is orthogonal, too. We are getting there solving those problems, though. > <SNIP> > > I don't know. It probably depends on how good the VMware image is. > In any case, Maxima is certainly not a model of success to aspire to, > at least given what we're trying to accomplish. > I am glad you wrote that and not me. I certainly don't disagree on that point :) > > > > Since Sage is almost completely a volunteer project, I hope developers > > > will > > > do what excites them most. Just do it very very well. Oh, and make > > > sure your > > > code is readable since odds are you might be way too busy to work on Sage > > > in a few months! > > > Well, since I have nothing better to do I will certainly spend the > > next two weeks on making a first step in the direction of the native > > Windows port and might even revive the Cygwin build. So far no linker > > has successfully stood in my way forever, and I will break its > > resistance to linking a dynamic libSingular! > > Ah, now my secret plan is exposed! By arguing with you I'll inspire > you to do what I really secretly want you to do. :-) Haha, reverse psychology no longer works on me. Or does it? :) > William Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
