Ah, *JAVAC*. But that's not *java*, which was claimed. Java source files are easy to compile in a multi-threaded environment, and very fast to boot.
For every file, you need to do: 1. Build an AST. This is 100% independent of other source files, and thus can be multicored trivially. 2. Extract a list of type names from an AST. This is again 100% independent. 3. Extract a list of signatures from the AST. This requires knowing the structure of everything on the classpath as well as all those type names from all ASTs, so you need to first have all cores finish step 2 and sync this across the processes before going on to step 3 here. 4. Resolve and compile all classes contained in the AST. This requires completion of step 3 as well as syncing all those signatures to all processes. And don't forget that in java land, recompiling an unchanged source file is rarely necessary. That's massively parallelizable. It hasn't been done yet, because javac, singlethreaded and all, just isn't slow enough to get on anyone's nerves. Especially considering that step 1, which was trivially and fully parallelizable, takes easily 90% of the total time taken. (Parsing is just difficult and slow, no way around that). On Jul 27, 8:34 am, Casper Bang <[email protected]> wrote: > One thing is for certain, reading the source code, javac isn't > designed for multithreaded compilation/linking! This is in contrast to > C#. Having said that, compilation and link time is hardly Java's > biggest problem. > > /Casper > > On Jul 27, 3:32 am, Reinier Zwitserloot <[email protected]> wrote: > > > > > Java isn't designed for efficient compile/link? > > > Lies. > > > On Jul 25, 5:54 pm, RogerV <[email protected]> wrote: > > > > Go language was motivated as an answer to Google's C++ problem. A lot > > > of their server software is written in C++. > > > > Go provides an intrinsic way to do concurrency and via goroutine > > > messaging, does not revolve around having to get locks right for multi- > > > threaded access to objects. > > > > Also, the goroutine concurrency is far more fine-grained than > > > threading. Threads are upper-bounded by what the underlying operating > > > system can effectively manage (usually topping out at a few thousand > > > at best). There are Go sample programs that spawn up to a 100,000 > > > goroutines in a single program and harvest values from them. > > > > However, a very significant paint point for all the C++ code base is > > > the build time overhead. Go language is designed to be very fast to > > > compile and link into executables. > > > > Java doesn't have an intrinsic actor model approach to concurrency. > > > Nor has Java been targeted for very efficient compile/link into > > > executable ala Go. > > > > Go also has a huge boilerplate reduction in code verbosity relative to > > > Java. It compiles down to native code and its feasible to directly > > > call a lot of POSIX APIs from Go without all the fuss and muss of > > > Java's JNI muck. Go didn't have a package for interacting with file > > > system events, but because how how easy it is to inter-operate with > > > Linux APIs, I was able to whip up a Go package on top of Linux inotify > > > subsystem in short order. > > > > I kind of see Go as a language that has appeal to people that like the > > > C language. It's not as low level to the degree that C is (no pointer > > > arithmetic) but it has an essence of C simplicity about it. Sort of a > > > C brought into the 21 st century. > > > > If you prefer the coolness factor of the functional languages, and C > > > didn't ever have much appeal to you, then you probably won't really > > > care for Go. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. 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/javaposse?hl=en.
