Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier thusly wrote:

> language_fan wrote:
>> Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
>> 
>>> You're right about concurrency being a different concept than
>>> threading,
>>>   but I wouldn't give threading away for a pure concurrent model
>>>   either.
>>> I believe D is aiming at giving programmers a choice of the tools they
>>> wish to use. I could see uses of both a concurrent model with message
>>> passing and a threading model with shared data used at once in a
>>> program.
>> 
>> The danger in too large a flexibility is that concurrency is not easy and it is getting incresingly complex. You need to be extraordinary good at manually managing all concurrent use of data. If I may predict something that is going to happen, it is that there will be high level models that avoid many low level pitfalls. These models will not provide 100% efficiency, but they are getting faster and faster, without compromizing the safety aspect. This already happened with memory allocation (manual vs garbage collection - in common applications, but not in special cases). Before that we gave some of the error detection capabilities to the compiler (e.g. we do not write array bounds checks ourselves anymore). And optimizations (e.g. register allocation). You may disagree, but I find it much more pleasant to find that the application does never crash even though it works 15% slower than an optimal C++ code would.
> 
> 15% slower is an extreme performance hit. I agree that code safety is useful and I use this model all the time for initialization and other code which isn't real time, but 15% takes away a lot of the application's responsiveness, if you have 50 such applications running on your system you just spent $1000 more in hardware to get the performance of entry level hardware with faster code.

The cost of e.g. doubling computing power depends on the domain. If you are building desktop end user applications, they usually should scale from single core atoms to 8-core high-end enthusiastic game computers. So the cpu requirements shouldn't usually be too large. Usually even most of the 1-3 previous generations' hardware runs them just nicely.

Now doubling the cpu power of a low-end current generation PC does not cost $1000, but maybe $20-50. You can continue this until the cpu costs about $400-500. By then you've achieved at least tenfold speedup. On the gpu market the cheapest chips have very limited capabilities. You can buy 5 times faster graphics cards for $50-60. $150-160 will get you a 25 times faster gpu than the first one. 4..8 GB RAM is also really cheap these days, and so is a 1.5 TB hard drive. Hardly any desktop program requires that much from the hardware. The 15% or even 50% slower execution speed seems rather small a problem when you can avoid it by buying faster hardware. Hardly any program is cpu bound, not even the most demanding games are.

On the server side many systems use php which is both unsafe and slow. If you have decent load balancing and cache systems, it does not even matter since the system may not be cpu bound, either. Even top10 popular sites like wikipedia run on slow php.

On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:

> Robert Jacques wrote:
>> On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
>> [snip]
>>> Its the same for concurrency, I can think of vector processing, functional calls, STM, message passing and shared memory off the top of my head. All being valid models with each their pros and cons, together forming a complete all-around solution.
>>>
>>> Jeremie
>> Don't forget task-based or lock-free.
>
> Oh yeah, thanks! Those were covered by Bartosz in his blog right? I think he used the term Actor for task based programming, I really enjoyed reading these articles.

There are many things called Actors, but they generally boil down to a process/thread/object + message passing. It's a good model, particularly for the cloud.  Task programming is generally intra-process and works on the level of a single work-task (aka function). Cilk, futures or Intel's Threading Building Blocks are the canonical examples. The nice thing (I think) about a good work-stealing runtime is that it can provide the back-end for CPU-vector processing, tasks/futures, intra-process actors and functional calls.

Christopher Wright wrote:
> Jeremie Pelletier wrote:
>> language_fan wrote:
>>> Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
>>>
>>>> You're right about concurrency being a different concept than threading,
>>>>   but I wouldn't give threading away for a pure concurrent model either.
>>>> I believe D is aiming at giving programmers a choice of the tools they
>>>> wish to use. I could see uses of both a concurrent model with message
>>>> passing and a threading model with shared data used at once in a
>>>> program.
>>>
>>> The danger in too large a flexibility is that concurrency is not easy and it is getting incresingly complex. You need to be extraordinary good at manually managing all concurrent use of data. If I may predict something that is going to happen, it is that there will be high level models that avoid many low level pitfalls. These models will not provide 100% efficiency, but they are getting faster and faster, without compromizing the safety aspect. This already happened with memory allocation (manual vs garbage collection - in common applications, but not in special cases). Before that we gave some of the error detection capabilities to the compiler (e.g. we do not write array bounds checks ourselves anymore). And optimizations (e.g. register allocation). You may disagree, but I find it much more pleasant to find that the application does never crash even though it works 15% slower than an optimal C++ code would.
>>
>> 15% slower is an extreme performance hit. I agree that code safety is useful and I use this model all the time for initialization and other code which isn't real time, but 15% takes away a lot of the application's responsiveness, if you have 50 such applications running on your system you just spent $1000 more in hardware to get the performance of entry level hardware with faster code.
> 
> What are most applications these days? MS Office, a web browser, maybe an email client, some odds and ends, and a whole bunch of web sites running on servers somewhere (with associated database servers and some other odds and ends).
> 
> How much does it cost to get a slightly better machine? Fully hosted? Maybe $100/month.
> 
> How much does it cost to develop it in a faster but more error-prone language? Maybe months more time to market, time you're not making money but are still paying developers. Those developers will need to be more skilled than the ones using a safer language, and thus will cost you more. New features will take more time to develop.
> 
> It's a competitive advantage to use a slower, safer language on the web.
> 
> Desktop applications are not quite so straightforward.

I agree with you about web applications, scripting languages are fast enough to serve web pages in most cases. However I did see some pretty ugly code which took over a minute to generate a page from a 1.5Gb database using only string fields without any indexes and PHP was throwing more notices and warnings than actual html.

I was referring to desktop applications, where you can't just buy a second server to host your database and serve static content like images and whatnot. From the 2 years I worked in tech support the problem I saw the most often was computers slowed down to a crawl, many of them without viruses or spywares. There are so many people who upgrade their computer just so they can run new software that really doesn't have many new features, but just is written in a safer language. That 15% performance hit over all the programs they ran at once was just too much for their old processor, when 2 months ago before they upgraded the software it was working just fine. Live messenger should not take half a minute to load and perform poorly when the old msn messenger was running perfectly fine.

>> If you wrote a real time renderer for example with that 15% hit, you get a very noticeable difference in framerate. Not to mention standard GUIs to be laggy on slower machines (just MSN messenger runs to a crawl on my old computer, yet it can run the first UT which does way more operations per second, because there's no performance hit by safer code bloat).
> 
> Games are not interesting in this regard. They require performance, and they're hideously expensive. A studio can throw developers at the problems and make them go away.
> 
> Not all games are like this, of course. But most are.

<rant>

What happened to one man armies like John Carmack and Tim Sweeney? These were the guys who inspired me to get into coding in the first place. I just loved how they could put together entire engines on their own and carefully optimize them. What about Walter who wrote the first C++ compiler and optlink as well as dmd from which I learned so much about compiler internals, or Andrei and his extensive work on meta programming and generic programming, from which I also learned so much.

There's also that one guy developing the game LOVE all on his own using only C, he wrote his tools, his engine, his model format, does his artwork, *everything*. And he is making some quick progress that would make teams of 50+ jealous.

Point is, only companies have the resources to throw more people at the problem and forget about it. At the end of the day, if you multiply the number of people involved by the development time, the one man army still is winning by far, both in time and resources spent.

Games were only an example, what about programs like flash, photoshop, autocad, 3dsm, and others. No matter what domain you're interested in you're gonna come across program that require every bit of performance they can get. Be it developed by teams of 50+ programmers or a single one.

I'm not saying safer languages are bad, far from that, I'm just saying there's a way to get the productivity of these languages and the optimization power of unsafe languages together, and there's a target audience for that.

Having a single language which provides enough features to allow either safe development or unsafe development will also get everything in between. This is what got me hooked on D in the first place, even when I first read about it this is what was going through my head, and I haven't looked back since.

</rant>

Jeremie.

Robert Jacques wrote:
> On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
> 
>> Robert Jacques wrote:
>>> On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
>>> [snip]
>>>> Its the same for concurrency, I can think of vector processing, functional calls, STM, message passing and shared memory off the top of my head. All being valid models with each their pros and cons, together forming a complete all-around solution.
>>>>
>>>> Jeremie
>>> Don't forget task-based or lock-free.
>>
>> Oh yeah, thanks! Those were covered by Bartosz in his blog right? I think he used the term Actor for task based programming, I really enjoyed reading these articles.
> 
> There are many things called Actors, but they generally boil down to a process/thread/object + message passing. It's a good model, particularly for the cloud.  Task programming is generally intra-process and works on the level of a single work-task (aka function). Cilk, futures or Intel's Threading Building Blocks are the canonical examples. The nice thing (I think) about a good work-stealing runtime is that it can provide the back-end for CPU-vector processing, tasks/futures, intra-process actors and functional calls.

I think the best way to deal with actors is by making them objects. Binding them to heavyweight kernel structures such as threads and processes will greatly limit the number of concurrent actors you can execute at once.

Tasks would be most likely implemented by async methods, since you don't care about knowing when they're done. On the other hand, futures are there when you need an async call and monitor its completion.

A good implementation could therefore easily support tens of thousands of concurrent actors.

I must admit its the first time I hear about work-stealing, I will need to do some research on that :)

language_fan wrote:
> Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier thusly wrote:
> 
>> language_fan wrote:
>>> Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:
>>>
>>>> You're right about concurrency being a different concept than
>>>> threading,
>>>>   but I wouldn't give threading away for a pure concurrent model
>>>>   either.
>>>> I believe D is aiming at giving programmers a choice of the tools they
>>>> wish to use. I could see uses of both a concurrent model with message
>>>> passing and a threading model with shared data used at once in a
>>>> program.
>>> The danger in too large a flexibility is that concurrency is not easy
>>> and it is getting incresingly complex. You need to be extraordinary
>>> good at manually managing all concurrent use of data. If I may predict
>>> something that is going to happen, it is that there will be high level
>>> models that avoid many low level pitfalls. These models will not
>>> provide 100% efficiency, but they are getting faster and faster,
>>> without compromizing the safety aspect. This already happened with
>>> memory allocation (manual vs garbage collection - in common
>>> applications, but not in special cases). Before that we gave some of
>>> the error detection capabilities to the compiler (e.g. we do not write
>>> array bounds checks ourselves anymore). And optimizations (e.g.
>>> register allocation). You may disagree, but I find it much more
>>> pleasant to find that the application does never crash even though it
>>> works 15% slower than an optimal C++ code would.
>> 15% slower is an extreme performance hit. I agree that code safety is
>> useful and I use this model all the time for initialization and other
>> code which isn't real time, but 15% takes away a lot of the
>> application's responsiveness, if you have 50 such applications running
>> on your system you just spent $1000 more in hardware to get the
>> performance of entry level hardware with faster code.
> 
> The cost of e.g. doubling computing power depends on the domain. If you are building desktop end user applications, they usually should scale from single core atoms to 8-core high-end enthusiastic game computers. So the cpu requirements shouldn't usually be too large. Usually even most of the 1-3 previous generations' hardware runs them just nicely.
> 
> Now doubling the cpu power of a low-end current generation PC does not cost $1000, but maybe $20-50. You can continue this until the cpu costs about $400-500. By then you've achieved at least tenfold speedup. On the gpu market the cheapest chips have very limited capabilities. You can buy 5 times faster graphics cards for $50-60. $150-160 will get you a 25 times faster gpu than the first one. 4..8 GB RAM is also really cheap these days, and so is a 1.5 TB hard drive. Hardly any desktop program requires that much from the hardware. The 15% or even 50% slower execution speed seems rather small a problem when you can avoid it by buying faster hardware. Hardly any program is cpu bound, not even the most demanding games are.
> 
> On the server side many systems use php which is both unsafe and slow. If you have decent load balancing and cache systems, it does not even matter since the system may not be cpu bound, either. Even top10 popular sites like wikipedia run on slow php.

While I agree with what you say, here in Canada our computer parts are often twice the price they cost in the US, we kinda get screwed over transport and customs. A high end CPU is not $500 but well above $1000 CAD alone.

And quite frankly, its annoying to change computers every 6 months, I myself buy the high end top of the line every 4-6 years just to avoid that and rarely buy upgrades in between since by then its a new CPU socket, new DDR pinout, new GPU slot, and then I need a more powerful PSU and all that requires a new mobo. Then bluray is out so I change my optical drives, and theres a new sata standard so I get new HDDs.

About PHP, its a language that can generate the same webpage in either 0.002 seconds or 2 minutes. Load balancing helps when you cant optimize PHP anymore or when your database is eating all your system resources. Wikipedia most likely has load balancing, but it definitely has well written PHP code running over it too.

language_fan wrote:
> The cost of e.g. doubling computing power depends on the domain. If you are building desktop end user applications, they usually should scale from single core atoms to 8-core high-end enthusiastic game computers. So the cpu requirements shouldn't usually be too large. Usually even most of the 1-3 previous generations' hardware runs them just nicely.
> 
> Now doubling the cpu power of a low-end current generation PC does not cost $1000, but maybe $20-50.

You also need to consider how widely distributed your application is. If you force a million desktop PC users to upgrade their CPUs, you just wasted twenty to fifty million dollars of your customers' money (or, more likely, lost a million customers).


-- 
Rainer Deyke - rainerd@eldwood.com

On Fri, 25 Sep 2009 00:07:08 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:

> Robert Jacques wrote:
>> On Thu, 24 Sep 2009 20:59:23 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
>>
>>> Robert Jacques wrote:
>>>> On Thu, 24 Sep 2009 20:46:13 -0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
>>>> [snip]
>>>>> Its the same for concurrency, I can think of vector processing, functional calls, STM, message passing and shared memory off the top of my head. All being valid models with each their pros and cons, together forming a complete all-around solution.
>>>>>
>>>>> Jeremie
>>>> Don't forget task-based or lock-free.
>>>
>>> Oh yeah, thanks! Those were covered by Bartosz in his blog right? I think he used the term Actor for task based programming, I really enjoyed reading these articles.
>>  There are many things called Actors, but they generally boil down to a process/thread/object + message passing. It's a good model, particularly for the cloud.  Task programming is generally intra-process and works on the level of a single work-task (aka function). Cilk, futures or Intel's Threading Building Blocks are the canonical examples. The nice thing (I think) about a good work-stealing runtime is that it can provide the back-end for CPU-vector processing, tasks/futures, intra-process actors and functional calls.
>
> I think the best way to deal with actors is by making them objects. Binding them to heavyweight kernel structures such as threads and processes will greatly limit the number of concurrent actors you can execute at once.
>
> Tasks would be most likely implemented by async methods, since you don't care about knowing when they're done. On the other hand, futures are there when you need an async call and monitor its completion.
>
> A good implementation could therefore easily support tens of thousands of concurrent actors.
>
> I must admit its the first time I hear about work-stealing, I will need to do some research on that :)

:) I prefer Actor's being objects with async methods too.

Anyways here's the work-stealing concept in brief:
Each thread/actor keeps a set of tasks to be done. This avoids having a single point of contention for task creation/assignment. When a worker thread runs out of tasks it then steals tasks from other actors/threads. Both Cilk and Intel's TTB are good places to start reading. For low latency, futures require a set with efficient random removal. I.e. the promise becomes due, so the current thread assigns the associated future to itself. Actors, on the other hand, should be limited to FIFO, to maintain consistency. Though mutable methods would require exclusive access, in theory const and immutable methods should be able to be run in parallel with each other.

Thu, 24 Sep 2009 22:58:51 -0600, Rainer Deyke thusly wrote:

> language_fan wrote:
>> The cost of e.g. doubling computing power depends on the domain. If you are building desktop end user applications, they usually should scale from single core atoms to 8-core high-end enthusiastic game computers. So the cpu requirements shouldn't usually be too large. Usually even most of the 1-3 previous generations' hardware runs them just nicely.
>> 
>> Now doubling the cpu power of a low-end current generation PC does not cost $1000, but maybe $20-50.
> 
> You also need to consider how widely distributed your application is. If you force a million desktop PC users to upgrade their CPUs, you just wasted twenty to fifty million dollars of your customers' money (or, more likely, lost a million customers).

I do not believe the market works this way. According to that logic popularity correlates with expenses. So if you have e.g. 1 billion users, even $1 in per-user hardware costs causes a billion dollar losses to customers. Is that unacceptable? On the other hand a program with a userbase of 10 might require a $100 hw upgrade and it is still ok?

Usually it is the other way, more popular programs pretty much dictate what hardware is useful today. E.g. consider a G4 Mac or PIII PC, it is pretty much useless today since popular web applications like facebook, myspace, youtube, and others are way too slow on it. (not to mention the obligatory virus scanner updates which today require a 2 GHz PC). The HD videos in youtube may require a 1.2+ GHz PC. If you buy an office suite, the old Windows 98 will not even let you install it. Upgrading to Vista is not possible since it will not fit to the 10 GB hard drive. The stores will not sell PATA drives anymore so you either need to buy a PCI PATA controller (not supported by the OS, of course) or upgrade the case, psu, mobo, cpu, memory chips, graphics card, and the hard disk.

A used 2.5 GHz Athlon XP with 1GB of RAM and 100GB of disk costs about $100. Anything below that is obsolete these days. Good luck selling anything to people who use older computers, they are probably broke anyways. Otherwise I just see it cheaper to build your apps slower and require hardware updates. Just imagine - a highly optimized $400 program is way too expensive for most users, a $50 program + $200 hw upgrade sounds just fine.

language_fan wrote:
> Thu, 24 Sep 2009 22:58:51 -0600, Rainer Deyke thusly wrote:
> 
>> language_fan wrote:
>>> The cost of e.g. doubling computing power depends on the domain. If you
>>> are building desktop end user applications, they usually should scale
>>> from single core atoms to 8-core high-end enthusiastic game computers.
>>> So the cpu requirements shouldn't usually be too large. Usually even
>>> most of the 1-3 previous generations' hardware runs them just nicely.
>>>
>>> Now doubling the cpu power of a low-end current generation PC does not
>>> cost $1000, but maybe $20-50.
>> You also need to consider how widely distributed your application is. If
>> you force a million desktop PC users to upgrade their CPUs, you just
>> wasted twenty to fifty million dollars of your customers' money (or,
>> more likely, lost a million customers).
> 
> I do not believe the market works this way. According to that logic popularity correlates with expenses. So if you have e.g. 1 billion users, even $1 in per-user hardware costs causes a billion dollar losses to customers. Is that unacceptable? On the other hand a program with a userbase of 10 might require a $100 hw upgrade and it is still ok?
> 
> Usually it is the other way, more popular programs pretty much dictate what hardware is useful today. E.g. consider a G4 Mac or PIII PC, it is pretty much useless today since popular web applications like facebook, myspace, youtube, and others are way too slow on it. (not to mention the obligatory virus scanner updates which today require a 2 GHz PC). The HD videos in youtube may require a 1.2+ GHz PC. If you buy an office suite, the old Windows 98 will not even let you install it. Upgrading to Vista is not possible since it will not fit to the 10 GB hard drive. The stores will not sell PATA drives anymore so you either need to buy a PCI PATA controller (not supported by the OS, of course) or upgrade the case, psu, mobo, cpu, memory chips, graphics card, and the hard disk.
> 
> A used 2.5 GHz Athlon XP with 1GB of RAM and 100GB of disk costs about $100. Anything below that is obsolete these days. Good luck selling anything to people who use older computers, they are probably broke anyways. Otherwise I just see it cheaper to build your apps slower and require hardware updates. Just imagine - a highly optimized $400 program is way too expensive for most users, a $50 program + $200 hw upgrade sounds just fine.

But a $40 optimized program will flush the competition of either $400 optimized equivalents or $40 slow equivalents, making you the winner in the end. People are so crazy about money they care more about their profits than the satisfaction of their customers.

language_fan wrote:
> I do not believe the market works this way. According to that logic popularity correlates with expenses. So if you have e.g. 1 billion users, even $1 in per-user hardware costs causes a billion dollar losses to customers. Is that unacceptable? On the other hand a program with a userbase of 10 might require a $100 hw upgrade and it is still ok?

If you manage to sell a billion copies of your program, you can certainly afford to spend some extra time on optimizations and reach maybe another million users (which would be only 0.1% of your total user base, but a huge amount of money in absolute sales).  If you're serving a vertical market of only 10, then your program is probably so expensive that another $1000 for hardware upgrades is peanuts.  So yes, that's the way it works.

> A used 2.5 GHz Athlon XP with 1GB of RAM and 100GB of disk costs about $100. Anything below that is obsolete these days. Good luck selling anything to people who use older computers, they are probably broke anyways. Otherwise I just see it cheaper to build your apps slower and require hardware updates. Just imagine - a highly optimized $400 program is way too expensive for most users, a $50 program + $200 hw upgrade sounds just fine.

If you just pull numbers of your ass, you can prove anything.

Software is priced to optimize total income, which is net income per unit times number of units sold.  Production costs are not factored in at all.  So the real question is if your $50 software package sells enough additional units to make up for the increase in production costs.

Competent programmers write reasonably efficient code from the start, and can take maybe another 10% of the development time to optimize the code to the point of diminishing returns.  If you have competent programmers, your 8x price increase almost an order of magnitude off.

Incompetent programmers don't just write slow code, they write buggy, non-reusable code.  If you're using incompetent programmers, you're probably wasting more money on management than it would have cost to hire competent programmers in the first place.


-- 
Rainer Deyke - rainerd@eldwood.com