 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Fikret Hasovic
Guest
|
|
| Back to top |
|
 |
Martin James
Guest
|
 Posted: Mon Jun 20, 2005 9:14 am Post subject: Re: Delphi to take advantage of multiple threads within the |
 |
|
| Quote: | "I'm also looking at ways to re-architect the compiler itself, perhaps
there is a way we can take advantage of multiple threads within the
compiler, this is something we haven't pursued in the past."
|
Hmm. A CPU-intensive single-pass compiler. Would be an interesting
challenge to try & wring extra performance out of todays
multicore/multiprocessor boxes. They would have to dump 'TThread.waitFor'
and TThread.synchronize', however, when designing their super-compiler :)
Running the debugger/IDE on a different processor than the exe would be
useful, however, (esp. with my apps:)
Rgds,
Martin
|
|
| Back to top |
|
|
Peter Zolja
Guest
|
| Posted: Mon Jun 20, 2005 12:20 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | Hmm. A CPU-intensive single-pass compiler. Would be an interesting
challenge to try & wring extra performance out of todays
multicore/multiprocessor boxes. They would have to dump 'TThread.waitFor'
and TThread.synchronize', however, when designing their super-compiler 
|
I believe Danny was talking about compiler changes that would allow writing
multi-threaded apps in an easier way; here's a quote from the same article:
"For an application to fully exploit all of that compute capacity the
application has to be multithreaded. The problem with multithreading today
is that it is all manual, the programmer has to do everything. The name of
the game for tools is to present a simplified model that is automatic and
just takes care of the details. I think we have an opportunity to go that
way with Delphi language changes. If we can either redefine some of the
existing language or introduce new pieces to the language that would say
"this routine can execute independently of all the others" then you don't
have to worry about callback or a number of other things. "
|
|
| Back to top |
|
|
marc hoffman
Guest
|
| Posted: Mon Jun 20, 2005 12:49 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | If we can either redefine some of the existing language or introduce new
pieces to the language that would say "this routine can execute
independently of all the others" then you don't have to worry about
callback or a number of other things. "
|
What a great idea!
--
marc hoffman
Chief Architect, .NET
RemObjects Software
http://www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Mon Jun 20, 2005 1:32 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | "I’m also looking at ways to re-architect the compiler itself, perhaps
there is a way we can take advantage of multiple threads within the
compiler, this is something we haven’t pursued in the past."
|
The most interesting bit isn't this one IMO (compiler is already plenty
fast) but the one about language improvements to make multithreading
usage implicitly more simple.
Been discussed here several months ago... this one is a tough nut to
crack, but with 2-4 way cores coming to the desktops today, and 8 to
64-way core starting to show up on AMD/Intel roadmaps, the old
fashionned multithreading will be showing its age.
Tomorrow's performance winners will be languages+compilers that can make
multithreading easier to write than single threading, ie. the complete
opposite of what today's programming language are offering.
Eric
|
|
| Back to top |
|
|
Captain Jake
Guest
|
| Posted: Mon Jun 20, 2005 1:35 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
marc hoffman <spam (AT) spam (DOT) spam> wrote in message
<42b6bb46$1 (AT) newsgroups (DOT) borland.com>
| Quote: | What a great idea!
|
As long as it is not done with synchronization objects that freeze one thread
while waiting for another. That is not true multi-threading.
--
***Free Your Mind***
Posted with Reader3000-BETA 0.9.4.847
|
|
| Back to top |
|
|
Ralf Mimoun
Guest
|
| Posted: Mon Jun 20, 2005 1:49 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
marc hoffman wrote:
| Quote: | If we can either redefine some of the existing language or introduce
new pieces to the language that would say "this routine can execute
independently of all the others" then you don't have to worry about
callback or a number of other things. "
What a great idea!
|
Indeed  Btw, greetings to Derek if you talk to him. He is a great
speaker, and a great guy overall!
Ralf
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Mon Jun 20, 2005 3:16 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | What a great idea!
|
I'm not sure such an approach has any future beyond dual or quad core
(and that, if you're lucky), 64+ core CPUs are already on the roadmaps,
you'll need more than syntaxical sugar around threads (which is what
this solution consists in) to make efficient use of these beasts .
You'll need a more implicit threading model, you'll need the compiler to
be able to handle threading of code with dependencies, and more
generally, you'll need scheduling, reordering and management of
asynchronous operation down to the variable/code line.
If I code
A:=SomeFunc;
B:=SomeFunc;
C:=A+B;
...some other code that doesn't use C...
if C<4 then
not only should the compiler fire SomeFunc simultaneously, but it
shouldn't have a wait or synchronize on the C:= assignation, only at the
'if', and even at the 'if', it should only trigger an actual wait if
what is in the 'if' is required by another thread, f.i. if you have
if C<4 then begin
SaveToFile('dummy.file', C);
end;
and C is no longer accessed after that, it should push back the
synchronization/wait to whatever code (if any) actually attempts to
access 'dummy.file'.
Kinda like for plant-floor scheduling: as long as the synchronization
requirement isn't an hard requirement, things happen in parallel and
asynchronously by default. There is no "main thread" anymore, only
distinct tasks that have requirements and are themselves requirements to
other tasks.
Eric
|
|
| Back to top |
|
|
Dennis Landi
Guest
|
| Posted: Mon Jun 20, 2005 3:22 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | Tomorrow's performance winners will be languages+compilers that can make
multithreading easier to write than single threading, ie. the complete
opposite of what today's programming language are offering.
|
And to be fair to Danny, I think this is exactly what he's talking about.
While he's re-architecting his compiler its pretty obvious he'd be doing it
for the 64-bit world, btw...
Mind-numbingly obvious to me. What I really like about this new bit of
info, is that the real challenge is getting Borland management to sign-off
on funding the work to RE-ARCHITECT the compiler (and *selling* a compelling
reason to do it). If true, who can doubt it that the new architecture would
be a 64-bit compiler??? (Or a flexible compiler to support more than one
"bit-ness")
Not me.
Nice going Danny. Still "research" is not "implementation". Although it
certainly is the egg before the chicken....
-- d
---------------------------------------------------
Need to see what's happening?
Check out the Delphi Community Blog Aggregator
http://delphi.flashblogger.com
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Mon Jun 20, 2005 4:02 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
| Quote: | And to be fair to Danny,
|
Yep, hence my most interesting bit 'redirection' ;)
Though I don't think just adding syntaxical sugar around threads will be
enough for anything but the 1st generation of multi-core (which may not
last very long IMHO, I wouldn't be surprised to see 4 and 8 core become
widespread before the market has had a chance to digest dual core, cf.
Intel roadmaps).
| Quote: | While he's re-architecting his compiler its pretty obvious he'd be doing it
for the 64-bit world, btw... Mind-numbingly obvious to me.
|
Not to me... yet :/
There could be a variety of reasons for that, like f.i. having had
trouble with generics or some other feature, and not wanting to go
through that trouble for the next major feature addition, or being able
to add new constructs/optimizations for multithreading more easily, etc.
Eric
|
|
| Back to top |
|
|
Dennis Landi
Guest
|
| Posted: Mon Jun 20, 2005 4:02 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
"Eric Grange" <egrangeNO (AT) SPAMglscene (DOT) org> wrote
| Quote: | While he's re-architecting his compiler its pretty obvious he'd be doing
it
for the 64-bit world, btw... Mind-numbingly obvious to me.
Not to me... yet :/
|
Well, if he should go through the effort and expense of actually
RE-ARCHITECTING the compiler, and not support native 64-bit, then may
Borland R.I.P.
-- d
---------------------------------------------------
Need to see what's happening?
Check out the Delphi Community Blog Aggregator
http://delphi.flashblogger.com
|
|
| Back to top |
|
|
a
Guest
|
| Posted: Mon Jun 20, 2005 4:18 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
Sounds like Modula/2?
Used this 15 years ago in University.
|
|
| Back to top |
|
|
Rudy Velthuis [TeamB]
Guest
|
| Posted: Mon Jun 20, 2005 6:05 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
At 18:18:02, 20.06.2005, a wrote:
| Quote: | Sounds like Modula/2?
Used this 15 years ago in University.
|
AFAIK, Modula 2 only had cooperative multi-tasking.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Sometimes when reading Goethe I have the paralyzing suspicion that he is
trying to be funny."
- Guy Davenport
|
|
| Back to top |
|
|
Loren Pechtel
Guest
|
| Posted: Mon Jun 20, 2005 7:36 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
On Mon, 20 Jun 2005 10:14:37 +0100, "Martin James"
<mjames_falcon (AT) dial (DOT) pipex.com> wrote:
| Quote: | "I'm also looking at ways to re-architect the compiler itself, perhaps
there is a way we can take advantage of multiple threads within the
compiler, this is something we haven't pursued in the past."
Hmm. A CPU-intensive single-pass compiler. Would be an interesting
challenge to try & wring extra performance out of todays
multicore/multiprocessor boxes. They would have to dump 'TThread.waitFor'
and TThread.synchronize', however, when designing their super-compiler :)
Running the debugger/IDE on a different processor than the exe would be
useful, however, (esp. with my apps:)
|
It seems to me it would be fairly simple to make a limited
multi-thread compiler. It would require almost no changes to the core
of the compiler.
The thing is the reality is that most of the time you're compiling
multiple files.
Thread #1: It's only job is to walk the uses chain figuring out what
needs to be done. When it finds something that needs doing it puts it
on a list. If it can't find anything useful to do it compiles
something instead.
Threads #2...max processor-equivalents: Take a task from the
to-be-compiled list that isn't blocked by anything. Compile it.
Obviously this does nothing for the final link step.
|
|
| Back to top |
|
|
Crazy Horse's crazier lit
Guest
|
| Posted: Mon Jun 20, 2005 9:13 pm Post subject: Re: Delphi to take advantage of multiple threads within the |
|
|
"Loren Pechtel" <lorenpechtel (AT) removethis (DOT) hotmail.com> wrote
| Quote: |
It seems to me it would be fairly simple to make a limited
multi-thread compiler. It would require almost no changes to the core
of the compiler.
|
IMO, the words "simple" and "multi-threaded" do not belong in the same
sentence.
--
Download Blackbird Crow Raven's book
"STILL CASTING SHADOWS: Two American Families 1620-2006"
(.exe and .pdf): http://cc.borland.com/ccweb.exe/listing?id=23106
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
