Re: mixed-sign arithmetic and auto
Walter Bright wrote:
Bo Persson wrote:
Walter Bright wrote:
Bo Persson wrote:
My experience porting D code between platforms is it ports
easier than the equivalent C++ code.
Porting is easier if you limit the number of potential platforms.
Sure, but I was comparing porting C++ from platform A to B with
porting D from A to B. The latter was noticeably easier.
It could be because the variation is smaller. There are some
platforms were you cannot easily implement D at all, like IBM
zSeries with EBCDIC character set and non-IEEE floating point. C++
has no problem with that.
No problem compiling the code, that is. It offers no guarantee your
ascii code will run. All the porting problems are dumped on the
programmer.
My code isn't coded for ACSII, and I don't want to port it. This is
all about inhouse applications. We just want to write code for the
hardware we have.
So yes, C++ 'supports' EBCDIC. But C++ doesn't support Unicode or
UTF encodings. D's native character set is Unicode UTF-8, UTF-16,
and UTF-32. EBCDIC is the past, Unicode is the future.
But we live with the past. 40 years of EBCDIC code just doesn't go
away.
Java, based on ascii, runs on EBCDIC machines. So it clearly can't
be that hard.
For some definition of "runs", see below.
Floating point is another issue. FP code is often very sensitive to
precision and other details. You might even need to use different
algorithms for non-IEEE arithmetic. The fact that the code manages
to compile on those machines is of no help at all in finding/fixing
such dependencies.
It's not about porting, it's about being allowed to write custom code
for the machine. Too bad if the language spec says that you cannot!
Porting Java is easy too, if your target platform supports it.
Porting Java is hard, if you haven't ported its platform first!
Porting C++ compilers is pretty hard, too. How many programmers do
you know who can write a code generator?
The point was rather that Java is very hard, if the intended
platform doesn't support the spec. It might require adding
dedicated hardware: http://www-03.ibm.com/systems/z/zaap/
zaap is not required to run Java on those machines (see the zaap
faq). All it is is a hardware accelerator specific to Java
bytecodes.
"All it is" is that it enables you to run Java code on the mainframe,
with resonable efficiency. Without the accellerator, even JIT-ed code
made the WebSphere server consume 50% of the CPU resources on
Enterprise level z9 hardware. The other several hundred applications
had to be content with the other half of the machine.
We had a discussion just last week with a Java developer on
reusing his web server code on the mainframe.
- "Oh dear! That's just Java 1.5, I need 1.6 generics for my
code. Limiting myself to 1.5 features will cost you a lot more!"
But isn't Java implemented in C? C is more portable and available
on every platform, so he should just recompile it and he's good
to go.
Well, IBM believe they should decide what Java version to run on
z/OS.
That's a problem with IBM, not any particular language.
It also needs to access the special Application Assist hardware to
do IEEE floating point. C and C++ doesn't have to do that.
So, with the JVM implemented in C, how does C being compilable on
that machine mean that we can just recompile the JVM and have Java
work? We both know that doesn't happen - and that just having code
compile doesn't mean it is portable.
And the absurdity here is that the Java spec makes it less portable.
Having the JVM implemented in C isn't enough, if it means that you
have to emulate the hardware. C and C++ can use the hardware, Java
cannot.
Also, we have no requirement for the code to be portable. It only runs
on one set of hardware!
For our inhouse applications portability is no concern, but Java
still insists on using a portable data format.
Then I believe we agree that there's more (a lot more) to portable
C++ code than being able to recompile it.
Even if it is more expensive.
A lot more, in this case!
It boggles the mind to think people will pay $125,000 for zaap
which is only good for accelerating Java apps, when they can use
cheap linux boxes instead. It's not like Java apps are legacy apps
from the
60's.
And some people buy several of these, to solve the other problem -
access to the data.
We started out running web applications on a room full of PC level
hardware. Using C++, and everything. :-)
Turned out there was a scaling problem. The databases were still on
the mainframe, because that is where the data is produced. The
bottleneck turned out to be the communications between the PC servers
and the back end database. The transactions timed out.
So, by moving the web server over to the mainframe that was solved. At
the expense of rewriting everything in Java, and investing a couple of
$100k in application specific hardware (about 4 zAAPs I guess). So
Java's portable spec cost us that amount, for code that isn't portable
anyway!
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]