Re: Tech directions for Delphi?
- From: "Marc Antheunis" <ask_me@xxxxxx>
- Date: Mon, 9 Oct 2006 14:51:20 +0200
seconded...
"Eric Grange" <egrangeNO@xxxxxxxxxxxxxxx> schreef in bericht
news:452a0985@xxxxxxxxxxxxxxxxxxxxxxxxx
Unicode was yesterday.
.Net 2.0 was yesterday.
Win64 is today.
.Net 3.0 is today.
What's for tomorrow?
More CPUs on an entry-level desktop machines than most servers ever had.
Dedicated processing units, GPU, PPU, VPU...
What are DTG plans on these? Current development tools and languages are
quite inconvenient (to say the least) when doing multithreading, not only
because of thread safety (the low hanging fruit), but because load
balancing and true parallelism is really hard to achieve (even on a dual
core, try making a mere "search and replace"... even on a buffer already
in memory with no I/O getting in the way, achieving 4x the execution speed
on a quad core can already involve hellish stuff).
Intel is announcing 16 cores, 256 cores and more within the decade.
Quad-core will be available by the end of the year, and will be mainstream
by the end of 2007, at that point, 16 core servers won't be such alien
encounters.
Customers will want to see some speedups /even/ if the server isn't
serving 16 clients at the same time (the low hanging fruit, though not
that easily caught due to the ease with which you can end up with implicit
locks and serialization).
If there is a future development market to be taken, it's the one that
will allow to make use of those extra xPUs /easily/, even for mundane
tasks, and without having to slog through threads explicitly.
There are specialty languages and arcane tools, but as for mainstream
tools, this is still virgin territory... but once someone will have
claimed land there, all the other dev tools and languages will become
obsolete in short order, like magnetic storage obsoleting punch cards.
A Delphi Win64 not relying on a GC but on classic allocation or
reference-counting would avoid a core scaling bottleneck (that is gonna
bite MS), but you'll need more than that: micro task schedulers,
threading-friendly collections, modular compiler (compile one part for a
CPU core, another for whatever VPU you'll be delegating that work piece
to), language enhancements etc.
Are there any plans? It would be rather lethal IMO to give priority to the
.Net chase instead. Here is an opportunity to leapfrog MS: while they're
busy refining .Net and presentation layers, build the development platform
that will process, compute and manage all the /data/.
Kinda like a VCL in reverse: VCL leapfrogged MS on the UI front, but since
leapfrogging on the UI will prove difficult this time, leapfrog them on
the data processing front.
Things like ECO are design tools, they shine more when designing the
bowels than when designing UIs. Leverage the strengths!
Many of us have been using Delphi/Pascal for processing tasks,
server-side, and scientific stuff. Not all Delphi users spend their time
slapping together UIs with DB-aware components.
Eric
.
- References:
- Tech directions for Delphi?
- From: Eric Grange
- Tech directions for Delphi?
- Prev by Date: Re: Application.Title
- Next by Date: Re: Application.Title
- Previous by thread: Tech directions for Delphi?
- Next by thread: Re: Tech directions for Delphi?
- Index(es):
Relevant Pages
|
|
