On Thu, Apr 2, 2015 at 12:09 AM, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On 31 March 2015 at 15:18, William Stein <wst...@gmail.com> wrote: > > <SNIP> >> >> >> All that said, Julia seems really exciting. If people write major >> packages of functionality in Julia that people doing mathematics >> really need, and is better than what is already in Sage, we could >> consider adding Julia to Sage... So far, the demand-from-end-users >> scale hasn't tipped in that direction. > > > We are already writing new sparse linear algebra and class group computation > code in Julia. > > Much of it is still slower than Magma, due to various things we are missing. > But some parts are already orders (plural) of magnitude faster than > Magma/Pari.
Can you provide some links so that people reading these threads can easily try out and or look at what you're working on? Thanks. I just got excited by everything you wrote below, and thought "heh, I want to fire up Julia and try this out...! but I have to give a talk this morning so I only have a few moments to spare..." I realize you've posted or sent me a link or something before, but it'll take me 5+ minutes just to find it, and it might be out of date. (And of course, thanks for posting.) > > One of the big problems we have at present is that all the different > packages we are using or plan to use (Flint, ANTIC, Pari, Arb, Singular, > Factory, Julia, Gap, NTL, etc.) use different fundamental formats for basic > things like integers. And they have incompatible memory managers. This > results in either ugly hacks or 100x slowdowns in some things we need. > > The other major issue is that some of these libraries are fundamentally > dynamically typed, even at the C/C++ level. Agreed, it is difficult to do > any terribly serious mathematics without generics, which are fundamentally > dynamic. But the lesson learned is that all the high level generic code > basically has to be in the same language if you want to eliminate massively > uneven performance. > > I spent months listening to people complain about how it was better to have > a lot of code that worked than a small amount of code that worked really > fast. Those same people are now coding stuff in Julia and complaining about > "100x slowdowns" and "design issues" in my Julia code. > > For the first time in my life, other people are complaining to me that > things are not running fast enough for them, instead of it being the other > way around. > > Unfortunately, writing things in Julia and C/C++ makes it really obvious > where the amateurish code is. > > I'm seriously considering splitting the Julia codebase that I have been > working on into two parts: > > 1) A system where all the various packages are fully wrapped and data > conversions just cost additional time. > > 2) A system where only fast statically typed code is wrapped from each > package (not much in some cases, not mentioning any names), plus complex > functionality from the various packages with high computational complexity > where data conversion costs are almost irrelevant (Julia can even call > python code using its pycall interface). Everything else (including all > generics and everything built on it) will be reimplemented directly in > Julia. > > Number 2 would not have as much functionality, and would be targeted at > number theorists, who apparently really care about smooth performance, and > the other would be for just about everyone else. > > Ultimately we are going to need much greater technical cooperation between > the various packages, especially in the area of memory management, data > conversion and C interfacing. > > We'll also have to do quite some work to get all the packages working on > Mingw64. We have a strategy for doing this, just not enough time to > implement it as of now. > > Of course there are some other issues we haven't resolved in the Julia > stuff: > > 1) Julia integer literals have inconsistent semantics. Not very useful for a > CAS. > > 2) The Julia division operators are only really useful for numerical people. > They aren't the definitions algebraists want to see/use. > > 3) Julia matrices are optimised for column operations, not row operations, > as various other packages are. > > 4) There are still some bugs in the Julia type system and garbage collector > and we are still working with development branches of various things (llvm, > cxx, julia, lldb) that are frequently broken. > > 5) Our generic power series and p-adic modules were implemented in a > completely amateurish way (by me) and need to be completely re-implemented. > > So the time is not right for the average developer just yet. But we are > still getting serious work done. I anticipate things will look much better > in another 6-12 months, after possibly another rewrite. > > Bill. > > -- > You received this message because you are subscribed to the Google Groups > "sage-flame" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-flame+unsubscr...@googlegroups.com. > To post to this group, send email to sage-fl...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-flame. > > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
