4 ms·
When directly talking to hardware, C is enough. Noone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is
by pkolaczk 13y ago
When directly talking to hardware, C is enough. Noone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is wrong, too). I was refering to database systems or other software that is very close to system, e.g. application- or web-servers. In this area Java is excellent choice and performance-wise it often beats C++ because of superior concurrency support. And you can always code the low-level pieces in C, if you really need those unsigned arithmetic or bitfields.
- pandaman 13y agoNobody is talking about C's insufficiency for programming. When doing anything C is enough just like any other Turing-complete language. You'd been saying that in your humble opinion system programming in Java is no harder than in C++, which is something very alien to my experience of actually programming on the system level (as same as your performance claims but I am not even going to get into this one. Last time I did a Java programmer told me that a Java program that is measuring as 4 times slower is running "on the same level", whatever that means).
- pkolaczk 13y agoIs Netty system-level enough? Or Cassandra? Or Tomcat? Or Apache Spark? Or Hadoop? Or Akka? For some reasons devs chose Java to implement them, not C++. As of performance, they are doing extremely well. Last time I checked Netty vs Nginx was a tie; Tomcat vs Apache HTTP were also extremely close; Apache Spark (pure Java) is generally much faster than Impala (using C++); and Cassandra has no direct competitors written in C++ so far (not counting 1000 toy databases here), but it is definitely one of the top performant NoSQL stores out there.
- pandaman 13y agoSorry, I don't know what any of these does. When I went to school it was common convention that system level is the OS kernel, drivers and anything else that talks to the hardware.
- pjmlp 13y agoWhile I do agree with you, how do you implement such features in fully pure ISO/ANSI C++ compliant compiler?
- pandaman 13y agoAll the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there the bulk of work is creating control structures in memory and then kicking them through a port or a coprocessor instruction). C/C++ are perfect for the memory manipulation even in their purest standard form. I imagine your concern is about deriving the addresses for register apertures or emitting specific opcodes? For the concrete addresses you just link with the symbols defined outside of your C code. Special ops cannot be done in pure standard, but this is not an issue in practice as there are no pure standard compilers. Even for app development you want intrinsics just for the vector, cache and bit instructions.
- pjmlp 13y agoNo, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler. You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs. There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.
- pandaman 13y agoI guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).
- 13y ago
- taspeotis 13y agoNoone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is wrong, too) You are correct, C++ is a bad choice for low-level device drivers. But it's getting better [1]! [1] http://msdn.microsoft.com/en-us/windows/hardware/gg487420.aspx http://msdn.microsoft.com/en-us/windows/hardware/gg487420.as...