View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2012
Re: OT (partially): about promotion of integers
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.
December 12, 2012
Re: OT (partially): about promotion of integers
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.
December 12, 2012
Re: OT (partially): about promotion of integers
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.
December 12, 2012
Re: OT (partially): about promotion of integers
> 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.
December 12, 2012
Re: OT (partially): about promotion of integers
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).
December 12, 2012
Re: OT (partially): about promotion of integers
Even OOP possible in asm.

It's completely OT ;)
December 12, 2012
Re: OT (partially): about promotion of integers
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
December 12, 2012
Re: OT (partially): about promotion of integers
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.
December 12, 2012
Re: OT (partially): about promotion of integers
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
December 12, 2012
Re: OT (partially): about promotion of integers
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.
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home