 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> *Anything* compiles extremely quickly compared to C++. Just don't perform the
> same.
With JIT compilers and such, I'm not sure how you can be so sure. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++. Just don't perform the
> > same.
>
> With JIT compilers and such, I'm not sure how you can be so sure. :-)
Look for the top:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1®exdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
with memory performance taken into consideration as well, it only gets worse:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1®exdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
Yes, I'm aware theoretically a JITted program running for long should be able to
be extra tuned on the fly and drop irrelevant parts to run faster. That isn't
reflected in the charts, of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++. Just don't perform the
> > same.
> With JIT compilers and such, I'm not sure how you can be so sure. :-)
I have no idea about the principles used in C#, but if it's anything like
Java, the biggest problem is not so much speed as memory usage. In Java
I don't think there's any way around the problem that you cannot create
a data container where each element takes as much memory as the total size
of the members of the object, nothing more. The smaller the object is, the
worse the memory usage overhead relative to this size.
I actually find it a bit worrying that it seems that no programming
language introduced in the last 20 years which has got some popularity
seems to offer any tools *whatsoever* to create memory-efficient programs
(at least not without resorting to really ugly code which bypasses nice
modular design).
Many people will say "that doesn't matter, memory amount is increasing
all the time". However, that's only a valid point for programs which use
a *fixed* amount of memory for what they do. In other words, a program
which required a fixed amount of 500 megabytes of memory when written in
a memory-efficient way in C++ 10 years ago may well run ok when written
in Java with a modern computer which has 4 gigabytes of RAM.
However, it's rather rare that a program uses a huge amount of memory,
and that this amount is somehow fixed. The more usual case is that memory
usage is dynamic, and having more RAM in the computer will allow the program
to perform more than before. In other words, that program which 10 years
ago could perform a certain task with 500 MB of RAM may well be able to
perform a much larger task in a computer with 4 GB of RAM, while the java
version will only be able to perform the same task as the 10yo computer.
In other words, the same program written in Java will be able to do
less than the version written in C++. And often you just *can't* create
a Java version which would be able to do the same things as the C++ version
with a given amount of memory, no matter what you try. (In some cases
similar memory usage may be achieved in Java, but at the cost of making
the code less modular and a lot more complicated.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> 2) Resource manage is *incredibly* easy. In the "Solution Explorer",
> simply bring up the context menu and choose "Add Existing" or "Add New",
> give it a name (and select the file if it aleady exists), and it's
> imported into the correct directory.
Does it have any support for creating a (possibly encrypted) package
from all the resources so that you don't have to distribute a bare version
of your resources directory structure, but instead you can simply distribute
this single package file with your program?
(There are many reasons why one would want to do this, but the main
reason is that packaging (and encrypting) all the resources is a simple
"anti-spoiler measure": A curious user navigating the directory structure
of the game won't be able to spoil himself about the contents of the game
by simply double-clicking on the files.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage.
It's a lot like Java, but not in that respect. C# has things called
"structures" which you can't inherit from, but are otherwise objects.
They're basically value semantics. It's part of the type rather than the
variable (unlike C++), but an integer takes the same number of bytes in
C# as in C++. I.e., you can make a struct that takes 12 bytes of
storage, create an array of 10 of them, and it'll take 120 bytes of storage.
C#'s VM is also more targetted at JIT compilation. For example, at any
given point in the VM bytecode, no matter how you get there, the stack
has to have the same types on the stack. So in theory, if you had a
bunch of registers, you could assign anything that was put onto the
stack into a register instead. Just as one of many examples.
> I actually find it a bit worrying that it seems that no programming
> language introduced in the last 20 years which has got some popularity
> seems to offer any tools *whatsoever* to create memory-efficient programs
We already have those languages. Anyway, you're missing Ada. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Does it have any support for creating a (possibly encrypted) package
> from all the resources
I thought it was pretty cool that you can encrypt the debug info in
Erlang with a chosen key, so you can understand the stack traces only if
you have that key, for example. Full source-level debugging with the
package, but no way to recreate the source without knowing the key.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage. In Java
> I don't think there's any way around the problem that you cannot create
> a data container where each element takes as much memory as the total size
> of the members of the object, nothing more. The smaller the object is, the
> worse the memory usage overhead relative to this size.
Wasn't it John Carmack who said that Java is a great way of doing things
at 1/10th the speed they should be done at? :)
Anyway, one of the first things I noticed in looking over C# is the
difference in structs and classes. Basically, a Class is the same as a
C++ struct / class, with the indirection et al, allocated on the heap.
A struct, on the other hand, has no member functions, and is a simple
collection of the base data types all allocated on the stack. Very
sparse memory usage, and very fast, either as individual instances or in
collections.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> 2) Resource manage is *incredibly* easy. In the "Solution Explorer",
>> simply bring up the context menu and choose "Add Existing" or "Add New",
>> give it a name (and select the file if it aleady exists), and it's
>> imported into the correct directory.
>
> Does it have any support for creating a (possibly encrypted) package
> from all the resources so that you don't have to distribute a bare version
> of your resources directory structure, but instead you can simply distribute
> this single package file with your program?
It does have support for packaging your projects, but I don't believe it
has encryption. It's compiled into a bytecode, so it's very easy to
decompile into the original sources. If you encrypted it, then the same
key which allows it to execute would allow it to be decompiled.
Of course, you could use an obfuscator, and there are commercial
packages available that integrate nicely with VS to do this
automagically for you when you build your project.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> C++ struct / class, with the indirection et al, allocated on the heap. A
> struct, on the other hand, has no member functions,
Woops, this is wrong. Structs *can* have member functions.
Also, structs are passed by value whereas classes are passed by reference.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> > Does it have any support for creating a (possibly encrypted) package
> > from all the resources so that you don't have to distribute a bare version
> > of your resources directory structure, but instead you can simply distribute
> > this single package file with your program?
> It does have support for packaging your projects, but I don't believe it
> has encryption. It's compiled into a bytecode, so it's very easy to
> decompile into the original sources.
Hmm, that's not really what I asked...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
