On 12/12/2012 3:12 AM, foobar wrote:
> Regarding performance and overflow checking, the example you give is x86
> specific. What about other platforms? For example ARM is very popular nowadays
> in the mobile world and there are many more smart-phones out there than there
> are PCs. Is the same issue exists and if not (I suspect not, but really have no
> idea) should D be geared towards current platforms or future ones?

I don't know the ARM instruction set.

On 12/12/2012 12:01 PM, Timon Gehr wrote:
> That is certainly fixable. It is a mere QOI issue.

When you have a language that fundamentally disallows mutation, some algorithms
are doomed to be slower. I asked Erik Maijer, one of the developers of Haskell, if the implementation does mutation "under the hood" to make things go faster. He assured me that it does not, that it follows the "no mutation" all the way.


> I think the factor GHC/DMD cannot be more than about 2 or 3 for roughly
> equivalently written imperative code.

A factor of 2 or 3 is make or break for a large class of programs.

Consider running a server farm. If you can make your code 5% faster, you need 5% fewer servers. That translates into millions of dollars.

Thread (and etc) is a high level abstraction that requires a support by hardware/software/instruction set. If it necessary, library can be integrated to language. And it's another one question about design.

> Thread (and etc) is a high level abstraction that requires a support by hardware/software/instruction set.

Not only. First of all, it requires that the compiler *knows* and *understands* the concept of thread. This is why C mimicking C++ will *never* get as fast as a true C++ compiler, for the latter *knows* what a class is and wat to expect from it, what are the goals and the uses of such concept.

The same stands for any other thing. The ideea is: conceptualization.

A compiler that does not know what a class is will only partially optimize, if any. It is a blind compiler.

On Wednesday, 12 December 2012 at 21:51:00 UTC, Michael wrote:
> Thread (and etc) is a high level abstraction that requires a support by hardware/software/instruction set.

And you can do happily multi-threading on a single processor, with no parallelization and so on. It is just time-slicing. This could be implemented at many levels: at the hardware level, at the OS level, but also at the compiler level (through a runtime).

Even OOP possible in asm.

It's completely OT ;)

Walter Bright:

> Consider running a server farm. If you can make your code 5% faster, you need 5% fewer servers. That translates into millions of dollars.

Two comments:
- I've seen Facebook start from PHP, go to PHP compiled in some ways, and lately start to switch to faster languages, so when you have tons of servers space and electricity used by CPUs becomes important for the bottom line. On the other hand on similar servers lot of other people use languages where there is far more than your 5% overhead, as Java. Often small performance differences are not more important than several other considerations, like coding speed, how much easy is to find programmer, how cheap those programmers are, etc, even on server farms.
- If your code is buggy (because of overflows, or other causes), its output can be worthless or even harmful. This is why some people are using OcaML for high-speed trading (I have given two links in a precedent post), where bugs risk being quite costly.

Bye,
bearophile

On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright wrote:
> On 12/12/2012 3:12 AM, foobar wrote:
>> Regarding performance and overflow checking, the example you give is x86
>> specific. What about other platforms? For example ARM is very popular nowadays
>> in the mobile world and there are many more smart-phones out there than there
>> are PCs. Is the same issue exists and if not (I suspect not, but really have no
>> idea) should D be geared towards current platforms or future ones?
>
> I don't know the ARM instruction set.

I think it would be very hard, at this stage, to argue that you should be putting your effort into ARM rather than x86. It's a nice to have that doesn't seem very relevant to gaining traction for D, areas like bioinformatics seem more relevant.

On Wednesday, 12 December 2012 at 22:36:35 UTC, ixid wrote:
> On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright wrote:
>> On 12/12/2012 3:12 AM, foobar wrote:
>>> Regarding performance and overflow checking, the example you give is x86
>>> specific. What about other platforms? For example ARM is very popular nowadays
>>> in the mobile world and there are many more smart-phones out there than there
>>> are PCs. Is the same issue exists and if not (I suspect not, but really have no
>>> idea) should D be geared towards current platforms or future ones?
>>
>> I don't know the ARM instruction set.
>
> I think it would be very hard, at this stage, to argue that you should be putting your effort into ARM rather than x86. It's a nice to have that doesn't seem very relevant to gaining traction for D, areas like bioinformatics seem more relevant.

http://santyhammer.blogspot.com/2012/11/something-is-changing-in-desktop.html

On 12/12/2012 2:17 PM, bearophile wrote:
> Two comments:
> - I've seen Facebook start from PHP, go to PHP compiled in some ways, and lately
> start to switch to faster languages, so when you have tons of servers space and
> electricity used by CPUs becomes important for the bottom line. On the other
> hand on similar servers lot of other people use languages where there is far
> more than your 5% overhead, as Java.

I know people who use Java on server farms. They are very, very, very cognizant of overhead and work like hell trying to reduce it, because reducing it drops millions of dollars right to the bottom line of profit.

Java makes no attempt to detect integer overflows.


> Often small performance differences are not
> more important than several other considerations, like coding speed, how much
> easy is to find programmer, how cheap those programmers are, etc, even on server
> farms.

The problem they have with C++ is it is hard to find C++ programmers, not because of overflow in C++ programs.


> - If your code is buggy (because of overflows, or other causes), its output can
> be worthless or even harmful. This is why some people are using OcaML for
> high-speed trading (I have given two links in a precedent post), where bugs risk
> being quite costly.

I personally know people who write high speed trading software. These people are concerned with nanosecond delays. They write code in C++. They even hack on the compiler trying to get it to generate faster code.

It doesn't surprise me a bit that some people who operate server farms use slow languages like Ruby, Python, and Perl on them. This does cost them money for extra hardware. There are always going to be businesses that have inefficient operations, poorly allocated resources, and who leave a lot of money on the table.