Jamie said: > > > > You can logically see the conclusion of the reformulation of the > > sentence: if accessing managed libraries is as easy as accessing regular > > libraries, there wouldn't be any impediment to write core libs in > > managed code, which could dramatically speed up development. > > In theory, yes. In practice thats unknown at present as we dont know the > trade off in terms of speed and efficiency. My main concern with Mono > taking over from C in that respect is what will it cost in terms of > extra memory requirements and what's the performance like. If you > remember the doomed Java OS and have seen the beta of Longhorn then I > hope you understand these concerns about performance/excessive memory > usage of managed code. I dont know how mono performs in these areas > (compared to Java/.NET) so I would like to see benchmarks once its at a > suitable stage. AFAIK, code written in C# and compiled to the Mono runtime should run equally fast as the C equivalent. Note I said run, meaning that I don't count: * load times * JITting times so basically "run time" in this paragraph means "code being run after JIT". Mono and its runtime have been designed from the ground up to JIT instead of P-code interpreting, in contrast to Java, where JIT was bolted on afterwards. JIT results are also cached, so multiple runs of the same code path do not require multiple JITs). Now I'm not assuring anyone that Mono is currently faster than Java (but Java isn't slow these days, even Python is slower). But due to its design, it has a much better chance of being optimized further than Java. We may never ever see Mono code running as fast as C++ or C or ASM, but it can be fast enough, or more than fast enough. (I am thinking someone with the ability to do so should develop a "persistent-run-time so startup time equals 0", perhaps coupled to on-disk JIT caches just like .pyc files, only on machine code - pyc files are in p-code like Mono assemblies.) Well, that's just about run speed. The other thing is development speed. Nearly 40% of development is spent in testing and debugging. This means that any platform that allows the developer to minimize defects will result in faster time-to-deliver. We now know for sure that it's better to leave some tasks to the computer, such as managing memory. Letting the machine manage its memory really helps development, because it: 1) lets the developer concentrate on the *problem* 2) avoids really-hard-to-track defects related to memory mgmt. I've been on track of a memory mgmt. defect on Directory administrator for three straight days, without being able to find it. I've also had leaks, leaks that I cannot fix because I simply don't have the skills to track and debug "hardcore". I'd seriously welcome C# as a first-class GNOME devel language, if only for the memory mgmt. thing. I'd rewrite DA in Python if I had the time, as well (due to time, I had to relinquish project control to somebody else). There were other advantages but right now I have to register two more bills in GnuCash. Nice talking to you! > > jamie. > > > > > > > This is exactly > > > what MS is doing with Longhorn to "persuade" all the developers to use > > > .Net > > > > That is true. They are doing it out of greed. Were we to do so, it > > would be only on technical merit, thus anything coming out of our camp > > would definitely be better. > > > > > > > > Jamie. > > > > > > > > > > > > > Christian > > > > > > > > _______________________________________________ > > > > desktop-devel-list mailing list > > > > desktop-devel-list gnome org > > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > > > > > > > > > > _______________________________________________ > > > desktop-devel-list mailing list > > > desktop-devel-list gnome org > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente